Putting a UniFi Gateway Behind an ISP Modem: Bridge Mode, Double NAT, and CGNAT

Do you know what address your UniFi gateway actually sees on its WAN port? If you have ever forwarded a port in UniFi Network and it stayed closed, you should.

Most UniFi gateways do not plug straight into the internet. That holds for a Cloud Gateway Ultra on a shelf and a Dream Machine Pro in a rack alike. They plug into a cable modem, a fiber gateway, a Starlink router or a 5G box owned by the ISP, and that box decides more about remote access than anything you configure downstream.

That said, the arrangement comes in only three forms, and each one has predictable consequences. Once you know which one you have, port forwarding, a WireGuard server and remote access to your UniFi network become things you can plan.

Every install behind ISP hardware falls into one of three patterns. The difference between them is how many layers of network address translation (NAT) sit between your gateway and the public internet, and who controls each layer.

The three patterns are:

• Bridge mode (or IP passthrough). The ISP device stops routing and hands the public IPv4 address directly to the UniFi WAN port, usually via DHCP. Your UniFi gateway is the only NAT layer, so its firewall, port forwards and VPN server face the internet directly.
• Double NAT. The ISP device keeps routing. It gives your UniFi gateway a private address such as 192.168.1.x and translates traffic a second time on the way out. Outbound traffic works fine, but inbound connections have to be forwarded twice — once on the ISP box and once on UniFi.
• CGNAT (carrier-grade NAT). The ISP translates many customers behind a shared pool of public addresses before traffic ever reaches your premises. Your gateway or ISP router often gets an address from the 100.64.0.0/10 shared range defined in RFC 6598, and no setting in your house can open an inbound IPv4 port.

Keep in mind that these can stack. A UniFi gateway behind a T-Mobile Home Internet gateway, for example, is typically behind CGNAT and double NAT at the same time, which is the hardest case to work around.

What's more, the type of ISP equipment gives you a strong hint before you log into anything. Standalone DOCSIS cable modems usually bridge by default, combination modem-routers usually ship in router mode, and fixed-wireless and satellite services rely heavily on CGNAT for IPv4.

The test takes a couple of minutes and needs only UniFi Network and a browser. You are comparing two addresses: the one UniFi reports as its WAN IP, and the one the rest of the internet sees.

Here are the steps:

1. Find the WAN address in UniFi Network. Open the dashboard or the Internet section under Settings and note the IPv4 address on your primary WAN.
2. Find your public address. From any client behind the gateway, visit a what-is-my-IP service and note the IPv4 address it reports.
3. Compare the two. The range the WAN address falls in tells you which scenario you are in.

Read the result against the private and shared ranges:

• The addresses match. Your UniFi gateway holds the public IP. Bridge mode or passthrough is working, and nothing upstream is translating.
• The WAN address is in 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. These are the RFC 1918 private ranges. The ISP box in front of you is routing, so you are double NATed.
• The WAN address falls between 100.64.0.0 and 100.127.255.255. That is the RFC 6598 shared address space reserved for carrier NAT, so you are behind CGNAT.
• The WAN address looks public but does not match. Another layer of translation sits somewhere upstream. In practice that is almost always CGNAT using a range other than 100.64.0.0/10.

If the WAN address is private, log into the ISP router and run the same check on its WAN status page. If the ISP router itself holds a 100.64.x.x address, you have double NAT on top of CGNAT, and fixing the first layer will not fix the second.

A traceroute is a useful second opinion. Run one to any public host and look at the first few hops — a 100.64.x.x address after your own routers is a reliable sign of carrier NAT.

Double NAT is the one scenario you can usually fix yourself. Work through the options in order of preference, because each step down the list leaves more of the ISP device in the path.

The first choice is true bridge mode. Many cable combination gateways, including the units Comcast issues for Xfinity service, have a bridge mode setting that turns off the device's router and Wi-Fi and passes the public IP straight through to whatever is plugged into it.

Once you enable it, power-cycle the ISP device and then the UniFi gateway, since cable modems often bind the lease to the first MAC address they see. On DOCSIS hardware the management page usually moves to 192.168.100.1 in bridge mode, and the Wi-Fi radios go dark — which is exactly what you want.

The second choice is IP passthrough. AT&T fiber gateways such as the BGW320 have no true bridge mode. Instead they offer IP Passthrough, which hands the public IP to one designated device via DHCP while the gateway keeps handling fiber authentication.

In passthrough, set the allocation mode to DHCPS-fixed and select the UniFi gateway's WAN MAC address so the assignment is predictable. Be aware that the ISP device is still in the traffic path, so its own firewall options and session handling still apply even though your gateway now holds the public address.

Some providers let you skip the ISP router entirely. Verizon Fios, for example, delivers internet over Ethernet from the ONT on many installs, and a UniFi gateway can usually take that connection directly — though data-only plans are much simpler than plans that also carry Fios TV or voice through the ISP router.

The last resort is DMZ. If the ISP device offers neither bridge nor passthrough, give the UniFi gateway's WAN port a DHCP reservation on the ISP router and set that address as the DMZ host.

DMZ sends unsolicited inbound traffic to your gateway, so you only maintain port forwards in one place. However, you are still double NATed in the technical sense, and some ISP routers keep certain ports for their own management or voice services even in DMZ mode.

Whichever option you choose, turn off the ISP device's Wi-Fi if it is still broadcasting. A client that joins the ISP network instead of yours bypasses your UniFi zone firewall, your VLAN segmentation and any DNS filtering you have built.

CGNAT is a different problem, because the translation happens inside the ISP's network. Since the shared public address belongs to many customers at once, no bridge setting, DMZ host or port forward on your side can make an inbound IPv4 connection reach you.

That said, CGNAT breaks less than people expect, because much of today's remote-access tooling relies on outbound connections. Anything that connects out from your network to a broker or relay keeps working, and anything that waits for an incoming connection from the internet does not.

Here is how the common UniFi and self-hosting tools behave behind CGNAT:

• UniFi Site Manager. Remote management through unifi.ui.com relies on the gateway keeping an outbound connection to Ubiquiti's cloud. As a result, it generally keeps working behind both CGNAT and double NAT.
• Teleport. UniFi's one-click VPN uses Ubiquiti's cloud to set up the session instead of a manually forwarded port. That makes it the more forgiving built-in option when you do not control the upstream NAT, but test it on your own connection before relying on it.
• WireGuard and OpenVPN servers on the gateway. These listen for inbound UDP, by default on port 51820 for WireGuard and 1194 for OpenVPN. Over IPv4, they cannot be reached from outside a CGNAT connection.
• Port forwards for self-hosted services. A forward for Home Assistant, a game server or a Plex library has nothing to receive, because the inbound packet never reaches your address.

If you still need inbound access, there are three practical workarounds. The first is IPv6, which many CGNAT providers hand out as globally routable addresses, so a UniFi firewall rule that allows one port to one host works without NAT at all.

The second is an overlay network or tunnel that connects outbound. Tailscale, ZeroTier and Cloudflare Tunnel all open their connections from inside your network, and our guide to Home Assistant remote access on UniFi covers where each one fits.

The third is to pay the ISP. Many ISPs that use CGNAT by default will assign a dedicated public IPv4 address on a business plan or as a paid add-on, which turns the connection back into a bridge or double NAT case you can solve with the steps above.

It helps to see the consequences side by side. Three common goals — a forwarded port, a VPN server on the gateway and automatic port mapping for consoles — behave very differently depending on which layer of NAT you are behind.

In bridge mode or working passthrough, everything behaves the way UniFi documents it:

• Port forwarding. Create the forward in UniFi Network and it works, subject to your firewall rules.
• VPN server. The WireGuard or OpenVPN server is reachable on the public IP, and dynamic DNS in UniFi Network keeps a hostname pointed at it.
• UPnP and NAT-PMP. If you enable UPnP on the gateway, consoles and games that request ports automatically get them.

Under double NAT, every inbound path needs configuration on both routers:

• Port forwarding. You need a forward on the ISP router to the UniFi WAN address and a second forward on UniFi to the internal host. Alternatively, a DMZ on the ISP side means only the UniFi forward is needed.
• VPN server. The same rule applies, so forward UDP 51820 on the ISP router to the UniFi WAN address before the WireGuard server can answer.
• Dynamic DNS. Check what your DDNS record actually resolves to. A client that reports the WAN interface address will publish a private IP that nobody outside can reach.
• UPnP. UniFi can open ports on itself but not on the ISP router, so game consoles often report a strict or moderate NAT type.

Under CGNAT, inbound IPv4 is simply unavailable. Your tools are remote management, Teleport and outbound tunnels, and any service that has to be reached directly needs IPv6 or a public IPv4 address from the ISP.

Keep in mind that IPv6 depends on the box in front of you too. If the ISP device stays in router mode, it has to delegate a prefix to your UniFi gateway through DHCPv6 prefix delegation, and if it only hands down a single /64, UniFi has nothing left to divide across your VLANs.

The upstream setup belongs in the same discussion as gateway selection. After all, the routing, firewall and IDS/IPS throughput differences between UniFi gateways only matter if that gateway is the one actually facing the internet.

A few planning steps save the most rework:

• Ask the ISP before you sign. Find out whether the service uses CGNAT, whether a public IPv4 address is available and on which plans, and whether their equipment supports bridge mode or passthrough.
• Plan the second WAN too. Cellular and fixed-wireless backup links very often use CGNAT. For that reason, a WAN failover setup should assume inbound services stop working when the backup takes over.
• Choose tools that work in the worst case. If you are on CGNAT today, or could be after a provider change, build remote access around outbound tunnels and IPv6 rather than port forwards.
• Document the ISP box. Record its admin address, credentials and the mode you set. A firmware push or factory reset from the ISP can quietly put it back in router mode.

Once you know whether you are bridged, double NATed or behind carrier NAT, the rest of the design is straightforward to plan. If the box in front of your network has you rethinking what sits behind it, our guide to choosing a UniFi gateway and the UniFi gateway lineup are good next steps.