Roaming with NAT mode; 802.11r


Roaming with NAT mode; 802.11r

We have our main SSIDs using NAT mode at the moment. I am curious if any of the roaming technologies (802.11k, r, v, etc.) do not apply to networks using Meraki NAT, and if so, which and why? Also, are there any disadvantages of using NAT over bridge mode or vice versa, aside from the obvious NAT taking place on the AP itself?

5 Replies 5
Meraki Employee
Meraki Employee

802.11r is meant to be used in enterprise wireless LANs typically using WPA2/Enterprise although you can also leverage it with WPA2/Personal.  Regardless the SSIDs need to be running Bridge Mode to support fast secure roaming.  You'll notice the 802.11r option disappear and reappear on the Access Control page by toggling between NAT mode and Bridge mode.  If you need to leverage 802.11r, run in bridge mode and probably leverage VLAN tagging.  If you have a Guest SSID, that's where you can leverage NAT mode, that way there's also client isolation (all guests will get a seemingly random 10.x.x.x address and be firewalled off from one another) and also firewall the Guest SSID from local LAN resources, as well as set a per-client bandwidth limit on the Firewall & Traffic Shaping page. 


One disadvantage with NAT mode is with roaming.  Roaming to new APs on a NAT-mode SSID will be disruptive to the connection, one reason being that everything will be NATted to the management address of the AP itself so when a client roams they reauthenticate and reassociate from the top like a full L3 roam.  So that's right in line with the 11r option disappearing when you've got NAT mode selected.  Consider running your main/internal SSID in Bridge mode.


One other possible disadvantage with NAT mode might come up in really large networks, if you have thousands of users on multiple NAT mode SSIDs, that's an awful lot of NAT processing and DHCP operations on the APs.  I haven't come across an upper limit yet, and I've seen this scale very high in enterprise deployments, but I'd imagine multiple SSIDs running in NAT mode supporting thousands of clients, there could be a performance degradation at some point. 


Some links for more info:


I'm really glad you mentioned the NAT session disruption. Previously I thought the clients would maintain their session since they get the same IP address when roaming, but somehow I didn't take the actual AP management IP change into account. I think we'll be switching back to bridge mode soon.


Also, now that there's an option to enable client isolation in bridge mode, there's no real reason to stick with NAT mode.


On a different note, how do the APs handle traffic shaping on a larger scale as compared to using a dedicated shaping appliance? We are using both in different situations, and they seem to be working fine as is, but I am just curious if there is any latency or excess overhead introduced when the AP does the shaping, especially when handling a lot of concurrent clients.



Agreed, you'd probably be better off with Bridge Mode for that reason.  In the guest case, when it does scale very high, that's when you might see that Guest SSID also use Bridge mode, but leveraging a dedicated Guest VLAN on the wired side.


Since it was a pro/con type question, one thing I left out was the basic adult content filtering that's there when running in NAT mode, you wouldn't have that in Bridge mode.  But as you mentioned if you have an MX appliance that's the ideal way to have full content filtering and traffic shaping (plus FW, IDS/IPS, AMP, VPN).  On a larger scale, you have that option of a distributed traffic shaping solution by enforcing those rules right at the edge of the network on the APs, sparing the wired infrastructure from traffic storms and placing all the traffic shaping and firewalling burden on the dedicated appliance. 


I've yet to see a deployment where a very high number of either traffic shaping rules and/or firewall rules on the APs caused noticeable performance or latency problems for clients, so long as best & common practices were implemented.  Meraki APs generally have more CPU and memory packed into them than is necessary in order to accommodate future firmware versions with more features.  As things scale, I think you'd get administratively worn out first (quite a large Dashboard page with hundreds of rules) before the APs ran out of horsepower.  So yes, there's certainly additional processing happening if you've got several hundred firewall and traffic shaping rules, but in most cases when there's that many (I've only seen a few) the question is "why" and there's typically a much better way to consolidate rules down to a more manageable and reasonable level.  If you're on the scale of a few dozen rules at most (very common), I'd say the impact is minimal to negligible in most use cases. 

I figure this question is related enough to reply here instead of creating a new topic:


Is L3 roaming mode incompatible with 802.11r? I see the selector for it disappears when going from bridge to L3 roaming. Why is that?

Meraki Alumni (Retired)
Meraki Alumni (Retired)

Yes, it is currently incompatible with 802.11r, as explained here:



Leo Gomez
Get notified when there are additional replies to this discussion.