There is a network topology so common that most people running it have no idea it exists: an ISP-supplied gateway performing NAT, with the customer's own router behind it performing NAT again. Every packet leaving the network gets translated twice. Most applications shrug this off. Web browsing works, streaming works, email works — which is exactly why double NAT survives undetected for years, quietly sabotaging the one class of traffic that cannot tolerate it.
VoIP is that class. If your phones suffer from one-way audio, registrations that mysteriously lapse, inbound calls that go straight to voicemail while the handset sits idle, or calls that drop at eerily consistent durations, double NAT belongs at the top of your suspect list. This post explains how the topology comes to exist, how to confirm it in about two minutes, why it hits SIP so much harder than a single NAT layer does, and how to fix it — ranked from the clean solution to the acceptable workaround.
The setup nobody realizes they have
Almost every ISP now ships a combination device: a modem (or ONT interface) fused with a router, Wi-Fi access point, and firewall in one box. Comcast's xFi gateways, AT&T's BGW-series units, Spectrum's leased routers — all of them are full NAT routers out of the box, handing out private addresses on their LAN side.
Then the customer, reasonably, adds their own router. Maybe the ISP box's Wi-Fi is weak and they bought a mesh system. Maybe an IT provider installed a proper firewall for the office. Maybe the old router just came along from the previous ISP. The new router's WAN port plugs into the ISP gateway's LAN port, the new router does what routers do — NAT — and now the network has two translation layers stacked in series. Devices sit on, say, 192.168.1.x behind the customer router, which sits on 192.168.254.x behind the ISP gateway, which finally holds the public IP.
Nothing announces this. Both boxes report healthy status. Speed tests look normal. The topology can persist for the entire life of the installation, and in small offices it very frequently does — we would estimate double NAT is present in a large fraction of small-business networks running an ISP combo unit plus their own firewall, and in most of them nobody has ever checked. There is a third variant worth naming: carrier-grade NAT (CGNAT), where the ISP itself performs a NAT layer in its core and hands your "public" interface a shared address. You get double NAT without a second box on the premises at all.
If you are speccing a small office network from scratch, the office network and router guide covers how to avoid building this trap in the first place.
How to detect VoIP behind two routers
Detection takes two minutes and requires no tools beyond a browser and a terminal.
Check your router's WAN IP. Log into your own router — the inner one, the one your devices connect to — and find its WAN or internet status page. Note the WAN IP address, then compare it to what a "what is my IP" website reports from a device on your network. If they match, you have single NAT. If the router's WAN IP falls in a private range, there is another NAT device between you and the internet:
- 192.168.0.0 – 192.168.255.255 — the classic home range; a WAN IP of 192.168.254.254 is the AT&T gateway signature
- 10.0.0.0 – 10.255.255.255 — common on ISP gateways and CGNAT deployments
- 172.16.0.0 – 172.31.255.255 — less common, still private
- 100.64.0.0 – 100.127.255.255 — the dedicated CGNAT range (RFC 6598); a WAN IP here means your ISP is NATing you upstream, and no amount of on-premises reconfiguration removes that layer
Confirm with traceroute. Run traceroute 8.8.8.8 (or tracert on Windows) from a device on the network. Under single NAT, hop 1 is your router's private address and hop 2 is already the ISP's public infrastructure. Under double NAT, hops 1 and 2 are both private addresses — your router, then the ISP gateway — before public addresses appear at hop 3. Two private hops at the top of the trace is definitive.
Why double NAT breaks VoIP where single NAT merely strains it
SIP was designed before NAT was universal, and it commits the original sin of embedding transport addresses inside message bodies — the Contact header, the Via chain, and above all the SDP payload that tells the far end where to send audio. NAT rewrites packet headers but does not (correctly) rewrite those embedded addresses, so the far end is handed coordinates that no longer mean anything outside your network. That single-NAT problem, and the STUN/keepalive/rport machinery built to work around it, is covered in depth in SIP and NAT traversal. Double NAT takes each of those failure modes and compounds it.
Two translation layers, addresses two steps removed from reality
Under single NAT, a phone at 192.168.1.50 advertises that address in its SDP; techniques like STUN let it discover its public address and advertise that instead, and the far end can reach it. Under double NAT the phone's packets are rewritten twice: once by the inner router, once by the ISP gateway. The address the phone can discover with STUN is the outermost public address, but the return path now requires two pinholes — one in each NAT — to line up simultaneously, mapped through an intermediate address the phone has no way to see or influence. If either mapping is missing, expired, or symmetric-NAT-scrambled, the audio dies in one direction. This is why one-way audio is the canonical double NAT symptom: signaling often limps through, the call connects, and then RTP — which flows on separate, dynamically negotiated ports — fails to find its way back through both layers.
Two timeout clocks, and the shorter one wins
Every NAT device holds UDP mappings only as long as its timeout allows. VoIP survives this by sending keepalives and re-registering often enough to refresh the mapping. Under single NAT you tune against one clock. Under double NAT there are two independent clocks — the ISP gateway might hold UDP mappings for 300 seconds while the inner router gives up at 60, or vice versa — and the shorter timeout governs everything, whether or not you know what it is. ISP gateways are rarely configurable and sometimes use aggressive timeouts of 30–60 seconds.
The symptoms are distinctive. Registrations drop: the phone registers successfully, the shorter mapping expires before the next re-REGISTER, and inbound calls ring straight to voicemail until the phone happens to re-register. Calls die at fixed durations: 30 seconds, 5 minutes, 15 minutes — always the same number, because a timer, not congestion, is doing the killing. Random network problems fail randomly; expiring timers fail punctually. If your drops are metronomic, read why calls drop after a set time alongside this post.
SIP ALG, twice
Here is the kicker. Most consumer and ISP routers ship with SIP ALG enabled — a feature that inspects SIP packets in flight and rewrites the embedded addresses it thinks it understands. Implementations are so chronically buggy that the feature breaks more calls than it fixes, which is why SIP ALG is the setting that breaks everything in single-NAT networks too.
Under double NAT, SIP ALG is very often enabled on both devices. Your SIP messages get mangled twice, by two different vendors' half-correct rewriting engines, each operating on the other's output. The inner router rewrites the SDP to what it believes is the outside address — which is merely the ISP gateway's private LAN — and then the gateway's ALG rewrites the already-rewritten message again, or fails to because the fields no longer look like it expects. Authentication breaks, Contact headers point nowhere, and the resulting failures are nearly impossible to debug from the endpoints because the corruption happens invisibly in transit. Two NAT layers is a hard problem; two NAT layers with two ALGs is signaling roulette.
Modem router combo VoIP fixes, ranked
The goal is one NAT layer, no ALG. Here are the paths to it, best first.
1. Bridge mode on the ISP gateway (best)
Put the ISP combo unit into bridge mode. This disables its router, NAT, firewall, Wi-Fi — everything except the modem function — and passes the public IP straight to your own router's WAN port. Double NAT is not worked around; it is gone. One translation layer, one timeout clock, one place to disable SIP ALG.
Most cable ISPs support this: Comcast xFi gateways have a bridge mode toggle in the admin interface, and most Spectrum and Cox equipment can be bridged by the ISP on request. Two caveats. First, bridging usually disables the gateway's Wi-Fi and any ISP-delivered extras (some TV and phone services need the gateway routing), so make sure your own router covers those needs. Second, after enabling bridge mode, power-cycle both devices so your router pulls the public IP.
2. IP passthrough (AT&T-style gateways)
Some fiber gateways — AT&T's BGW210/BGW320 line is the canonical example — cannot truly bridge because the gateway must stay in the path for authentication. The equivalent feature is IP passthrough: the gateway keeps its WAN session but assigns the public IP through DHCP to your router's MAC address, and forwards traffic to it wholesale. Configure it under IP Passthrough with allocation mode "Passthrough" and your router's MAC as the fixed device. Functionally this behaves like bridge mode for VoIP purposes; the gateway still maintains a small internal session table, so it is fractionally less clean than a true bridge, but in practice it resolves double NAT symptoms as completely.
While you are in the gateway's settings, disable its SIP ALG. Passthrough or not, you do not want it inspecting SIP.
3. DMZ to the inner router (workable)
If the gateway offers neither bridge mode nor passthrough — or it must keep routing for other services — configure its DMZ (sometimes "DMZplus") to point at your router's WAN address, and give your router a static IP or DHCP reservation on the gateway so the DMZ target never drifts. Now every unsolicited inbound packet reaching the gateway is forwarded to your router, which restores inbound reachability for signaling and media.
Understand what this does and does not fix. Both NAT layers still exist, both timeout clocks still run, and outbound mappings still traverse two tables — so keep SIP registration intervals short (60–120 seconds) to hold both pinholes open. DMZ turns double NAT from broken to survivable; it does not make it single NAT.
4. Disable SIP ALG on both layers, regardless
Whichever option above you choose, disable SIP ALG on every device that still routes — and if you are stuck with full double NAT temporarily, disable it on both boxes today, because it is the single highest-value change you can make without touching topology. The setting hides under different names per vendor: SIP ALG, SIP Helper, SIP Transformations, SIP Inspection. Our router-by-router SIP ALG guide has the exact steps for the common hardware. On ISP gateways with no visible toggle, bridging or passthrough conveniently takes the ALG out of the path along with the NAT.
One boundary case: if your router's WAN IP is in 100.64.x.x, the second NAT layer is CGNAT inside your ISP and none of these fixes reach it. Ask the ISP for a static or public IP (many sell one for a few dollars a month); for outbound-registering phones to a hosted provider CGNAT is usually tolerable, but anything requiring inbound reachability needs the real public address.
Verify the fix with a real measurement
Topology changes of this size deserve verification beyond "the phones seem fine now." A phone that registers is not proof the media path is clean — registration is a trickle of small packets, while a call is a sustained 50-packets-per-second stream in both directions, and that stream is what double NAT was silently degrading.
Run a VoIP quality test after the change. It pushes real media through your actual network path and measures what a call experiences: latency, jitter, packet loss, and a MOS score, over a full 60-second stream. Run it before the fix if you can, so you have a baseline; run it after, and confirm the numbers hold for the entire duration — a test that degrades or dies partway through is exactly how a surviving NAT timer announces itself. If the post-fix numbers are clean end to end, you have removed one of the most stubborn, least visible causes of VoIP failure there is.
For the underlying mechanics, read SIP and NAT traversal. For the symptom-side view, see one-way audio and calls dropping after a set time.
Frequently Asked Questions
How do I know if I have double NAT?+
Log into your own router and look at its WAN or internet status page. If the WAN IP starts with 192.168, 10., 172.16 through 172.31, or 100.64 through 100.127, your router is receiving a private address from another NAT device upstream — either an ISP gateway in front of it or carrier-grade NAT at the ISP itself. You can confirm with a traceroute to any public address: two private-range hops at the start of the path means two NAT layers. If your router's WAN IP matches the public IP a 'what is my IP' site reports, you have single NAT and can look elsewhere for your VoIP problem.
Does double NAT cause one-way audio?+
Yes, it is one of the most reliable ways to produce it. SIP embeds IP addresses inside its message bodies, and each NAT layer rewrites the packet headers without touching those embedded addresses — so the far end is told to send audio to an address that is now two translations removed from reality. One layer of this is survivable with modern NAT traversal techniques; two layers, often with SIP ALG mangling the signaling on both devices, is frequently not. If you hear the other party but they cannot hear you (or vice versa), check for double NAT before anything else. Our guide to one-way audio covers the full diagnostic path.
Should I use bridge mode or DMZ to fix double NAT?+
Bridge mode is the better fix when your ISP gateway supports it, because it genuinely removes the second NAT layer — the gateway becomes a plain modem and your router receives the public IP directly. DMZ is a workaround: both NAT layers still exist, but the gateway forwards all unsolicited inbound traffic to your router, which resolves most inbound signaling and media problems while leaving two translation layers and two timeout clocks in play. Use DMZ when bridge mode is unavailable or when the gateway must keep routing for ISP services like TV set-top boxes. On AT&T-style gateways that cannot truly bridge, IP passthrough is the equivalent and works well.
Why do my calls drop at exactly the same duration?+
A fixed-duration drop — every call dying at 30 seconds, or 5 minutes, or 15 minutes — is the signature of a NAT or signaling timer expiring, not of network congestion, which fails randomly. Under double NAT you have two independent UDP timeout clocks, and the shorter one wins: when it expires, the pinhole your audio or signaling depends on closes mid-call. The 30-second variant usually means an ACK or re-INVITE never arrived because SIP ALG or NAT rewrote it into garbage. We break down each characteristic timing in why calls drop after a set time.
Share
Want to know when we publish new articles? Sign up for updates