Meraki

kidtrebor · ‎Dec 10 2018

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

PhilipDAth · ‎Dec 10 2018

I assume the SSID is operating in bridge mode?

Although it has gotten a bad name, have you considered using 802.11r? 802.11r is only dangerous with static PSK's. I suspect it might help in this case.

kidtrebor · ‎Dec 10 2018

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.

ozebaduac · ‎Dec 10 2018

have you a FW in th

@kidtrebor wrote:
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

e network?

kidtrebor · ‎Dec 10 2018

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.

ozebaduac · ‎Dec 10 2018

the AP's are connected in sw ports or in the fw directly ?

kidtrebor · ‎Dec 10 2018

Connected to the edge switches - L3 Switch at the core, which then connects in to the firewall.

kidtrebor · ‎Dec 13 2018

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

PhilipDAth · ‎Dec 13 2018

>We are using Meraki APs in conjunction with Windows Server 2012R2 as the RADIUS server

I've used this combination extensively, and not had issues. Typically in the setup's I have done the AP's RADIUS traffic does not have to pass through a firewall to get to NPS, or at most, only pass through a VPN.

FiberOps · ‎Nov 20 2019

Did you ever get this issue resolved. We are seeing similar behavior in our environment .

Meraki

Community

iOS 802.1x Deauthentication When Roaming

iOS 802.1x Deauthentication When Roaming