Almost every business network we inherit has a firewall of some kind sitting behind a carrier gateway. In a meaningful share of them, nobody ever decided which device was supposed to be doing the routing. Both are. The result is double NAT, and double NAT is the quiet cause of a whole family of problems that get blamed on everything else.

What double NAT actually breaks

Two layers of network address translation do not break basic outbound browsing, which is why the condition survives for years. What they break is anything that depends on an inbound path or on an address being predictable.

• Inbound services. Port forwarding has to be configured identically on both devices, and the second one is always the one nobody documented.
• Site-to-site VPN. Tunnels either fail to establish or establish and then flap when a translation table entry ages out.
• SIP and VoIP. Registration works, then calls drop one way after a few minutes. This gets blamed on the phone vendor for months.
• Remote access. Anything requiring a stable public address behaves unpredictably.
• Diagnostics. The public address your firewall reports is not the public address the internet sees, so every troubleshooting assumption starts one step wrong.

The fix is to decide, deliberately, which device owns the edge. If you have a real firewall, it should. That is what bridge mode is for.

What bridge mode does

On the Comcast Business CBR2, bridge mode is a documented configuration option available through the gateway’s web administration interface. Enabling it stops the gateway from performing routing and address translation for the LAN, and passes the WAN-side address through to the device connected behind it.

In practical terms, once the gateway is bridged:

• Your firewall receives the public address directly and owns NAT, routing and policy.
• There is one translation boundary instead of two.
• Port forwarding, VPN and inbound services are configured in one place, the place your engineers actually look.
• The address your firewall reports is the address the internet sees, so diagnostics stop lying to you.

What bridge mode does not do

This is where assumptions cause outages. Bridging the LAN routing function is not the same as turning the device into an inert media converter.

The gateway is still a managed device

It remains provisioned by the carrier, it still receives configuration and firmware from the carrier, and it still has a local management interface. It is not passive. If it reboots for a firmware update, your circuit goes down, and no setting on your side changes that.

Voice ports are a separate function

The CBR2 carries eight FXS ports for phone or fax service, with battery backup. Those are provisioned as a voice service, not as part of the data routing path. Before anyone touches the configuration or swaps the unit, find out what is plugged into them. We have seen fire alarm and elevator lines terminated there, and the failure does not surface until the next inspection.

Wireless needs to be handled explicitly

If you are deploying managed wireless, the gateway radios should be turned off. Leaving them on produces co-channel interference against your own access points and an SSID that is outside your security model. Confirm the radio state after bridging rather than assuming it followed.

Static IP handoff is its own configuration

If you have purchased a static IP block, the way it is delivered depends on how the service was provisioned. Bridging alone does not guarantee that the usable addresses land where you want them. This is the single most common thing we find wrong: an organization paying for addresses it has never been able to use, because the handoff was never configured correctly and nobody tested it after installation.

When bridge mode is the wrong answer

Not every site should be bridged. If the gateway is the only routing device, bridging it means there is nothing performing NAT and DHCP, and the site goes down. Some smaller deployments are better served by leaving the gateway routed and configuring it properly.

The decision comes down to a few questions:

• Is there a firewall behind it that should own policy? If yes, bridge.
• Does the site need inbound services, site-to-site VPN or a static block? If yes, bridge and put the block behind the firewall.
• Is the gateway the only routing device on site? If yes, do not bridge. Configure it deliberately instead.
• Are the voice ports carrying production lines? If yes, plan around them regardless of which mode you choose.

The failure mode is not choosing wrong. It is nobody choosing at all, and then discovering the consequence eighteen months later during an outage that has nothing obvious to do with it.

How we approach it

Before we change a mode on a production gateway, we capture the current state: provisioned tier, signal levels and error counters, firmware version, the full routed configuration, any static block assignment, radio state, and what is physically connected to every port including the FXS ports.

Then the change is made in a window, with the previous configuration recorded well enough to reverse. After the cutover, we verify the public address on the firewall, test inbound paths, confirm VPN establishment and re-check the access-layer counters so we have a clean post-change baseline.

It is not complicated work. It is just work that has to be done deliberately, and the reason it so often is not is that nobody owns the boundary between the carrier and the network.

Written by the Infinity Networks engineering team. We are an independent network engineering firm and are not affiliated with or speaking for Comcast.

See our full CBR2 and EPON practice