U-verse and Static IP Addressing: Badly Broken!


Although AT&T makes blocks of additional public IP addresses available for U-verse more cheaply than most other residential broadband services (e.g., $15/mo for a /29 block, i.e., 8 addresses of which 5 are usable), some very serious bugs and misfeatures in the U-verse 2WIRE 3800 Residential Gateway (RG), make it almost unusable -- or at best a real headache. If you must have a block of static public IP addresses, and you probably do if you run servers and/or are simply a serious networking geek like me, then either avoid U-verse or get them through an IPsec or OpenVPN tunnel. Unless, of course, you are really up to a challenge, and don't mind spending a lot of time getting it to work - and fixing it when it breaks.

The big problem: you just can't get the RG's stateful firewall out of the way!

Most "static IP" services provide a simple bridged Ethernet interface to a router somewhere at the other end of your phone or cable line, with no filtering or firewalling whatsoever. Not U-verse. Even if you turn off every "protection" option and check the "Auto Firewall Open" option under "Advanced Home Network Settings", it still blocks some traffic such as the ICMP messages that make traceroute work. (Ironically, traceroute works fine through the RG's built-in NAT.) And every stateful firewall is potentially subject to memory exhaustion from large numbers of TCP connections or UDP associations that even individual users may legitimately create (think of Bit Torrent, Skype, and even loading CNN's main page).

Problem number two: the RG abuses ARP to limit each Ethernet MAC address (i.e., physical computer) to just one IP address, either public or private -- not both. This precludes attaching a "real" router to the RG to manage your address block. It can also complicate life for servers with clients on both the local network and the outside Internet, but this problem can be worked around by using private addresses from another local block block not managed by the RG.

When I first wrote this, the U-verse 3800HGV-B Residential Gateway (RG) was running software version It has since been changed to It has a very different 'look' to its configuration pages, but I have seen no change in functionally; the problems I describe here seem to persist. I sincerely hope another update will soon moot everything I say here.


U-verse support for static IP addressing must have been added as an afterthought. The saleslady who came to my door didn't know what it was until I explained it, but she checked and assured me that it was available (I had made it clear that I wasn't interested otherwise.) As I expected, the installer didn't know anything about it either, but to his credit he spent a good hour on the phone tracking down somebody inside AT&T who knew how to configure it into their routers and my RG.

But the real problem is that the software in the RG to support static IP addresses is badly broken. Although static (public) IP addresses bypass the RG's NAT, they are still processed by a badly configured stateful packet-filtering firewall, and there doesn't seem to be any way to just turn the damn thing off.

AT&T did one thing right: when you order a static IP address block, it is provisioned in addition to the single IP address already configured into the residential gateway and used by its internal NAT to support the built-in Voice Over IP adapter, WiFi base station and video control subsystem. I had assumed that my static allocation would replace whatever single address I had been assigned, and I might have to give up some to the set top box and VoIP adapter. But the RG still assigns addresses to the set top boxes from the private IP address block

The RG still wastes three public IP addresses for other reasons, but at least it doesn't need any for those other devices.

%$#$%#@!! Firewalls!

I have never been a fan of packet-filtering firewalls on my Internet traffic. Especially when I can't control them. [1]

Although the U-verse RG has some firewall configuration screens accessible to the user, they are poorly documented and limited in functionality. In particular, there is no way for the user to completely bypass the firewall. Even checking the helpful-sounding "Auto Firewall Open" flag on the "Edit Advanced Home Network Settings" page doesn't completely do the trick.

Nor is replacing the RG with something less broken an option. Its use is mandatory because AT&T uses 802.1x authentication on the VDSL2 link and the RG contains the necessary cryptographic credentials. [1a]

Even with the firewall supposedly turned off with respect to a block of static IP addresses, at least two TCP ports (445 and 139?) are still blocked. Sure, those two aren't a great loss, but this is at least partly a matter of principle; my computers are perfectly capable of dropping those packets all by themselves, thankyouverymuch. (Note: I don't run Windows.) Since attacks on port 445 are especially common (every few seconds), I want to use them in some host-based attack detection and mitigation experiments. I would also like to study various other kinds of attacks.

Certain types of ICMP traffic, particularly the Destination Unreachable - TTL Exceeded messages used by the traceroute command, are also completely blocked. This is a significant impediment to network debugging.

The RG's firewall is of the "connection tracking" or "stateful" type, so any loss of connection state will cause even valid traffic to be discarded. Several things can cause this to happen:

  • Rebooting the RG;
  • RG memory exhaustion from too many connections;
  • "ageing out" of idle but still valid connections.
  • This last cause is especially common on UDP associations because a NAT or firewall cannot detect the end of a transaction by looking at the UDP header. Since UDP is heavily used for short transactions such as DNS look ups, short idle timeouts are necessary to keep large numbers of old UDP associations from piling up in the table. A stateful firewall can use a much longer idle timeout for TCP because it can easily detect the normal end of a TCP connection by observing the FIN bits in the TCP headers.

    Yes, it is possible to keep a firewall from dropping live connections by sending periodic "keep alive" messages. But this has two problems: it creates useless Internet traffic, and it doesn't solve the problem for sleeping hosts. I see no reason I shouldn't be able to put my laptop or desktop to sleep, wake it up hours later, and still have all of my Internet connections. [2]

    The RG's DHCP Server: Lame

    Like virtually every home Internet gateway, the U-verse RG has a built-in DHCP server handing out IP addresses in a private (non-routable) block, This block can be changed along with the lease duration, but those are the only configuration options. You cannot allocate specific IP addresses to specific MAC addresses. You can't specify the DNS servers to be given to the clients. You can't change the domain name suffixes to be searched when resolving names. Nor can you even turn the DHCP server off. For these reasons, plus more to be discussed later, the built-in DHCP server is likely to be a highly unsatisfactory replacement for an existing DHCP server, especially if you're used to ISC's popular (and fully featured) open source DHCP server.

    So I had to find a way for it to coexist with my existing ISC DHCP server on my local network. I did this by connecting my LAN to the RG through a small Linux system acting as an Ethernet bridge that, among other things, blocks DHCP packets. DHCP clients internal to the RG, or connected directly to it (or through its WiFi access point), receive addresses on the network from the RG's DHCP server. At the moment, its only client is the U-verse set top box. Clients on the rest of the local network, on the other side of the Linux bridge, receive one of the public addresses in the AT&T-assigned static IP block and/or a private address in the block that the RG does not manage.

    Computers, once configured with IP addresses, can connect to either side of the bridge and operate properly. The bridge does not have to drop ARP because the RG ignores ARP activity involving addresses it doesn't control. However, my plan is to keep everything but the set top box on the other side of the Linux bridge from the RG so I can use the traffic control features in Linux to shape the traffic going to the Internet. This is important in keeping latency low for interactive traffic even when the link is operating near capacity with "scavenger" traffic like Bit Torrent.

    Only One Address To A Customer!

    An early unpleasant U-verse discovery was that the RG expects each host on the local network to have only one IP address -- one in the private block or one in the public routable block but not both. Not only is there no provision in the DHCP server to configure multiple addresses to a single MAC address (or to configure much of anything else, as discussed above) but even statically allocating one of each will get you in trouble!

    Why would I want a host to have both a private IP address and a public one? Efficiency. Consider a large Linux server running lots of services. They're used from both the LAN and from the outside Internet, so clearly this system needs a public IP address. The server also handles a collection of Squeezeboxes, "dumb" network audio players on the local LAN. Obviously it would be a waste to assign precious public IP addresses to these devices. But the Squeezebox does not have a sophisticated IP router; it only knows the prefix of its local network and the IP address of the default router to be used to reach everything else. So if their server has only the single public IP address, then all traffic from the Squeezeboxes would be relayed through the default router -- the RG -- even though they're all on the same physical LAN. This puts unnecessary load on the RG, creates extra points of failure (such as the RG), and adds delay.

    The simple and elegant solution to the problem is to give the Linux server two IP addresses: one public for external use and a private one for talking to the players.

    But the RG has other plans. It detects statically configured hosts by broadcasting a near-continuous stream of ARP requests for every IP address it has ever seen, one every few seconds. [2a] Yet, inexplicably, it can take minutes for a new statically configured host to appear in the RG's network summary page.

    If an ARP for a private IP address managed by the RG (i.e., in the block) is answered by a MAC address that had previously answered an ARP for a public IP address, the private IP address replaces the public IP address in the entry in the RG's local device list, the RG slams its firewall shut on the public address and no longer routes packets to or from that address.

    The fix for the Squeezebox (local client) problem is to give them addresses from another private IP address block, e.g., Their server also needs a secondary address in this block. The RG seems to ignore all ARP exchanges involving these addresses since it does not manage them. You will have to either configure your clients manually (i.e., statically) with these addresses or set up a separate DHCP server to manage them. In the latter case you must isolate your DHCP server from the one in the RG by dropping DHCP packets in the bridge between it and the LAN with the DHCP server, Squeezebox clients and server. Also, if a client with an address on this second private block has to talk to the outside world you will have to provide your own NAT for it as the NAT in the RG only serves the subnet. (Linux can easily be configured to provide both NAT and DHCP services.)

    A Nasty RG Configuration BUG

    As described above, when a host with a public IP address tries to use a private address managed by the RG (i.e., in the block), the RG slams the firewall shut on that host's public IP address. Even manual attempts to restore the public IP address generally fail because of the RG's buggy software. Here's how the affected host ("maggie") appears in the Edit Address Allocation Settings page. It now has a private IP address and its "Firewall Protection" box is checked because external hosts cannot initiate connections to private IP addresses, an inherent property of all NATs. [3]

    But when I try to restore maggie's public IP address like this, watch what happens. The error message "For the public routed subinterface only WAN IP mapping is allowed" is clearly spurious. I'm doing exactly what it's telling me to do - I'm specifying an IP address on the WAN (wide area network). I find that I can only recover from this situation by clearing the RG's local host table and rebuilding it from scratch, host by host. This is quite simply unacceptable.

    Why am I trying to use a private address in the from a machine that already has a public IP address? To work around the traceroute bug mentioned earlier; only a traceroute from a private address through the RG's NAT will work. So working around one bug has revealed another...

    You must be very careful even when you use separate Ethernet interfaces in the same machine for the different addresses. By default, Linux (and probably other operating systems) will answer an ARP for any of its IP addresses on any of its interfaces. Normally this is just fine -- but not in the U-verse universe. For example, if you configure eth0 with and eth1 with and then connect both interfaces to the RG, Linux might answer an ARP for through eth0 - and this would cause the same problem as configuring both addresses on eth0. Fortunately, Linux has configuration flags to stop this; see the kernel documentation for


    Among other things, this nasty RG misfeature keeps you from connecting a real IP router (e.g., a Cisco or a Linux system acting as a router) to the RG and having it proxy ARP for the entire public IP address block. I suppose this might still be possible if the router's Ethernet interface could be given a set of alternate MAC addresses so that the router can answer the RG's ARPs with a distinct MAC address for each public IP address. But I found it easier to configure the Linux system as a bridge and have it pass the actual MAC addresses of the hosts on the other side. Linux can still perform all the functions I need while bridging, such as packet filtering (specifically to block DHCP as discussed earlier) and traffic shaping.

    At least the RG doesn't seem to care about Ethernet source addresses when it receives an IP packet to forward over the Internet. This means that a local host can loop its outbound traffic through another machine on its way to the U-verse RG. I've done this to set IP DSCP values, and it works. But Linux can optionally invoke iptables on bridged Ethernet traffic so it isn't actually necessary to explicitly route traffic in this manner.


    [1] In my opinion, firewalls are only properly used, at best, as emergency stopgaps. They're certainly no substitute for proper security engineering of individual Internet hosts. (Could the residents of East Berlin leave their houses unlocked thanks to the "protection" afforded them by the Berlin Wall?) Unfortunately, the state of computer security is so abysmal, thanks largely to Microsoft software, that firewalls have become a sad fact of life. They're now built into everything and advertised as though they were desirable features. (Would you consider it a desirable feature of a car to refuse to drive down certain streets even if you wanted to?)

    Firewalls and NAT have greatly complicated life for every network administrator and seriously hampered experimentation, development and deployment of new Internet protocols and applications.

    Because firewalls are usually controlled by network administrators, not users, they frequently block traffic that the intended recipients actually want. That's why they're so evil. Likewise, the NAT in the U-verse RG is especially evil because you can't replace it with one of your own, or do without one by connecting just a single computer and having it inherit the single IP public address assigned to you by default.

    [1a] It's hard to understand what makes AT&T so paranoid that they require authentication on a residential phone line. Ordinary POTS telephones never had to authenticate themselves to the phone company. Nearly every telephone company also uses PPPoE on regular DSL so that the user has to "log in" to the network before he can use it. What's the point? If the user doesn't pay his bill they can always just disconnect his line and then it doesn't matter what he puts on his end of it.

    [2] What's so sad about all this is that simplicity, statelessness and end-to-end transparency were once among the Internet's most powerful features. They made it fast, flexible and reliable. It was easy to experiment at the edges of the network without having to beg permission from anyone. NAT and stateful firewalls reintroduce all of the problems with alternative "connection-oriented" networks that the Internet was designed to solve.

    [2a] In my opinion, this constitutes an abuse of the protocol. ARP requests are broadcasts that every host on the network must process, so to minimize this overhead ARP responses are supposed to be cached for 15 minutes.

    [3] The RG's authors are among those who erroneously refer to NATs as firewalls. A firewall selectively passes or blocks packets based on their contents without necessarily modifying them, while a NAT always modifies one of a packet's IP addresses and UDP or TCP port numbers. The only packets that a NAT will block are those from the outside for which there is no local connection state. This state is created automatically by the first outbound packet, which is why hosts behind NAT are unable to act as servers without an additional mechanism in the NAT. Avoiding this inherent restriction without having to resort to port-forwarding kludges is precisely why one orders static (public) IP addresses in the first place!

    Last modified: Sat Apr 3 02:40:12 UTC 2010