Satellite Internet as WISP Backhaul: Living With CGNAT
What Carrier-Grade NAT actually means for a WISP using satellite internet as an uplink, and a working way to still manage the router remotely.
Low-earth-orbit (LEO) satellite internet has become a common backhaul choice for small WISPs in areas without reliable fiber — it's fast to deploy and doesn't depend on local infrastructure. But most consumer satellite ISPs share one architectural detail that catches new operators off guard: your router's WAN interface never gets a real public IP address.
What CGNAT actually is
Carrier-Grade NAT (CGNAT) is your satellite provider sharing a pool of public IPv4 addresses across many customers simultaneously, the same way your router shares one public IP across many subscribers via masquerade — just one layer further up. Your router's WAN interface gets an address from the range 100.64.0.0/10, reserved specifically for this purpose under RFC 6598. That address is real and routable on the provider's internal network, but it is not a public internet address — nothing outside that network can initiate a connection to it.
How to tell if you're behind CGNAT: check your router's WAN IP. If it starts with 100.64 through 100.127, you're behind CGNAT. Compare it to what a site like whatismyip.com reports from a device on that connection — if they're different, there's NAT happening between your router and the public internet.
What this changes in practice
- No inbound connections work — not Winbox, not a port-forwarded camera, not a self-hosted service. It doesn't matter how the firewall is configured; the connection never reaches the router because the WAN IP isn't publicly reachable at all.
- Port forwarding is not fixable with router configuration — this is a common point of confusion. A correctly configured
dst-natrule does nothing if the packet never arrives at the WAN interface in the first place. - Outbound connections are unaffected — subscribers can browse the internet normally, since NAT (both the provider's and your own) only blocks unsolicited inbound traffic, not traffic initiated from inside your network.
The practical workaround: an outbound-initiated tunnel
Since the router can always reach out even though nothing can reach in, the standard fix is a VPN tunnel that the router itself initiates toward a server with a real public IP — typically a small VPS. Once the tunnel is up, you connect to the VPS, and the VPS forwards your management traffic through the tunnel to the router. WireGuard is the simplest modern option on RouterOS for this.
The setup, at a high level
| Component | Role |
|---|---|
| VPS (Contabo, DigitalOcean, etc.) | Has a real public IP. Runs the WireGuard server side. |
| MikroTik router | Runs the WireGuard client side, initiates the tunnel outbound — this works fine even behind CGNAT since it's an outbound connection. |
| Your laptop | Connects to the VPS (or its own WireGuard client), reaching the router through the tunnel. |
Once configured, Winbox, SSH, or the API can all be reached through the tunnel's IP address as if you were on the router's own LAN — CGNAT on the WAN side becomes irrelevant for management purposes.
Set this up before you need it. A router only reachable through a tunnel that isn't configured yet is a router you can't fix remotely if something goes wrong. Build the WireGuard tunnel as part of initial deployment, not as an emergency measure after a lockout.
What CGNAT doesn't affect
It's worth being precise about the boundary here, since it's easy to over-apply this concern:
- RADIUS still works normally if your RADIUS server is on the same LAN as the router, or reachable through the same tunnel — CGNAT only affects the WAN-facing side.
- PPPoE and Hotspot for subscribers are unaffected — those services run on your subscriber-facing interface, not the WAN interface behind CGNAT.
- Outbound-initiated services like a router phoning home to a monitoring platform, or NTP time sync, work exactly as they would with a public IP.
Common mistakes and how to fix them
| Symptom | Likely cause | Fix |
|---|---|---|
| Port forward configured correctly but still unreachable from outside | WAN interface is behind CGNAT — the packet never arrives | Confirm the WAN IP is in 100.64.0.0/10; if so, port forwarding cannot work without a different approach (tunnel, or a business-tier plan with a real public IP if your provider offers one in your region) |
| Lost remote access to a router after a network change | No VPN tunnel was configured before the change, and CGNAT means no direct fallback | Requires physical access to reconfigure — this is exactly why the tunnel should exist before it's needed |
| WireGuard tunnel drops intermittently | The provider's own IP reassignment behind CGNAT can occasionally interrupt long-lived connections | Set a reasonable WireGuard keepalive interval (25–30 seconds) so the tunnel re-establishes quickly after any interruption |
Best practices
- Set up a WireGuard tunnel to a VPS as part of initial deployment, not after something breaks.
- Don't rely on port forwarding for anything on a CGNAT-behind connection — plan around a tunnel from the start.
- Document the VPS's IP and the tunnel configuration somewhere accessible outside the router itself.
- Test remote access through the tunnel before you actually need it in an emergency, not during one.
Hardening the router itself?
The NAT + Firewall generator covers WAN-side hardening that applies whether or not you're behind CGNAT.
Open the NAT + Firewall Generator →