Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- About ronnieshih75
ronnieshih75
Getting noticed
Member since Jan 21, 2021
Monday
Community Record
62
Posts
50
Kudos
3
Solutions
Badges
01-04-2023
11:06 AM
2 Kudos
Thank you for the articles. I found the issues eventually myself. The endpoint test laptop did not have certificate meant for client/server authentication from our internal CA installed. Also our Forescout server did not have the intermediate certs from the subordinate CA servers. After that, I also found out that on the endpoint, I had to configure authentication to do "Computer authentication" only because user was getting tried and that's not what I want. THEN, I found out on the Forescout or RADIUS server, a different cert was getting hit. So I had to reconfigure the client end to use that cert instead. 802.1x EAP-TLS authentication then started working.
... View more
01-03-2023
10:02 AM
Once again I'm hitting this community for some potential answers. I am attempting to setup 802.1x authentication using certificate on a "wired" Windows 10 host against Forescout as the RADIUS server. Forescout does not have great documentation on how this should be done on the Windows side. Currently, Meraki support verified that the Windows 10 test host I have is not sending 802.1x auth attempts and failing over to MAC address bypass directly. On the Meraki switch side, just to verify nothing is setup wrong, I have an access policy under switching/access policies: - my RADIUS server with the Forescout's host IP port 1812 and shared secret -> verified to work - RADIUS testing enabled - RADIUS CoA enabled - RADIUS accounting with the Forescout's host IP port 1813 and shared secret - RASIUS attribute specifying group policy name: None - Host Mode: Single-Host -> I have just a laptop attached to a switch port - Access policy type: Hybrid authentication - Guest VLAN: our guest vlan ID of 133 - Failed Auth VLAN: None - Re-authentication Interval: None - Critical Auth VLAN: None - Voice VLAN client: Bypass authentication - URL redirect walled garden: disabled - Systems Manager enrollment: disabled I believe the above works, I am not clear regarding what settings should be on the Windows 10 host side, even with Forescout's professional service help. I have our internal CA's root cert loaded in Forescout, as well as on the Windows 10 host. Windows 10 host is configured with these settings under the Authentication tab of the Ethernet NIC: - Enable IEEE 802.1X authentication - Choose a network authentication method: "Microsoft: Smart Card or other certificate" - Verify the server's identity by validating the certificate unchecked Under "Microsoft: Smart Card or other certificate" Advanced setting: - Use a certificate on this computer with Certificate Issuer being our internal root CA's cert - Extended Key Usage (EKU) checked - All Purpose unchecked, Client Authentication checked, AnyPurpose unchecked Please advise, thank you.
... View more
11-29-2022
12:25 PM
2 Kudos
Received Cisco branded GLC-TE SFP modules yesterday, and guess what?! They work right out of the box. I finally got the routers up and firmware upgraded on those modules first. Then we plugged in the MA-SFP-1GB-TX modules, and now they also finally work after that firmware upgrade. Lesson learned. I'm actually ditching the Meraki MA-SFP-1GB-TX modules for Cisco ones. The Cisco ones also seat properly. SOLVED. This was a double fail: 1. Meraki support couldn't tell provide a fix over the phone, nor did the 3 guys I spoke to know about this. And 2. The hardware is poorly manufactured with fitment issue, plus firmware upgrade required first for the meraki branded modules to work
... View more
11-22-2022
10:34 AM
If you've read my original post. I do not have any working WAN port on the MX250 due to SFP module issue with MX250 on old firmware.
... View more
11-22-2022
07:11 AM
Again, I found info off older forum posts: https://community.meraki.com/t5/Security-SD-WAN/Mx250-wan-compatibility-changed/m-p/122179 To summarize, MX250s need to run firmware v16.10 and newer to support newer MA-SFP-1GB-TX modules. And simply to make it work, get the old Cisco GLC-T modules. Excerpt from the post:
... View more
11-21-2022
03:08 PM
Discovered that the modules indeed weren't seating in, clicking in. But this didn't matter though. We finally got one seated in, clicked in. First tried two SR modules with single mode LC fiber cable in between, switch side would not light up, MX250's status LED did light up finally. Perhaps I just need to reboot the MS120-8 external switch but it's a prod switch and I did not want to reboot it during the day. The two MS120-8 switches have only two 1GB SFP ports so using DAC is out of the question, although I do have DAC cables and did try it and both switch and router side stayed dark. Unfortunately, I do not have aftermarket non-Meraki SFP modules just sitting around to play with. I will be stopping by a branch office to rip off an Inseego SkyUS-DS 4G modem and use it on the MX250's USB port. This is most likely how it will get to the internet. This was a solid USB 4G modem supported on all MX routers in the past that we used for tertiary internet failover. To be continued after Thanksgiving.
... View more
11-21-2022
11:50 AM
And how did you manage to get the updated firmware on there? SFP handoff from provider's NID?
... View more
11-21-2022
11:04 AM
Absolutely not. It wouldn't, because the router still cannot get to the internet to update its firmware to support the modules.
... View more
11-21-2022
10:27 AM
Connecting a MX250's SFP+ port to one of our existing MS350 switch's SFP+ port via a twinax cable does absolutely nothing, as I imagined it would be. I literally JUST TRIED IT. The MX350 has internet access via its VLAN1 interface. The physical interconnection between the MS350 switch and the MX250 router serves as only a transport, the MX250 does not obtain any sort of IP address because its SFP or SFP+ ports do not obtain IP addresses. The only thing that came out of trying this was that the MX250 started serving DHCP IPs off its default 192.168.0.0 network which I got an alert for on our prod network so I promptly disconnected the router. The only way for these routers to get updates is for me to buy an old Inseego SkyUS-DS 4G modem on ebay, which is supported on all MX routers and plug that into the USB port of the router for it to get firmware update over 4G. That's yet another second fail on Meraki's part, they have no updated list of supported USB 4G modems.
... View more
11-21-2022
09:56 AM
My question is how would you route traffic of a router out the internet with it being behind a switch? The downlink SFP switch ports are in either trunk or access mode with a vlan number, but no default gateway and it won't get a DHCP IP on any port. The SFP ports are meant to do transport and not route, that's what the WAN ports are for. So now we are trying to come up with some arcane workaround fiddling with our headquarter's existing network.
... View more
11-21-2022
09:25 AM
That's what my second picture above shows. The MA-SFP-1GB-TX module works in a SFP port meant for downlink to switches, but does not work in either one of the WAN ports.
... View more
11-21-2022
08:33 AM
Once again, I need to resort to the community to solve problems where meraki support is lacking information on. Story begins: I have two MX250 units that are supposed to replace two MX100 routers at our headquarter office. Our two internet service providers provide only single copper handoffs off the network interface units. And we have an active / warm spare meraki router setup at this location, therefore, external public switches are required. And the 2 external switches also only support copper ports. I've been told by both our Cisco reps and Cisco Meraki support that we need to install the MA-SFP-1GB-TX module in the WAN or internet ports then we can use ethernet cables to connect to the external switches for internet connectivity. Well, I've found that these modules do not admin up by the OS and stay dark as indicated by the ports' status LED. (see picture 1) While they do blink on the external switches side ports, however the ports aren't even arp-ing on the external switches. Oddly, these modules come up when I move them to a SFP downlink ports meant for switches. (see picture 2). So one of the meraki support techs I spoke to said that I must select the 1Gbps full duplex setting which I have set via the local status page. (see picture 3) The modules still do not come up. Now consulting the SFP data sheet, the MA-SFP-1GB-TX modules are supported on "All MXes", see this doc: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/SFP_and_Stacking_Accessories So I'm at a loss. Then the next thing Meraki support asked me to do is to download the out-of-band support data, which ironically, without getting these routers to the internet to upgrade whatever firmware these routers are on, this feature is not supported in the local status page. Yes, I have quadruple checked. So I'm dead in the water here. These routers aren't traditional Cisco routers where I can just console in to pull files or just upgrade the firmware locally. These are getting packed and shipped back if no one has an answer here regarding whether these modules work in the WAN ports.
... View more
10-24-2022
03:40 PM
This is unbelievable, more than a year after I made this post, people are still discussing MS390's instability even on the newest beta firmware.
... View more
06-06-2022
02:32 PM
Wow, still not fully fixed, after almost a year!! You keep us updated here. Read what I wrote above, I upgraded firmware almost weekly for 3 months straight until the day I finished dismounting all MS390 switches.
... View more
04-26-2022
06:15 PM
API isn't pulling in os fingerprint unfortunately. I don't think I'm missing anything thing since the api pull config inside our NAC server is straight forward. But I'll give meraki support a call tomorrow to find out for sure.
... View more
04-26-2022
05:00 PM
We are already using API to pull MAC/IP address binding through API. Lots of unidentified devices. It does not pull in device type or OS and the NAC server has a hard time identifying devices using its own native means of device identification mechanism. I've been told to "relay DHCP information" to the NAC server but we all know the definition of DHCP relay means running DHCP server on the piece where you relay DHCP to, so that's not the right answer. Thanks anyway.
... View more
04-26-2022
02:48 PM
We are looking for a way to send DHCP audit logs or DHCP events to a network access control server, for the purpose of better device identification. We already have the syslog option configured and every single type of logs to send to our NAC server, however, this is not fulfilling what we need. Is there such thing as a DHCP option that sends DHCP messages to a different device or a Meraki specific function I'm not finding? thanks.
... View more
03-31-2022
03:36 AM
"Assign group policies automatically by device type" option works within each SSID network where it's defined, as I tested using an Apple ipad and an android phone. A single Deny Any to Any rule + an Allow UDP port 67 allows a device to obtain an IP address seemingly to allow access but all traffic to anywhere is denied. Although, you do need to allow for existing traffic streams to die off then all new traffic would effectively be blocked. This fulfills my goal of kicking all personal devices off our existing PSK SSID without changing the passphrase. This forces everyone to use the guest SSID instead. After the above is done for a while, we'll implement iPSK with RADIUS where we have a central MAB database of devices using different PSKs.
... View more
03-28-2022
04:48 PM
Did you mean loading the approved MAC addresses into Forescout and utilize iPSK with RADIUS right away? Since I don't see a native connectivity restriction by MAC address option in Meraki. I mean, other than the "MAC-based access control (no encryption)" option. And that's up to 10 IoT devices per network and I have 145 networks, so it's 1450 legit IoT devices that need to remain connected. I should mention that I do not have an inventory of all IoT devices as we speak. That's why I need to phase this in by forcibly disconnecting other types of devices first, and without changing the existing PSK passphrase because I cannot drop those IoT devices off the network. I understand "apply group policy by device type" option is not reliable but it's something than nothing. I don't see why I cannot use this right away simply to disconnect Apple devices off the network. The most recent version of Meraki dashboard 90% of the time can identify apple devices properly from what I've been seeing.
... View more
03-28-2022
03:19 PM
So I have several challenges here: - Since everyone knows the PSK passphrase for the existing SSID network, every single IoT devices + personal devices are connected to that SSID. I basically need to kick all those personal devices off that existing SSID network first. I see this is possible by using the "assign group policies by device type" then create and apply a policy with a firewall rule which says "Deny Any to Any". Our network has a rampant issue with personal Apple iPhones running wild so this is easy for me to do. - iPSK with RADIUS needs a database of MAC addresses of approved devices that are allowed to connect correct? I basically need to gather device types and their first few octets and configure them inside Forescout. Forescout will then act as the central point of auth for PSKs. Although all our wifi networks are centrally managed via a template, so by having the different PSKs configured inside 1 single Meraki template, is that not the equivalent of having the PSKs on a RADIUS server? It's almost like one solution is enclosed within Meraki and the other I'm using a 3rd party off-band server for auth. The only feature I'm missing here is that I wouldn't have a database of approved devices by doing it inside Meraki as oppose to inside Forescout. BTW, we will not have more than 10 devices using PSK because all windows domain joined devices are using 802.1x auth through a different SSID already. So I don't see doing this at the meraki level being an issue, with the limit of 50 iPSK devices. - THEN, we need to have our field techs change the PSK on IoT devices so that legacy PSK passphrase can be eliminated, preventing any future personal devices from using it. And the different PSKs can start to be handed out for different purposes. This last part is the most painful as our company has geographically diverse locations throughout US and will not be easy.
... View more
03-28-2022
03:00 PM
Because I'm told by Meraki support that assigning or tagging a different VLAN by a NAC mediator by means of applying a group policy via meraki API does not "move" an endpoint into a different SSID network. In theory, it changes the VLAN the client sits in, but it does not connect the endpoint to a different SSID. Is this true?
... View more
03-28-2022
02:34 PM
Keeping track of over 5000 approved devices across 145+ networks would be a monumental full time task for me. So I'm leaning toward the iPSK without RADIUS idea. We are using Forescout, and is the iPSK with RADIUS even possible? I am still picturing our field techs heading out to all locations and modifying the PSK for all IoT devices first even if I use iPSK without RADIUS. Secondly, if I do assign a different group policy to personal wireless devices, it still sits in a vlan that's not of the "guest" vlan correct?
... View more
03-28-2022
12:15 PM
Using an installed agent is out of the question. The whole point of my goal here is to prevent people from connecting their personal devices to a SSID using PSK, where everyone already knows the password. I cannot possibly tell people to install an app agent so I can kick them off the network 😅 This needs to be transparent in the background. Yes yes, we are looking to change the PSK passphrase on that SSID, however, that's easier said than done because there are hundreds legit IoT devices using that existing PSK SSID. We have a rampant problem with people connecting their personal cell phone and streaming on the wifi network causing high bandwidth usage.
... View more
03-28-2022
11:37 AM
We are in the process of implementing NAC control and is looking for a way to automatically disconnect a WiFi endpoint from any SSIDs users shouldn't connect to and placing them into a guest SSID. I have already spoken to Meraki support and was told that there is no way to do this as an endpoint is the selection host of SSID to connect to and it cannot be done via an intermediate NAC control point or a Meraki group policy. A NAC solution can exercise a block action by basically making an API call to meraki dashboard, but making the endpoint connect to a different SSID is not possible. I'd like to know that there is really a way to do this. We are currently deploying Forescout as the NAC solution.
... View more
02-02-2022
02:39 PM
1 Kudo
For the record, once again, I configured these stacks within 2 days then configuration was static from then on with no more L3 changes. Problem started about a month after the finished installation. Then it was non-stop weekly firmware upgrade, it was a complete joke trying to explain to management why I was at the call center every Friday night, it basically ruined my weekends for the summer months in 2021. I don't see a point in defending a product that brought down our call center about 5 times in the middle of the day. Even the $300 Cisco Small Business switches off ebay are better than these.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 243 | 01-04-2023 11:06 AM | |
| 595 | 11-29-2022 12:25 PM | |
| 2889 | 08-27-2021 09:40 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 8 | 13592 | |
| 7 | 13711 | |
| 5 | 14679 | |
| 4 | 12672 | |
| 4 | 14292 |
