GigaPower: Has anyone had success getting AT&T to give them hardware that supports true bridge-mode?

Ericseastrand,

Unfortunately, our routers does not support true-bridge mode. You can enable IP Passthrough which may help however, DMZ+ mode should have done the trick.

-AT&T Community Specialist

I am aware that the hardware doesn't support bridge mode. IP passthrough and DMZ+ are still a double-nat configuration, which increases ping and reduces bandwidth.

Are you saying that AT&T does not have any devices that support true bridge mode? If not, how does a small business cope with a 2k connection limit on the NAT table?

To put that into perspective, to load this forum post page, your computer had to open ~200 individual connections. Multiply that by 10 people in a small business, and you're already at your 2k connection limit. And this assumes that your business is not very tech savvy and doesn't load more than one tab at a time. A software developer browsing documentation will regularly click 3-4 links to open in new tabs, so a small team of software developers will hit that limit in no time at all.

So you're telling me that AT&T doesn't have any hardware that supports bridge-mode, and that it is therefore impossible to use your own router without a double-nat setup?

---

@ericseastrand wrote:

.... IP passthrough and DMZ+ are still a double-nat configuration, which increases ping and reduces bandwidth....

 

This is not true.  DMZ+ and IP Passthrough (which you get depends on your device, no device has both) do not create a double-NAT configuration: traffic from the device indicated in the DMZ+/IP Passthrough configuration will not have any port or address translation at the Gateway, so it will not be double-NATted.

---

@ericseastrand wrote:

So you're telling me that AT&T doesn't have any hardware that supports bridge-mode, and that it is therefore impossible to use your own router without a double-nat setup?

---

I'm telling you that AT&T doesn't have any gateways in the small business/residential space that implement a true bridge mode.  However, that doesn't mean you have to have double NAT.  

What you're explaining makes sense, but doesn't correlate with what I'm observing. The RG's web UI still shows 330+ NAT connections under Diagnostics => NAT, even though my Asus router is doing all of the actual routing. To be absolutely sure, I did a factory-reset of the RG device, and since then, have only connected two devices to it: the Asus router, and my windows PC, temporarily, to configure the RG to give the Asus router a static IP. Maybe these are lingering connections that my PC opened when it was connected..? Or my testing methods could be flawed.

Is using DMZ+ (on the dynamic IP) different from assigning one of my static IPs to a device? When I assign one of my static IPs to the Asus router, the DMZ+ settings page shows that it's already using DMZ+ mode.

For reference, here's a traceroute from my windows computer behind the Asus router:

C:\Users\Eric>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops:
 1 <1 ms <1 ms <1 ms router.asus.com [192.168.2.1]
 2 1 ms <1 ms <1 ms homeportal [192.168.1.254] << Internal LAN IP of the AT&T RG
 3 3 ms 20 ms 2 ms 99-45-148-1.lightspeed.hstntx.sbcglobal.net [99.45.148.1]
 4 2 ms 2 ms 2 ms 71.149.7.204
 5 2 ms 2 ms 2 ms 71.144.129.2
 6 7 ms 7 ms 7 ms 12.83.86.137
 7 8 ms 8 ms 7 ms 12.123.18.237
 8 8 ms 7 ms 7 ms 12.255.10.102
 9 * * * Request timed out.
 10 8 ms 8 ms 15 ms 108.170.231.68
 11 8 ms 7 ms 7 ms 108.170.230.235
 12 9 ms 7 ms 7 ms google-public-dns-a.google.com [8.8.8.8]
Trace complete.

And a traceroute from the router itself:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
 1 75.51.12.86 (75.51.12.86) 0.982 ms 0.661 ms 0.553 ms << Static IP of the AT&T RG itself
 2 99-45-148-1.lightspeed.hstntx.sbcglobal.net (99.45.148.1) 18.716 ms 3.509 ms 2.274 ms
 3 71.149.7.204 (71.149.7.204) 2.589 ms 2.522 ms 2.400 ms
 4 71.144.129.2 (71.144.129.2) 2.688 ms 2.701 ms 2.539 ms
 5 12.83.86.137 (12.83.86.137) 10.615 ms 12.83.86.133 (12.83.86.133) 18.133 ms 12.83.86.137 (12.83.86.137) 3.096 ms
 6 12.123.18.237 (12.123.18.237) 8.585 ms 11.255 ms 26.905 ms
 7 12.255.10.96 (12.255.10.96) 7.854 ms 7.878 ms 7.810 ms
 8 * 108.170.240.193 (108.170.240.193) 8.131 ms *
 9 216.239.42.187 (216.239.42.187) 8.947 ms 209.85.242.52 (209.85.242.52) 10.210 ms 108.170.230.108 (108.170.230.108) 9.769 ms
10 108.170.230.237 (108.170.230.237) 8.891 ms 108.170.231.15 (108.170.231.15) 8.868 ms google-public-dns-a.google.com (8.8.8.8) 7.794 ms

And a traceroute that I ran from my EdgeRouter Lite set up with the same configuration:

ubnt@ubnt# traceroute 8.8.8.8 
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets 
 1 75.51.12.86 (75.51.12.86) 0.674 ms 0.818 ms 0.514 ms << Static IP of the AT&T RG itself
 2 99-45-148-1.lightspeed.hstntx.sbcglobal.net (99.45.148.1) 75.358 ms 2.008 ms 1.738 ms 
 3 71.149.7.204 (71.149.7.204) 2.239 ms 2.246 ms 2.505 ms 
 4 71.144.129.2 (71.144.129.2) 3.073 ms 2.370 ms 4.131 ms 
 5 12.83.86.133 (12.83.86.133) 8.161 ms 12.83.86.137 (12.83.86.137) 4.519 ms 12.83.86.133 (12.83.86.133) 6.658 ms 
 6 12.123.18.237 (12.123.18.237) 8.333 ms 8.196 ms 8.330 ms 
 7 12.255.10.110 (12.255.10.110) 7.938 ms 8.070 ms 7.910 ms 
 8 * * * 
 9 216.239.49.7 (216.239.49.7) 8.729 ms 108.170.230.112 (108.170.230.112) 7.920 ms 108.170.226.54 (108.170.226.54) 10.091 ms 
10 108.170.230.145 (108.170.230.145) 10.501 ms 108.170.230.249 (108.170.230.249) 7.846 ms * 
11 google-public-dns-a.google.com (8.8.8.8) 7.835 ms 7.976 ms 8.020 ms 

As you can see, in all of these instances, the traffic still has to hop through the AT&T router gateway device. For the sake of comparison, notice that the traffic does NOT have to hop through the AT&T ONT device, despite it being physically between the RG and the next hop. I would like to similarly cut out the hop through the RG device, just like on a DOCSIS connection, you don't have to hop through your modem to get to the gateway.

Here's a traceroute from my sister's computer (on Xfinity/Comcast) which shows how that doesn't happen:

C:\Users\Sis>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops:
 1 11 ms 1 ms 2 ms 192.168.0.1
 [ Not pictured: hopping through the modem's WAN address of 73.115.60.*** ]
 2 20 ms 13 ms 44 ms 96.120.17.73
 3 26 ms 8 ms 8 ms ae-204-sur03.grant.tx.houston.comcast.net [68.85.255.249]
 4 28 ms 22 ms 10 ms ae-37-ar01.bearcreek.tx.houston.comcast.net [68.85.247.113]
 5 20 ms 16 ms 20 ms be-33662-cr02.dallas.tx.ibone.comcast.net [68.86.92.61]
 6 15 ms 16 ms 14 ms be-12495-pe03.1950stemmons.tx.ibone.comcast.net [68.86.85.194]
 7 17 ms 19 ms 16 ms 66.208.228.66
 8 15 ms 22 ms 16 ms 108.170.240.193
 9 32 ms 22 ms 15 ms 216.239.62.77
 10 14 ms 22 ms 14 ms google-public-dns-a.google.com [8.8.8.8]
Trace complete.

Hopefully someone can clarify to help me fill my knowledge gap 🙂

As the U-verse Gateway does not have a true bridge mode, it is still a hop between your router and the first router in the AT&T network.  However, it is a simple routing hop; not one that does Network Address or Port Translation, it's just forwarding the packets and there is no need for an entry in the NAT table.  I'm trying to come up with a test where you could satisfy yourself of that.

If you're comfortable with WireShark, and have a switch that can give you promiscuous mode port, or an Ethernet hub (which effectively is in promiscuous mode on all ports all the time), you capture the IP packets between the router and the Gateway and see that they have already been NATted.  If you wish, you can capture the IP packets on the WAN side of the gateway and confirm that neither the address or port changes again as it goes through the Gateway (since you have Fiber, you have Ethernet on the WAN side and can do this; those with VDSL2 are out of luck).  Or, if you have access to the logs of a server outside your home that you can visit from inside your home, you can confirm what client ports arrive (and if they're the same as what was on the LAN side of the Gateway).

I thought that there was a public site that could sniff double-NAT, but I cannot find one, and frankly, I'm not sure how it can tell without some intermediary in the network