IP Address Planning for a Growing WISP
How to lay out subnets, pools, and CGNAT ranges before you run out of room — written for operators past the "just use 192.168.1.0/24 everywhere" stage.
Most WISPs start with whatever addressing scheme came pre-configured on the first router — usually 192.168.1.0/24 or 10.10.10.0/24 — and it works fine for the first dozen subscribers. The trouble starts around 40–60 subscribers across two or three sectors, when someone needs a second pool, a management VLAN, or a second router, and the original scheme has no room to grow without renumbering something that's already live.
A little planning up front avoids almost all of this. None of it requires exotic knowledge — just deciding on a structure before you need it, not after.
Start from a private range with real room to grow
The three private IPv4 ranges (RFC 1918) aren't equal in how much room they give you:
| Range | Size | Practical use for a WISP |
|---|---|---|
192.168.0.0/16 | 65,536 addresses | Fine for a single site or lab — too small to subnet cleanly across many sectors. |
172.16.0.0/12 | ~1 million addresses | Workable, but less commonly used — more collision risk if you ever merge networks (mergers, VPNs to partner ISPs). |
10.0.0.0/8 | ~16.7 million addresses | The standard choice for any ISP expecting to scale past a few hundred subscribers. |
Starting from 10.0.0.0/8 costs nothing and means you will not run into a hard ceiling later. The plan below assumes it, but the same structure works inside 172.16.0.0/12 if that's what you've already committed to.
A structure that scales: /24 per sector, grouped by function
Rather than one flat subnet for every subscriber, split addressing along two axes: what the subnet is for, and which physical sector or site it belongs to. A simple version:
| Octet 2 | Purpose |
|---|---|
10.0.x.x | Core infrastructure — routers, switches, management VLANs |
10.10–10.49.x.x | Subscriber pools, one /24 per sector (10.10 = Sector 1, 10.11 = Sector 2, ...) |
10.50–10.59.x.x | Point-to-point backhaul links between towers |
10.90.x.x | Hotspot / voucher subnets, kept separate from PPPoE subscribers |
10.99.x.x | Management-only — out-of-band access to routers themselves |
This gives every sector its own /24 (254 usable addresses — plenty for a single sector's subscriber count) and leaves 39 more sector blocks before you touch anything else. A new tower doesn't require renumbering an existing one — it just gets the next unused sector number.
Keep management addressing separate from subscriber addressing. If a subscriber pool and a router's own management IP live in the same subnet, a misconfigured client device can occasionally interfere with router reachability. A dedicated 10.99.x.x range for router management, reachable only via VPN, avoids this entirely.
Sizing a sector's /24 realistically
A /24 gives 254 usable host addresses. For PPPoE deployments this is rarely the limit — RADIUS assigns addresses per session, so the practical ceiling is closer to how many simultaneous sessions a sector's radios can actually carry. For Hotspot deployments, size the pool for peak concurrent devices, not just paying subscribers — phones and routers often hold a DHCP lease even when idle, and a sector with 100 subscribers might have 150+ leased addresses at any given moment.
If a sector genuinely needs more than 254 addresses, it's cleaner to split it into two logical sectors (each its own /24) than to move to a /23 — keeping every sector on a consistent, predictable /24 boundary makes firewall rules, monitoring, and troubleshooting simpler across the whole network.
Where CGNAT changes the picture
If your upstream connection — satellite internet or otherwise — sits behind Carrier-Grade NAT, your router's WAN interface never gets a real public IP; it gets a private address from the provider's own CGNAT range (commonly 100.64.0.0/10, reserved specifically for this by RFC 6598). This is separate from your internal addressing plan, but it directly affects two things:
- You can't be reached from the public internet on that WAN interface — no incoming connections, no simple port forward to a device behind it, regardless of firewall rules.
- Remote management needs a workaround — typically a VPN tunnel (WireGuard) initiated outbound from the router to a VPS with a real public IP, since the router can always reach out even though nothing can reach in.
See the satellite internet and CGNAT article for the full reasoning and a working WireGuard setup.
A worked example
A WISP with 3 sectors, a Hotspot deployment at one location, and 4 towers connected by backhaul links might lay out addressing like this:
| Subnet | Assignment |
|---|---|
10.0.0.0/24 | Core router and switch management |
10.10.0.0/24 | Sector 1 — PPPoE subscriber pool |
10.11.0.0/24 | Sector 2 — PPPoE subscriber pool |
10.12.0.0/24 | Sector 3 — PPPoE subscriber pool |
10.50.0.0/30–10.50.0.12/30 | Point-to-point links, tower-to-tower (4 towers = 3 links, /30 each) |
10.90.0.0/24 | Hotspot voucher subnet, main office location |
10.99.0.0/24 | Router management, reachable only via WireGuard |
Adding a fourth sector later is just 10.13.0.0/24 — no renumbering, no overlap risk, no surprises.
Common mistakes and how to fix them
| Symptom | Likely cause | Fix |
|---|---|---|
| Two sectors occasionally see each other's subscriber traffic | Overlapping subnets from ad-hoc addressing (both using 192.168.1.0/24 independently, later bridged) | Renumber one sector to a non-overlapping block — painful once, unnecessary if planned up front |
| Ran out of address space in a sector's pool | Sector grew past 254 devices without a plan for a second block | Split into two logical sectors, each its own /24, rather than expanding to a /23 that breaks the consistent boundary |
| Can't add a VPN client subnet without conflicts | No reserved range was set aside for future use | Always leave 5–10 unused /24 blocks in the plan from day one — they cost nothing until needed |
| Router management interface briefly unreachable when a subscriber's device misbehaves | Management IP shares a subnet with subscriber pool | Move router management to its own dedicated, VPN-only subnet |
Best practices
- Start from
10.0.0.0/8even if you only need a fraction of it today — there's no cost to reserving room. - Keep every sector on a consistent /24 boundary rather than mixing subnet sizes across the network.
- Separate subscriber pools, backhaul links, and router management into distinct ranges from the start.
- Document the plan somewhere outside the routers themselves — a spreadsheet or wiki page that survives a factory reset.
- Reserve unused blocks deliberately rather than assigning sequentially — it's easier to skip a number than to renumber a live sector later.
Setting up a new sector?
The PPPoE and Hotspot generators on this site build the RADIUS and pool configuration once you've decided on the addressing — fill in your chosen subnet and get a ready-to-import script.
Open the PPPoE Generator →