APs from different vendors give out IP addresses in vastly different ranges - roaming affected negatively?

Question

In his encyclopedic answer here, @Spiff touches upon a ton of wireless access point issues, but not the ONE detail I'm looking for!

I'm supporting a pre-Cisco buy-out Meraki wireless network that gives every guest an account in the 10.x.y.z scope, which is awesome. The internal addresses for the Merakis were all on our main 192.168.168.x scope, but because of their guest configuration, it was never an issue.

However, I've finally come up empty trying to find replacements on ebay, and finally broke down and bought a few similarly priced TP-Link APs. Put one on the same switch, configured it to have the same security and SSID. Turns out that while they are as unmanaged as the Merakis, they aren't as smart, and immediately started putting customers phones directly on our main network 192.168.168.x. (To be clear, they defaulted to using the only DHCP server available, THE server, which had only the one scope to put the guests on. Not a misconfiguration on TP-Link's part, just a different (albeit worse) default configuration than the Merakis. The TP-Link solution is to purchase a TP-Link L3 switch that can create VLANs by itself.)

I head to the server and SonicWall interfaces to figure out how to put all of the wireless gear on their very own VLAN. A few days and much head- (and butt-)scratching later, all of the Meraki APs and the tester TP-Link AP are on new VLAN, on a new DHCP scope, handed out by the SonicWall firewall, so they all have internally facing 192.168.2.x. However, clients connected to the Merakis are getting 10.x.y.z IP addresses, and the TP-Links are deferring to the SonicWall, which gives out 192.168.2.x addresses to guests.

TO THE QUESTIONS, AT LONG LAST: I assume that when a guest is roaming over the Meraki network between various APs, they maintain the same IP address.

1. Will that roaming still work between such different make and model APs?
2. If so, will the massively different IP addresses for the guests either a) slow down the handoff, or b) create browsing issues?

At the end of the day, all of the traffic to the internet is coming out of the same external IP address on the SonicWall, so an external server shouldn't necessarily be noticing them changing IP addresses...

The long-term goal IS to replace the Merakis as they die, so this doesn't need to be a forever solution.

Edit to add: I don't see any way to change the default Meraki behavior of using the 10.0.0.0/8 address pool for clients, and I'd apparently need to buy the aforementioned TP-Link L3 switch to also be able to manage them and what addresses they hand out. But even there, I'd don't know that I'd have a solid way to reserve a chunk of the 10.0.0.0/8 addresses to avoid conflicts with the Merakis.

Answer 1

You would need really really short lease times. Better is to configure things appropriately.

You should be able to terminate all of the APs uplinks at a switch (or two) and have them all talking among themselves, plug the switches into a router of some sort, one side on your "private" LAN and one side on the wireless network, and have it run its own DHCP server on the wireless network side. Really trivial to set up using a old machine with 2 NICs running Linux.

BUT ... you should be aware that just NATing out the guest network through your regular internal LAN, if a guest user knows an IP (or range) they could conceivably connect. Better to use said router above and have the "outside" leg end up in your DMZ or other place on the "edge" of your network, so it is truly "outside" of your internal LAN.

Answer 2

Wi-Fi clients generally expect that all in-range APs publishing the same network name (SSID) will be transparently bridging their traffic onto the same Ethernet [V]LAN, and thus the same IP subnet with the same router and same DHCP server.

If I've read your Question correctly, it sounds like you've got a situation where you have a single guest network SSID, but depending on which AP the client roams to (Meraki vs. TP-Link), it's actually a different [V]LAN underneath with a different valid IP subnet and a different NAPT gateway. This will definitely cause roaming problems of various kinds for your clients.

Some rudimentary clients may not realize their need to double-check their DHCP lease via DNAv4 or other means, and just end up in a broken state where they have Wi-Fi link up but don't have a valid IP address that lets them get anywhere. Users of such clients will likely need to turn their Wi-Fi interface off and back on, or do something else to force a DHCP renewal.

More reasonable clients will use DNAv4 or other means to check their DHCP lease, realize they were lied to and now they're on a different network after all, and proceed to get a new DHCP lease on the new subnet. Not only will this slow down roaming, it will also cause all established connections to drop. So you just lost all your SSH sessions, your big in-progress downloads, your VoIP calls, your video streams, your fileserver mounts, your online game sessions, etc.

I don't know the limitations of your old-school Meraki APs, but my best advice to you is to make it so that all of the APs publishing the guest SSID are all simply transparently bridging that traffic onto a single guest VLAN with a single subnet, a single NAPT gateway router, and a single DHCP server.