It is a Meraki Nxxx URL.  But I do not have the full URL as I'm waiting for a field tech to tell me when it happens again.   We run MX85 + MR56, neither one of these have splash authentication enabled.  However, the wireless network that contains and run the MR56 during the time period this happened shows splash authentication attempts in Network-wide/Monitor/Event log   ... View more

I sent you a PM ... View more

Well, we did consider using BGP, but it requires us to run MX450 in one-armed mode, which means we need a pair of super high-end high-powered routers in front of the MX450 to NAT with MX450 having just 1 single IP address.  Since it needs to talk to the internet and internally at the same time.  That was not an option for us either to scale out quickly, as it took some 6+ months for us to purchase a pair of Cisco ASR routers for a separate project due to supply chain issues. We just cannot wait that long.    There are things I wanted to do from design perspective but reality shows me otherwise.   So I'm left with this right now.  Cisco responded last night and they can disable the ability for hubs to talk to each other in the backend, it's an hidden option.  I'll be calling Cisco support this morning to get this going. ... View more

We upgraded to 14.33.1 back in September, since then (touch wood) we have had no issues. ... View more

Glad what we did worked for you, hopefully you can just enjoy the MX simplicity now 👍 ... View more

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

"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

We went through the same pain, after discovering the hard-way (at licenses renewal) that we were obliged to upgrade a vMX-100 to a vMX-M (which on Azure are equivalent, after Meraki doc) and when asked for support we were also bounced back to Azure support. ... View more

I will be building a windows 2016 server running DHCP and relay all DHCP requests back to headend data center instead.  But don't tell me that that even DHCP relay is busted... I hope that's not the case.     What bothers me here is the fact that everything was fine since I joined this company more than a year ago then this problem just started a few days ago while running on the same firmware for the last 2 months and 3 weeks. ... View more

Went back onsite yesterday to troubleshoot this with 2 guys walking the space, me doing air capture using Kali linux with an Alfa AWUS036CH high gain wifi NIC adapter listening/sniffing on channel 44 homed to a specific AP.  And we did this along with both Cisco and Portnox on the phone.  We actually could no longer reproduce the issue.  Cisco performed the following captures to make sure that the RADIUS packets are making all the through from the remote site via the SD-WAN IPSEC tunnel/over the internet to our headend in our data center where the Portnox auth caching server sits: - packet capture on the LAN interface of the remote network Meraki MX84 - packet capture on the SD-WAN virtual interface of the remote network Meraki MX84 - packet capture on the SD-WAN virtual interface of the headend network Meraki MX450 active node   All Radius packets accounted for.  This is why I asking what type of packet captures were performed.  We did captures at 4 different points.   Using the air capture of 802.11 packets via Kali Linux, I saw all 4 802.1X packets during authentication.   Conclusion of the underlying problems at this remote site that caused 802.1X issues were: - co-channel sharing when originally using 80MHz channel width among 9 different AP units. - serious wifi interference caused by this location next to residential area, had to turn on DFS channels for AP's to self adjust into those channels. - client balancing was turned on, caused proactive rejection of client re-association requests - 802.11r had to be turned off, Portnox' NAC solution is not so ready to work with 802.11r yet ... View more