NAT as a VLAN

[JDavie]

Hello, I was hoping to get some more information on using NAT on an SSID. 

First, a bit of background, we offer a service where we setup devices for customers. We can currently do around 2,000 devices at a time, but are looking to scale that up to around 3K-4K over the next couple years. The setup process can take anywhere between 15-30 minutes per batch. These devices do not need to connect to anything locally, and only need to connect to the enrollment servers over the internet. We are running off a MX450, and have 

4x MR56 AP's for production. 

So, my questions are,

1) If we use NAT on the SSID we use for production, do we get the whole 16.7 million addresses that having a /8 subnet gets you? I would imagine that is split between all networks using NAT, which is fine.

2) What is the DHCP lease time for NAT? Is there anyway to change it?

3) Is there a general rule of thumb that would dictate if using NAT or a /19 subnet (largest Meraki will support) is "best practice"? 

Thanks!

[Bruce]

I'll add my two cents worth in here and let other people add their own too. My personal opinion is that if you want any control whatsoever over the IP addressing (e.g. static assignments, DHCP options like TFTP options, ...the list goes on) then don't use NAT mode. Go with a bridge mode SSID and stand-up your own DHCP server.

I was told this a while back, so not sure if it still applies, the DHCP in NAT mode is a pseudo-DHCP. The DHCP discovery and response messages are as you'd expect (so the client is doing normal DHCP), but essentially the AP just does a hash of the client MAC to create an IP address in the 10.0.0.0/8 range - and before you ask I've no idea what happens if two devices end up on the same hash, or if it ends up on the gateway address (10.128.128.128), I just assume there are checks built in. So there is very little smarts in the AP.

Specifically in response to your questions...

1) Yes, you do, on every SSID and every AP that uses NAT - but you probably won't have enough access points to handle that many simultaneous clients, and you've no way of specifically assigning an IP to a particular device (or knowing which IP is going to be assigned to a device, that is until its assigned).

2) I've never looked to see what lease time is given to a device, it just works. You could look on the client, or sniff the DHCP packet to be sure. There is no way to change this value that I'm aware of, and why would you? Chances are every client is going to hash to a different IP address anyway.

3) No general rule of thumb. For basic connectivity NAT mode is fine, but its dumb. If you want to do even the slightest 'smart' thing (e.g. change the lease time) then you'll need your own DHCP server, so bridge mode starts looking attractive.

I'm always careful about using large subnets, as you don't want to create a broadcast issue, even if it is just clients ARPing. You obviously can use them, but you need to understand your traffic flows, and how to mitigate any broadcast issues.

Hope this helps.

[JDavie]

Thanks for the detailed response. It has helped us out a ton.

Even looking into the future, we can't foresee needing any control over the addressing. The one thing we might do is block all traffic but the enrollment servers on the production SSID, but that could easily be done from the wireless firewall on that specific SSID. 

You were right about hashing the MAC address to get an IP address. It looks like the lease time is 1 day, so the chances of running into another address is astronomically small.  

To clarify what you said, each SSID and each AP has its own /8 pool when in NAT mode? So, if we have 4 AP's for production, we have like 66.8 million addresses? Then if we also have a guest SSID on that same AP, it has its own /8 pool?

Thanks again for the help!

[Bruce]

@JDavie on your last point, yes that’s correct. Since the IP address is NATed on a per AP and per SSID basis it’s only relevant within a specific AP and SSID combination. But because the IP address is a hash of the MAC a client is likely always going to get the same IP address for a specific SSID no matter which AP they connect to.

The point @PhilipDAth made around number of APs and number of clients is very valid. It’s going to take a lot of APs to connect that many clients. The theoretical maximums are here, but I’d be surprised if you can actually achieve this (hence why they’re theoretical):

• Wi-Fi 5 Wave 1 and older: 128 clients per radio
• Wi-Fi 5 Wave 2 (MR20/30H/33/42/42E/52/53/53E/70/74/84): 256 clients per radio
• Wi-Fi 6 (MR36/44/45/46/46E/55/56/76/86): 512 clients per radio

Reference: https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Approximating_Maximum_Clients_per...

[PhilipDAth]

When you say "NAT on SSID" I'm going to assume you have this configured on the MR, rather than the MX.

https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/NAT_Mode_with_Meraki_DHCP 

When using NAT mode on an MR the DHCP address is calculated by hashing the client's MAC address.  This is done to avoid DHCP starvation attacks on guest WiFi.  Consequently, you will always get the same private IP address, no matter which Meraki AP you connect to - in the whole world - configured in this mode.

I do not know the NAT timeout.  I have not experienced any issues with NAT timeouts.

The DHCP lease time, on an MX or MR (when not in NAT mode), is whatever you configure it to be.

I've done corporate Wifi using /22 (1024 devices) and that has worked fine using lower-spec Cisco Meraki kit, and I've done nothing special.  I suspect a /21 (2048) wouldn't not be that much worse.

I think only using 4 x MR56's might not be enough though.  That is like 500 devices per AP.  That sounds like way too many.  I'm not sure you can even connect more than 128 clients at a time.

If you allowed for 50 clients per AP (which is still a lot) you would need closer to 40 APs.

So in conclusion - I think you will need a lot more APs if you want 2,000 connected clients.

[JDavie]

Hey, thanks for the reply.

Yes, you are correct, NAT mode is enabled on the MR rather than the MX, like in the article you linked.

While 16.7 million is a lot of addresses, that is a lot less then there are MAC addresses out there. At our current rate, we ourselves could use all that up in around 15 years. Are IP addresses able to used again?

The reason why the device would get the same IP address is because the hash of its MAC address would be the same. If another device attempts to connect to the network and produces the same hash, and the original device is not connected to the network, the new device would be able to connect correct? That address would not be "reserved" for the original device. Just want to make sure I am understanding all this correctly.

Thanks for brining up the concern about our limited number of APs. I was unaware of the 512 clients per radio with Wifi 6. Each device sends a very limited amount of data, its pretty much just a handshake with the enrollment server. With that limited amount of data flowing though the AP's would that allow for us to get closer to the theoretical limits?

[PhilipDAth]

> I was unaware of the 512 clients per radio with Wifi 6. 

That is the technical maximum limit.  You will undoubtedly run into issues if you run it exactly on that limit.  I would try and get down to at least 100 connected clients per AP.  At that limit, it should work as long as you have very low data transfer rates and assuming no one else in your vicinity is using up the WiFi spectrum and that you are only using 5Ghz spectrum.

I have not run into any "hash" collisions using the NAT functionality.  And with only 2,000 clients at a time and with 16.7 million addresses available - I would suggest this is never going to be an issue for you.  I would suggest you are more likely to be struck by lightning, twice, than for this to occur (to help you see the perspective).

https://www.cbs17.com/news/odds-of-winning-powerball-jackpot-less-than-being-hit-by-lightning-twice/ 

I would also not attempt to try and project today's technology into a use case 15 years from now.  I don't know what it will be like in 15 years - but I know it will be completely different to it is now.  Any current networking kit will have been long since thrown away.

[JDavie]

I agree that we definitely won't be able to get near 512 per radio, even so, the AP's we have contain 4 radios (2 for 2.4G and 2 for 5G), we should be able to use both spectrums. Would 300 clients per radio be reasonable to assume? That's just under 60% of the theoretical limits. That would put us at 1200 clients per AP. I definitely understand where you are coming from and now share your concern, I just am not getting how you are arriving at 100 clients per AP. 

My concern over hash collision stems for the idea that once your device connect to any Meraki system, if that IP address is "reserved" just for that first device. Say 5 years ago, someone's laptop at coffee shop in Japan made the same hash as a device we are setting up, would we be able to use that address? That's what I was referring to with the whole 15 years thing. I am sure we will have swapped out our gear by then. I was just trying to point out that if addresses are saved globally, how quickly we could "exhaust the global Meraki NAT IP Address pool".

Thank you for your help and patience while I am trying to understand everything.

[PhilipDAth]

2.4Ghz can't be used for dense deployments.  You should disable 2.4Ghz on the SSID.

Typically I design for 20 clients per AP, which gives excellent results.  I don't deliberately go over 50 as the performance tends to drop off a lot.  So I doubled the worst number I wanted to see - 100.

To manage 300 clients I would think you would have to have a pristine RF spectrum.  Perhaps if you build your own Faraday cage and do everything inside of that to get rid of the effects from the outside world.  Even then, I think you would crash and burn.

I found this article which gives some understanding of the maths and why this is not going to work.

http://divdyn.com/wi-fi-throughput/ 

The IP addresses are not reserved.  They are the result of a simple hash.  The whole point is so the system does not have to track them so that it can survive a starvation attack.

To make it even clearer - it is a stateless DHCP server.  Nothing about the DHCP addresses being given out is stored anywhere.

[JDavie]

Thank you for explain and clarifying everything. I feel like I understand it all now. I was really overthinking the NAT DHCP.

Thank you so much for all the help, it went a long way.

[cmr]

@JDavie to add to @PhilipDAth's post, you only have 2 radios one 2.4GHz and one 5GHz, they just have multiple streams each.

[JDavie]

Ah, I see now it has 1 for WIDS/WIPS, and 1 for bluetooth. I just saw the total 4 and assumed it was 2x for 2.4 and 2x for 5. Thanks!