Two ISPs is easy. Two ISPs that fail over cleanly, don't leak transit, keep the same public IPs, and place NAT where it belongs — that's an architecture. This is the design of a resilient internet edge for a business, WISP, or multi-site org, from address ownership to CGNAT placement.
The edge is where your network meets the internet, and its design decisions are the ones you can't easily change later: whose addresses do you use, how does failover actually work, and where does NAT sit. Get these right and adding capacity or a third ISP is routine; get them wrong and you're renumbering the whole estate the day you switch providers.
The core choice is provider-dependent vs provider-independent. If you use an ISP's addresses (PA) and one static IP, "multihoming" means dual-WAN failover with NAT — cheap, simple, but your public IP changes when the primary dies, breaking inbound services. If you own your addresses (a PI block + an ASN) and speak BGP to both ISPs, you keep the same public IPs across a failover — the real multihomed edge, and mandatory for anyone hosting inbound services or running a WISP. This post is the architecture around those builds; the BGP config is its own pair of posts.
01
PA (provider-assigned) or PI (provider-independent) addresses. This one choice determines whether failover keeps your public IPs — and therefore whether inbound services survive it.
| Aspect | PA + dual-WAN NAT |
|---|---|
| Cost / complexity | Low — no ASN, no BGP |
| Public IP on failover | Changes (to backup ISP's) |
| Inbound services survive? | No (needs dynamic DNS hacks) |
| Good for | Outbound-only sites, SMB |
| Aspect | PI + BGP multihoming |
|---|---|
| Cost / complexity | Higher — ASN + PI block + BGP |
| Public IP on failover | Stays the same |
| Inbound services survive? | Yes — same IPs on both paths |
| Good for | Hosting, WISPs, multi-site orgs |
Most small businesses do not need BGP — a PA dual-WAN edge with clean IP-SLA failover is the right, cheap answer for outbound-heavy sites, and inbound services can live behind a cloud reverse proxy that hides the IP change. You cross into PI + BGP when you host services people connect to, run a WISP/ISP, or contractually can't have your public IP change. Don't sell BGP to a café; don't run a hosting business on dynamic DNS.
02
Two links can sit one-hot-one-cold, or both carry traffic. The choice shapes your BGP policy and your capacity planning.
Active/backup is simplest and usually correct: the primary carries everything, the backup idles until needed. In BGP terms that's local-preference for outbound and AS-path prepend to steer inbound onto the primary. Active/active uses both links concurrently for more aggregate throughput — but you must design for the failure case: if each link runs at 70% and one dies, the survivor can't absorb 140%, so you're really planning for each to sit under 50%. Active/active also makes inbound traffic engineering fiddly (you can only hint the internet, per the BGP posts). Default to active/backup unless you genuinely need the combined capacity and can live within the survivor's limit.
03
NAT placement is an architecture decision, not a checkbox. Put it in the wrong place and failover mangles traffic, or your subscriber platform can't scale. This is the piece the field always gets wrong.
For a PA dual-WAN edge, NAT lives at the edge router and must follow the live WAN — a masquerade/PAT rule per interface, keyed on egress, so translations move with the path on failover (the trap covered in the NAT and dual-WAN posts). For a BGP/PI edge with public space, internal hosts using public IPs may need no NAT at all — cleaner, but plan the firewall accordingly. For a WISP/ISP serving many subscribers behind limited IPv4, CGNAT (RFC 6598 / 100.64.0.0/10) sits at an aggregation point, not on every CPE — with per-subscriber port-block allocation and logging for lawful traceability. And the Starlink reality from the field notes: standard Starlink hands you CGNAT already, so it's outbound-survival only and can't host inbound — design around that on day one.
The recurring edge disaster is double-NAT: your router NATs, and the ISP also CGNATs (common on LTE and Starlink), so you have no real public IP and inbound port-forwards silently do nothing. Always confirm whether each uplink gives you a genuine public address or a CGNAT one — it changes the entire inbound design. If a backup path is CGNAT (LTE/Starlink), architect it as outbound-only and keep inbound services on the path that has a public IP, or front them with a VPN/reverse-proxy that dials out.
Takeaways
NOCTIS designs resilient internet edges across Crete — dual-WAN and BGP multihoming, correct NAT/CGNAT placement, and failover that keeps you online without breaking inbound services — for businesses and WISPs.
Book a Discovery Call →