Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
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 kidtrebor
kidtrebor
Comes here often
Member since Dec 10, 2018
Jan 11 2019
Community Record
5
Posts
0
Kudos
0
Solutions
Badges
Dec 13 2018
3:13 AM
Just as an aside - we are now wondering if the start/stop messages from the APs are really reaching the firewall; we've configured the accounting server IP on the SSIDs to send accounting information directly to the FortiGate, but seeing some unusual behaviour; for example deauthentication messages followed by several authentication messages issued when roaming, but the client traffic still unable to get network access. We are using Meraki APs in conjunction with Windows Server 2012R2 as the RADIUS server, and the FortiGate firewall as mentioned. Does anyone else use a similar setup who might be able to post best practise advice? Regards, Robert
... View more
Dec 10 2018
2:06 PM
Connected to the edge switches - L3 Switch at the core, which then connects in to the firewall.
... View more
Dec 10 2018
1:54 PM
There’s no firewall between the clients or the APs; the RADIUS server is in a data centre via IPSEC VPN, which is managed by the firewall. We have a policy to permit all traffic to the RADIUS server.
... View more
Dec 10 2018
12:11 PM
You assume correctly, it’s in bridge mode. So yes, funny you should mention 802.11r. We got burned by this badly when we first implemented Meraki 3 years ago, so have always kept it off - you’d roam from AP to AP and the device would fully disconnect from the network and never jump back on until you forgot it and joined again from scratch. Anyway, a few months ago I became aware that Meraki had implemented adaptive mode and, on a hunch l, I gave it a whirl earlier today. Sadly, it had no discernible effect - I’d like to try again under more controlled circumstances, but I still saw deauth messages on the Meraki event log. I’ve also tried disabling band steering, and all combinations of band steering and 802.11r toggled, to no effect.
... View more
Dec 10 2018
9:03 AM
Hi, Wondering if anyone has experienced this before, or might be able to suggest a fix. We operate FortiGate firewalls on our campus network perimeter - traffic to the internet is only permitted outbound so long as the traffic is associated with a user. The firewall consults our RADIUS server to associate the traffic with the user. We have observed that, after an indeterminate period of time after authenticating on the 802.1x network, iOS devices would stop being able to access the internet. Initially we checked the firewall logs and could see that, sure enough, the traffic was hitting the deny policy. The reason was that it was not associated with a user. Further experiments showed that this would happen even only a few minutes after authenticating to the network. A deeper check of the firewall logs showed that a deauthentication message had been sent - ergo the firewall was behaving correctly. We then checked the Meraki logs. I've pulled some of the logs out and displayed below for reference. The first section here shows the events logged when authenticating initially - that is to say, joining the network, entering credentials and accepting the (self signed) certificate. Dec 10 16:01:08 SBK-CLV-MR33-WAP06 Southbank Staff Roberts-iPhone 802.1X authentication "radio: 1, vap: 1, client_mac: A0:D7:95:E4:94:B1" Dec 10 16:01:08 SBK-CLV-MR33-WAP06 Southbank Staff Roberts-iPhone 802.1X EAP success "radio: 1, vap: 1, client_mac: A0:D7:95:E4:94:B1" Dec 10 16:01:08 SBK-CLV-MR33-WAP06 Southbank Staff Roberts-iPhone RADIUS response "radio: 1, vap: 1, group: " Dec 10 16:01:06 SBK-CLV-MR33-WAP06 Southbank Staff Roberts-iPhone 802.11 association "channel: 44, rssi: 43" Here we can see an expected chain of events; association > response > EAP success > authentication. Delving further, our testing seemed to show that roaming to another AP triggered the loss of connectivity. We consulted the logs and observed the following events, slightly different to the above. Dec 10 16:03:28 SBK-CLV-MR33-WAP26 Southbank Staff Roberts-iPhone 802.1X authentication "radio: 1, vap: 1, client_mac: A0:D7:95:E4:94:B1" Dec 10 16:03:28 SBK-CLV-MR33-WAP26 Southbank Staff Roberts-iPhone 802.1X EAP success "radio: 1, vap: 1, client_mac: A0:D7:95:E4:94:B1" Dec 10 16:03:28 SBK-CLV-MR33-WAP26 Southbank Staff Roberts-iPhone RADIUS response "radio: 1, vap: 1, group: " Dec 10 16:03:28 SBK-CLV-MR33-WAP26 Southbank Staff Roberts-iPhone 802.1X deauthentication "radio: 1, vap: 1, client_mac: A0:D7:95:E4:94:B1" Dec 10 16:03:28 SBK-CLV-MR33-WAP26 Southbank Staff Roberts-iPhone 802.11 association "channel: 48, rssi: 49" Here we can see a deauthentication message thrown into the mix. From the testing I've done, whenever there's been a loss of connectivity, a deauth message has appeared in the Meraki logs. Now, I'm not quite sure what to make of this, but one question does spring to mind immediately - is the iOS device issuing this deauth message, or is the AP? I've raised this with Meraki support, they stated that the former is the case. What is strange, however, is that when roaming, the device will associate with a number of APs and the deauth message will not always be there; so I don't think it's part and parcel of the intended process. I haven't seen a description of how this process is supposed to work, so I'm not 100% sure. Any thoughts? Regards, Robert
... View more
© 2024 Cisco Systems, Inc.
