32-bit network prefix via DHCP ?

[Richard_Velox]

Has Meraki been able to support this configuration in their gateway devices?

We have several customers who we've taken to setting up as 1:1 NAT from a private address to their public address as their Meraki routers were unable to correctly route traffic through the gateway provided.

[jdsilva]

Can you elaborate on the use case a bit more? I've never seen any DHCP server hand out /32's... Not to say that it can't happen, I'm just curious to understand why you would need that and how it works in practice. 

[Richard_Velox]

We're a small WISP that's been allocated a small sliver of IPv4 addresses and we're a little stingy about needlessly allocating them; Also the scheme is incredibly flexible. Most vendor's routers work with this allocation scheme like Sonicwall, Unifi, Cisco-Linksys, AirCube, some Edgerouter, Watchguard, some? Asus, Fortigate) and others need 1:1 NAT like PFSENSE, Meraki, Luxul. Routing between towers is accomplished using OSPF. An event triggered script can add the route or it can be added to the configuration. Gateways have IPs in the 100.64.0.0/10 range.

[Nash]

---

@Richard_Velox wrote:

We're a small WISP that's been allocated a small sliver of IPv4 addresses and we're a little stingy about needlessly allocating them; Also the scheme is incredibly flexible. Most vendor's routers work with this allocation scheme like Sonicwall, Unifi, Cisco-Linksys, AirCube, some Edgerouter, Watchguard, some? Asus, Fortigate) and others need 1:1 NAT like PFSENSE, Meraki, Luxul. Routing between towers is accomplished using OSPF. An event triggered script can add the route or it can be added to the configuration. Gateways have IPs in the 100.64.0.0/10 range.

---

Have you tried the "asking ARIN for an IPv6 allocation and a wee bit of IPv4 to help with your transition" trick? 😉 Assuming ARIN is your people!

@MerakiDave and his friends might be able to give us a conclusive answer. But I suspect that if it hasn't worked before, you're going to have to stick with providing NAT to your customers.

How's using that space been working for your customers? Have you got yourself setup so they can use VPNs, or nah? I'm eternally curious about WISPs!

[PhilipDAth]

ARIN ran out of IPv4 address space a good year ago.  Maybe longer.

Have you considered using PPPoE?  This will allow you to use a /32 with pretty much every vendor.

You could run either PPPoE servers near your edge radios, and use OSPF to redistribute those routes back towards your network core, or run a central PPPoE server.

You don't have to use authentication either if the only goal is to use /32's in the most efficient manner possible.

You could also use hybrid approaches.  Using private IP addresses out of a larger pool for those customers where it does not matter, and PPPoE only for those that need a fixed static IP address.

I did this once in a student residence.  Everyone was allowed to access internal resources, but only those that paid got Internet access.  I used PPPoE for those paying customers.  Everyone else could just plugin and get a private IP address via DHCP.

This approach also meant the paying customers could plug in anywhere in the facility to use their Internet.

Going back to the DHCP option.  Is there a reason you can't allocate each tower a prefix (or each layer 2 domain), and simply DHCP out of that using the prefix size instead of a /32?

[Nash]

---

@PhilipDAth wrote:

ARIN ran out of IPv4 address space a good year ago.  Maybe longer.

hehehe. "ran out"... except... if you can prove you're working on IPv6 transition.

Although proving that is challenging if half your sites have no physical addresses and don't show up on satellite photos b/c they're underground, I am told!

[Richard_Velox]

@Nash ARIN is, however seeing as we already have IPv4 & IPv6 netblocks from them I don't expect that request to be well received although we could always try. We fairly recently graduated from using our provider's addresses to using our own, thanks in part to the addresses recovered by ARIN from fraudulent allocations.

That address space works well except for the odd client who's expecting to have a publicly routeable address. Do you mean a VPN in to access their private address? We don't have remote VPN access into our network for clients. Outbound VPNs should work without issue and I've seen an established session on two. Inbound VPNs to servers behind NAT are a different story depending on the client; iPhone, Android and others work without issue however Windows needs a registry key set to allow connections to a server that's behind NAT(https://support.microsoft.com/en-us/help/926179/how-to-configure-an-l2tp-ipsec-server-behind-a-nat-t...) I guess that's just another GPO setting for AD.

@PhilipDAth 

We haven't really considered PPPoE mostly because I thought of it being something that would be setup centrally and less amenable to failover in case of a loss of connectivity to the central site; considerations for MTU overhead and the failures associated with firewalls indiscriminately blocking ICMP and disrupting PMTU discovery included.

Having different VLANs for DHCP and PPPoE with different MTUs would help. The settings on the radio would need to be statically set. I don't know how well client implementations would handle interface MTUs > 1500 to offset the associated overhead. Redistributing routes into OSPF was less clear though I have to admit I didn't test the setup.

Our customers are either behind NAT or have a routeable public IP. This is a legacy of the circumstances of our development. We began using our provider's IPs with all but a few customers behind NAT and even then we were reluctant to assign customers more that one IP and having to change all of our customers public IPs when we needed more addresses due to the policy of our provider to only assign a single prefix wasn't particularly encouraging. Having to bridge our upstream connection through our routers to customers wasn't particularly appealing for a number of reasons; partly due to limitations with their offloading capabilities and layer 2 security.

With a router on each tower consuming ~84 addresses for network, router, and broadcast as well as being inflexible in regards to prefix allocation; customers aren't necessarily prepared to deal with having their static IP reassigned. The 32-bit prefix solution looked preferable.