Using Meraki Guest Network where MX is on a 10.x.x.x network

[DHAnderson]

I have a client where the previous network engineer put all the devices on a 10.63.145.0/24 subnet. 

I want to use the Guest Network on a MR series access point, but that uses a 10.0.0.0/8 subnet.  I am guessing that there will be potential clashes if I try this, but does anyone know if MR Access Point is smart enough that it will not allocate its own IP address in its DHCP pool for the Guest Network?

[PhilipDAth]

The MR when running in guest mode and giving out 10/8 addresses doesn't actually run a DHCP server - it just looks that way.  You could easily create a DOS attack on it if it did, as a guest could use random MAC addresses and send DHCP requests until the pool of IP addresses was exhausted.

What is does instead is take a hash of your MAC address and calculate an IP address from that.  As a result, no matter which AP you connect to in this mode your machine will always get the same IP address.  This is also how it handles roaming between APs in this mode (otherwise you could potentially get IP address conflicts roaming between these APs).

[DHAnderson]

Thanks for your response.  So then it is possible, but perhaps unlikely that an address of a device could be that same as that of the MR if the MR address is in the 10.0.0.0/8 range.  Correct?

[PhilipDAth · Accepted solution]

I would say it would be improbable.

The 10.x part uses 8 bits, so that leaves 24 bits after that.  2^24 is - a big number.  So I would say you are pretty safe.

[NolanHerring]

Are you saying the SSID is using NAT mode? The LAN 10.63.145.0/24 wouldn't interfere even if a client landed on that subnet if using NAT mode, as it just see's the AP IP which is on the LAN side.

[DHAnderson]

If Murphy (author or many laws) decided to give a Nat address to a client that is the same address the the AP has, NAT will get confused. At the very least, no packets will ever get to the NAT client.  At the very worse, nobody tested this and the access point will tip over.

I agree that given how the Guest Network works, this is very unlikely to happen, but Murphy likes those kind of challenges.

[NolanHerring]

NAT mode means the client IP in the 10.0.0.0/8 never gets 'seen' on the LAN side. It just see's [AP-IPADDRESS:port].

Unless I have somehow completely misunderstood how NAT mode works with Meraki lol

From the client's perspective, its gateway/DHCP/DNS is the AP (10.128.128.128). If the client gets an IP of say 10.1.2.3, only the AP will know about that, nothing on the LAN side should see that.

[NolanHerring]

I guess the only scenario that I can think of (and maybe it is what you were thinking of but I missed the point), is if the client happens to receive 10.128.128.128 as his IP.

Maaaaaaaaaybe that's possible but I would like to think the Meraki went out of their way to exclude that IP as an ever possible choice for its random DHCP algorithm + MAC hashing etc.

[DHAnderson]

That is exactly what I am thinking, and I agree it is highly unlikely.  Did Meraki test that?  Great question!

Going back to Murphy, I think I should avoid the issue until I can change the Lan to something not 10.x.x.x.  The client can get by on a 172 address or even a 192 address.

In the mean time I can use bridge mode, use Layer 2 isolation and block all access to the Lan in the firewall.

Thanks to all who have chimed in!

- Dave

[NolanHerring]

@MerakiDave  Hey Dave, do you by chance know if 10.128.128.128 is automatically excluded as a possible IP a client will receive, from the pool of 10.0.0.0/8 when NAT mode is used?

Thanks and sorry to bug you 😃

[NolanHerring]

Also, another fun fact @DHAnderson is that NAT mode, while it works great for what it does, does not allow seamless roaming.  =(

Roaming - NAT mode with Meraki DHCP will use the IP address of the AP as the public IP address for wireless clients. When a client roams between APs with Meraki DHCP, TCP connections will drop and have to be re-established. This can cause problems with some applications and devices.

This is why I tend to go out of my way to create a guest VLAN etc., so that I can use bridge-mode.

[BrechtSchamp]

In this doc page it's clarified:

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

"The DHCP service for NAT mode will only hand out addresses in the 10.0.0.0/8 subnet. SSIDs in NAT mode can still be used on wired networks already using a 10.x.x.x address space, however clients on the NAT SSID may be unable to communicate with these networks."

So for access towards the internet and where clients don't really need to access the internet that's not an issue. Which is probably most cases as this is really meant for guest.

I'm pretty sure the hashing algorithm will not hand out 10.128.128.128 to a client. In fact it's very probable from a more general perspective that there is a contingency mechanism to choose a new address in case of a hash collision/clash. In other words if an address already in use on that AP/SSID. This seems bound to happen as there are many more MAC-addresses than there are IP-addresses in the 10.x.x.x/8 range.

[NolanHerring]

---

@BrechtSchamp wrote:

however clients on the NAT SSID may be unable to communicate with these networks."

---

Thanks for the link @BrechtSchamp 

That statement on the document seem's a little vague to me though, no?

So maybe I'm misunderstanding something fundamental here.  The AP is NAT'ing, so I'm not seeing how the client behind it getting  (lets just pretend 10.1.1.1) will ever be able to have an issue with a LAN side client or device that might also have 10.1.1.1 (coincidentally).  I always viewed this as like RFC1918 over the Internet. Issues don't happen, because its being NAT'ed via the public IP. 

In this case the 'public IP' being the IP of the AP.  The client won't even know what that IP is since he'll only ever know about 10.128.128.128

The only thing I can think of is if the client gets 10.128.128.128 (either unlikely or not possible via Meraki doing something behind the scenes), or two clients get the same IP, but would that matter either since NAT/and isolation?

I hate it when I start to overthink stuff like this lol

[BrechtSchamp]

---

@NolanHerring wrote:

---

That statement on the document seem's a little vague to me though, no?

So maybe I'm misunderstanding something fundamental here.  The AP is NAT'ing, so I'm not seeing how the client behind it getting  (lets just pretend 10.1.1.1) will ever be able to have an issue with a LAN side client or device that might also have 10.1.1.1 (coincidentally).  I always viewed this as like RFC1918 over the Internet. Issues don't happen, because its being NAT'ed via the public IP. 

In this case the 'public IP' being the IP of the AP.  The client won't even know what that IP is since he'll only ever know about 10.128.128.128

---

The problem here is that the subnet mask the client gets is 255.0.0.0 or /8. That means if it wants send a message to any address in the 10.x.x.x/8 range it'll try to use L2 (ARP) directly thinking it's a device in its own subnet instead of forwarding the traffic via L3 to its default gateway.

---

@NolanHerring wrote:

---

The only thing I can think of is if the client gets 10.128.128.128 (either unlikely or not possible via Meraki doing something behind the scenes), or two clients get the same IP, but would that matter either since NAT/and isolation?

---

Now that you mention it, it may indeed be no issue if two clients have the same IP address as they don't need to communicate with each other. But then the AP needs to do some magic to keep track of both and not mix them up.

[DHAnderson]

Assume for the time being that the public IP of the access point is 10.128.128.128.  Also assume Client A gets the same 10.128.128.128.  If we also assume the access point acts like a switch with NAT capability, there will be two entries in a MAC to IP table for 10.128.128.128.  This should cause an IP conflict and traffic to that IP address may get dropped.