Double-NAT on UniFi: ISP bridge mode, IP passthrough, and CGNAT

Open the UniFi Network application. Navigate to Settings → Internet (or, on older builds, Settings → Internet → WAN1). Look at the WAN interface's assigned IP address. That single value tells you which scenario you're in.

For the home-side case, the WAN IP will almost always be in 192.168.0.0/16: most consumer ISP gateways hand out 192.168.0.x or 192.168.1.x by default. For CGNAT, the address starts with 100.and the second octet is between 64 and 127. Ubiquiti's own “Setting Up Public Access to Local Resources” article calls this out explicitly:

“Many ISPs use Carrier-Grade NAT (CGNAT) to conserve IPv4 addresses by sharing a single public IP among multiple customers. If your UniFi Gateway has a WAN IP address in one of the following ranges: 100.64.0.0/10 (100.64.0.0 – 100.127.255.255), you can try to re-configure your ISP modem/router into bridge mode so that your UniFi Gateway can obtain a public IP address on the WAN interface.”⁶

A second sanity check: visit whatismyip.com(or any equivalent) from a device behind the UniFi gateway. Compare the IP that site reports with the UniFi WAN IP. If they match, you're not double-NATted — the UniFi gateway has the real public address. If they don't match, the site is showing you the IP of the device closer to the internet, which means there's a NAT layer between the UniFi gateway and the public internet — that's the symptom of double-NAT.

Day-to-day outbound traffic — web browsing, streaming, most apps on phones and laptops — is unaffected by double-NAT. The protocols that break are the ones that depend on a host outside the home being able to reach a service inside the home. Six categories matter in a residential UniFi install:

1. Port-forwarding

A port-forward rule on the UniFi gateway only works for the network directlyin front of UniFi. Double-NAT means you have to also create a matching port-forward on the upstream ISP router — to send the inbound traffic from the ISP's public IP through to the UniFi WAN address. Two configurations, two vendors' firmware, two firmware-update cycles. In practice this is where most homeowners give up.

2. The gateway's WireGuard VPN server

Ubiquiti's own remote-access guidance reads, on itsUniFi Remote Access: VPN and Port Forwarding page, that “for Port Forwarding and most VPNs (excluding Teleport), a Public IP is necessary for connectivity.”⁷ The default UDP 51820 port the WireGuard server listens on needs to be reachable from the public internet for clients to connect. Under double-NAT, that means a port-forward on the ISP router — same configuration burden as #1. Under CGNAT, it is impossible from the customer side.

3. UniFi Site Magic

Site Magic is Ubiquiti's site-to-site SD-WAN feature — automatic VPN tunnels between two or more UniFi sites, brokered through the UniFi cloud. The help center page Setting Up SD-WAN with UniFi Site Magic states that at least one of the participating gateways must have a public IP for the tunnel to establish.⁸ Two sites both behind double-NAT cannot peer using Site Magic; one of them has to get a real WAN address first.

4. IPv6 prefix delegation

This is the most-misunderstood category. IPv6 itself doesn't do NAT in this scenario — there are enough IPv6 addresses that nothing needs to be translated. What does break is DHCPv6 prefix delegation chaining: the protocol by which an upstream router hands a downstream router a routable IPv6 block (a /60 or /56) to sub-delegate to its own LAN interfaces. Most ISP-supplied consumer routers do not act as requesting routers on behalf of a downstream router — they only delegate to themselves. The downstream UniFi gateway gets a single /64 on its WAN interface, and downstream LAN clients either get no IPv6 at all or get addresses that aren't routable on the wider internet. Ubiquiti documents this directly:

“Generally, the UniFi gateway should be directly connected to the ISP instead of behind a router … If you are only provided a single /64 IPv6 range or it is not working, it is possible that the ISP does not support connecting another router behind their equipment — an indicator is that the UniFi gateway has Internet access, however clients behind the UniFi gateway receive IPv6 addresses but do not have Internet access.”¹⁰

IETF RFC 7084 sets out the formal requirements a customer-edge IPv6 router should meet, including DHCPv6 prefix-delegation behaviour — implementations that don't are common in consumer gear.¹¹

5. Console gaming (Xbox, PlayStation), some real-time apps

Microsoft's support documentation classifies each console's NAT type as Open, Moderate, or Strict; double-NAT typically results in Strict NAT, which Microsoft's“Double NAT detected” support page identifies as the cause of party-chat failures, matchmaking problems, and reduced peer-to-peer game quality.¹² Bungie's Destiny troubleshooting page covers the same ground for game connectivity in general.¹³ The fix on the console-side is the same fix on the network-side: get the UniFi gateway a real public IP, or accept the limitation.

6. SIP / VoIP and IPsec passthrough

SIP-based VoIP often misbehaves under double-NAT because the SIP protocol carries the caller's announced IP address inside the application payload, which the second NAT layer doesn't rewrite. Cisco's support documentation on NAT in VoIP covers the standard mechanisms — STUN, TURN, ICE — for negotiating around NAT, and the cases where they fail.¹⁴ IPsec is mostly fine on modern stacks because of NAT Traversal (RFC 3947 / RFC 3948, UDP encapsulation on 4500), but legacy ESP-only IPsec — IP protocol 50, no L4 port to map — cannot cross a second NAT layer.¹⁵

One protocol worth singling out as quietly broken under double-NAT: UPnP. UPnP advertises and discovers a single upstream Internet Gateway Device via multicast SSDP, then signs port mappings against that one device. When two NATs are stacked, an application using UPnP opens a port on the inner router only — the outer router still drops the inbound traffic. UPnP is already off by default on UniFi gateways for security reasons; under double-NAT it would not work even if it were on.

Carriers and homeowners use these three terms interchangeably. They are not the same thing.

Bridge mode

The ISP device stops routing and stops doing NAT entirely — it acts as a transparent Layer-2 bridge between the WAN interface and one of its LAN ports. The public IP gets handed via DHCP directly to the UniFi gateway's WAN interface, where it appears as a normal public address. This is the cleanest option. Side effects: the ISP device's own Wi-Fi, voice lines, and management features usually stop working, because the device is no longer routing.

IP passthrough

The ISP device keeps routing — it still has its own management plane, its own Wi-Fi if applicable, its own voice lines — but it passes the public WAN IP through to a designated downstream device (the UniFi gateway). AT&T's residential fiber gateways and Verizon's 5G Home gateway use this model because they need to keep their own management plane alive for the carrier. The end-user effect is identical to bridge mode for practical purposes: the UniFi gateway gets a real public IP. The difference is internal — there's still a second device performing some functions.

DMZ / exposed host

A workaround when neither bridge mode nor IP passthrough is available. The ISP device keeps doing NAT but forwards all inbound traffic to one designated downstream device. The UniFi gateway still sees a private WAN IP, double-NAT is still technically in effect, but inbound port-forwards work the way they would on a real public IP. The trade-off is that end-to-end connectivity tools (Site Magic, IPv6 PD, detection of the real public address) still see the private WAN and may misbehave.

In order of preference: bridge mode, then IP passthrough, then DMZ, then accept double-NAT and use remote-access patterns that work behind two NATs (Teleport, Tailscale, Cloudflare Tunnel — see § 07).

Each ISP exposes the feature differently, and several require a phone call rather than a self-service web toggle. Primary-source links are given for each. Verify in your account portal before assuming a feature is available on your specific account / region.

Verizon Fios (G1100, G3100, CR1000A series)

Verizon's residential fiber gateways support IP passthrough mode through the gateway's admin interface (192.168.1.1, sign in with the admin password printed on the device). Verizon's own knowledge-base article Configure IP Passthrough / Bridge Mode documents the steps.¹⁶ In addition, the historical homeowner workaround — a physical ONT bypass that wires the fiber ONT directly to the UniFi gateway WAN, eliminating the Verizon router entirely — is well-documented in community projects.¹⁷ IP passthrough is the simpler choice for most Fios homes; the ONT bypass is for installs that want zero Verizon hardware involved at all.

Verizon 5G Home Internet

Verizon's 5G Home Internet Gateway exposes an IP-passthrough toggle through the My Verizon app on modern firmware. The Verizon community knowledge article on this is the canonical source; older firmware builds had the feature disabled in the consumer-facing app and required a call to support to enable.¹⁸ Caveat: Verizon 5G Home occasionally provisions customers on CGNAT depending on the cell-site loading, in which case even with IP passthrough enabled the WAN IP on the UniFi gateway will still be in 100.64.0.0/10.

Comcast / Xfinity (XB6 / XB7 / XB8)

Bridge mode is a one-click toggle in the Xfinity admin interface (10.0.0.1), or through the Xfinity app. The vendor's own Use Bridge Mode on your wireless gateway article documents the steps.¹⁹ Enabling bridge mode disables xFi, xFi Pods, and xFi Advanced Security — features that depend on the gateway acting as the home router. One thing that is not automatically disabled by bridge mode is the Xfinity public Wi-Fi hotspot SSID that the gateway broadcasts for other Xfinity customers; that is a separate setting in the Xfinity app and should be turned off explicitly.

AT&T Fiber (BGW210, BGW320)

AT&T's residential fiber gateways do not offer a true bridge mode — they keep routing because the gateway holds the customer's 802.1X EAP authentication certificate to the AT&T network. The supported equivalent is IP Passthrough, which hands the public IP to a designated downstream device while the BGW continues to handle the carrier-side authentication. AT&T's own knowledge-base article documents this.²⁰ The UniFi gateway's WAN MAC address is registered in the BGW's IP-passthrough setting; the BGW continues to NAT for its own management plane but forwards everything else.

Spectrum / Charter

Mixed picture. Spectrum-supplied combination modem-routers (Sagemcom, Askey, Wave 2) require a call to Spectrum support to be put into bridge mode; it's not a customer-accessible web UI setting. Spectrum's own router products like the RAC2V1K explicitly do not support bridge mode at all — the only path is to return the Spectrum router and substitute a customer-owned modem (any DOCSIS 3.1 model on Spectrum's approved list will work). The customer-owned modem-only path is the recommended option for any Spectrum home running UniFi.

Optimum / Altice (Long Island, NYC, NJ tri-state)

Optimum's Smart Router and Altice fiber gateways (GR140DG, GR240) do not expose a customer-facing bridge-mode toggle. Bridge mode has to be enabled by Optimum support over the phone; the routing tier moves to the customer's UniFi gateway, and the Optimum gateway becomes a transparent bridge. On the GR240 fiber gateway, the bridged LAN port is LAN4 (2.5 GbE)— this is a recurring support trap because the Optimum agent on the call will sometimes tell the customer to use LAN1; it's the wrong port and connectivity won't work. Altice One (the all-in-one cable-TV + internet device) does not support bridge mode at all; UniFi customers on Altice One have to either accept double-NAT or return the Altice One in exchange for a separate gateway and set-top box.

Frontier Fiber (eero gateways)

Frontier ships eero on current fiber plans. eero exposes bridge mode as a software toggle inside the eero mobile app under Settings → Advanced settings → DHCP & NAT → Bridge. Bridge mode on eero disables eero's own Wi-Fi, the eero Secure subscription features, and the Thread radio if the customer is using eero for Matter / smart-home; if any of those matter, the UniFi gateway has to be paired with a separate eero in a non-bridge configuration. The Frontier help center links to the canonical eero documentation.²¹

T-Mobile Home Internet (5G Gateway)

T-Mobile's 5G Gateway does not support bridge mode and does not support IP passthrough. The carrier's own community forum confirms this directly — multiple moderator responses state the gateway has no bridge-mode option, and the network puts customers on CGNAT.²² Cascading a UniFi gateway behind the T-Mobile gateway works (the UniFi gateway gets a private WAN IP from the T-Mobile gateway's DHCP), but double-NAT and CGNAT are both active and unavoidable. Remote access on T-Mobile Home Internet has to go through outbound-tunnel solutions — Teleport, Tailscale, or Cloudflare Tunnel — rather than inbound port-forwards.

Carrier-grade NAT is an ISP-side translation layer that lets the ISP share one public IPv4 address across many customers. RFC 6598 — published April 2012 as BCP 153 — allocated the 100.64.0.0/10 address block specifically for this purpose:

“This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier-Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).”¹

Wikipedia's framing of the consequence is direct:

“Carrier-grade NAT (CGN or CGNAT), also known as large-scale NAT (LSN), is a type of network address translation (NAT) used by Internet service providers (ISPs) in IPv4 network design.”²³

Where CGNAT is in play, no amount of bridge-mode toggling on the home-side device changes the situation — the CGNAT layer is in the carrier's network, between their edge router and the public internet. A homeowner cannot make it go away.

Three options when CGNAT is identified:

• Ask the ISP for a public IPv4 address. Some ISPs offer a paid “static IP” or “business IP” add-on that effectively takes the customer off CGNAT. Names and prices vary by market and tier; the question to ask the ISP is literally “can you take my account off CGNAT and assign a routable IPv4 address?”.
• Use outbound-tunnel remote access. Teleport, Tailscale, Cloudflare Tunnel, and similar products all establish an outbound connection from inside the home to a relay or coordination server outside the home. CGNAT doesn't block outbound traffic; only inbound. See § 07.
• Use IPv6 instead. If the ISP delivers routable IPv6 and IPv6 prefix delegation chains through to the UniFi gateway correctly, end-to-end reachability over IPv6 is available even though IPv4 is behind CGNAT. This is an increasingly common pattern on T-Mobile Home Internet and on some apartment-building fiber deployments. Whether it actually works depends on whether the application the homeowner cares about (Plex, Home Assistant, WireGuard) speaks IPv6.

When bridge mode is impossible — Spectrum router model that doesn't support it, T-Mobile Home Internet, apartment-building gear the customer doesn't control, CGNAT — the practical fix is to stop trying to make inbound traffic work and switch to outbound tunnels. Three options that all work behind two NATs:

Teleport (Ubiquiti, included with UniFi)

Teleport is Ubiquiti's zero-configuration VPN. The gateway and the client both initiate outbound connections to Ubiquiti's cloud, which brokers the tunnel. The Teleport help-center page is direct about the NAT properties:

“Unlike traditional VPNs such as L2TP, which encounter issues when behind NAT, Teleport can be used when both the UniFi gateway and client are behind NAT.”²⁴

Teleport peers are added with a single click in the WiFiman mobile app. No upstream port-forward required. Under the hood it's WireGuard with Ubiquiti supplying the discovery and key-exchange.

Tailscale / WireGuard mesh with a coordination server

Tailscale (and its open-source cousin Headscale) run a WireGuard mesh with a central coordination server that handles peer discovery and NAT traversal. Devices inside the home register with the coordination server outbound; remote devices register the same way; the coordination server tells the peers how to reach each other, typically using direct WireGuard once both have punched a hole through their NATs, or via a DERP relay if direct peer-to-peer fails. Works under home-side double-NAT and under CGNAT.

Cloudflare Tunnel (for HTTP / TCP services)

Cloudflare Tunnel runs cloudflaredinside the home (on a Raspberry Pi, a NAS, a Docker host) and establishes an outbound long-lived connection to Cloudflare's edge. Inbound requests to a public Cloudflare hostname get routed through the tunnel to the local service. Best when the goal is to expose a single web app (Home Assistant, a media library, a self-hosted dashboard); not a general-purpose VPN.

The common thread across all three: nothing inside the home needs to be reachable on an inbound port from the public internet. The home initiates outbound; the relay or coordination layer handles the rendezvous; the homeowner gets the same result as a port-forward without the architectural exposure.

1. WAN-IP check

Same diagnostic as § 02, run again. The UniFi gateway's WAN IP should now be a public, routable address — not in 10.x, 172.16-31.x, 192.168.x, or 100.64-127.x. If the WAN IP is still private, the ISP device is still routing — verify the bridge-mode setting saved, and that the UniFi gateway is plugged into the correct LAN port (on some ISP devices, only one LAN port participates in bridge mode — see the Optimum GR240 note in § 05).

2. Public-IP check from inside

From a device behind the UniFi gateway, visit whatismyip.com. The IP the site reports should match the UniFi gateway's WAN IP exactly. If they match, NAT is now happening once (on the UniFi gateway) and not twice. If they don't match, there's still a NAT layer between UniFi and the public internet.

3. Port-forward smoke test

Set up a temporary port-forward on the UniFi gateway — e.g., TCP 22 → a Raspberry Pi's SSH server, or TCP 51820/UDP → the WireGuard server. From a network outside the home (a phone on cellular, a remote machine), attempt to connect to the home's public IP on that port. If the connection succeeds, inbound reachability is working end-to-end and double-NAT is resolved. Remove the test port-forward after the check.

IPv6 verification (if applicable): from a device behind the UniFi gateway, check whether the device has a global-unicast IPv6 address (starting with 2 or 3) rather than only a link-local (fe80::) or unique-local (fc00::/7) address. Visit test-ipv6.com to confirm dual-stack connectivity. If only IPv4 works after bridge mode, the ISP device may still be in the path for IPv6 specifically — some ISP gateways pass IPv4 through cleanly but keep their IPv6 firewall active.

• Carrier features change.ISP gateway firmware moves the bridge-mode setting between menus, removes it, adds it back. Names of management apps (xFi, My Verizon, MyFrontier, T-Mobile Internet) change. The carrier-specific section is current as of the article's publication date; verify in your account portal before making a support call.
• Bridge mode often disables features you want. Built-in Wi-Fi, voice lines, hotspot SSIDs, and management apps tied to the ISP device all stop working in bridge mode. Homeowners should budget either for the UniFi gateway to fully replace those (which it does) or for a willing-to-revert fallback if a missing feature matters more than expected.
• Some “bridge mode” is not really bridge mode.AT&T IP Passthrough, several cable-MSO “bridge” modes, and most ISP fiber gateways keep their own management plane alive even with the consumer toggle on. The practical effect — UniFi gateway gets a real public IP — is the same, but if a downstream tool inspects what device holds the public IP, it sees the ISP device, not UniFi.
• CGNAT detection is not perfect. Some carriers use private RFC 1918 addressing for their CGNAT links rather than 100.64.0.0/10, which makes the link look like ordinary home-side double-NAT from inside the home. The traceroute output to a known public IP often distinguishes them — a CGNAT layer adds an extra hop on a private address before the first public hop.
• Whether your specific ISP offers a CGNAT-opt-out add-on, and at what price, varies by market and by month.We deliberately don't quote a flat dollar figure here. Ask the ISP directly.
• Site-to-site VPN behind double-NAT works in limited ways.If one of the two sides has a public IP, Site Magic and IPsec-NAT-T both work — the side without the public IP initiates outbound to the side with one. If both sides are double-NATted or CGNATted, neither can be the “listener”; a third-party broker (Tailscale, ZeroTier, Cloudflare Tunnel) is the only workable pattern.

None of this changes the underlying recipe. Identify which flavour of double-NAT you have using the WAN-IP test; for home-side double-NAT, put the ISP box in bridge mode or IP passthrough; for CGNAT, switch to outbound-tunnel remote access or ask the ISP for a routable address. The audit's job is to put a written, citation-backed answer in front of the homeowner so the right conversation with the ISP — or the right architectural decision — can happen with specifics.