TROUBLE WITH STATIC IP ROUTING WITH AT&T U-VERSE/FIBER — LESSONS LEARNED

If you have had issues using Static IP addresses, getting inbound or outbound traffic to pass, accessing Static IP addresses from the outside or assigning a Static IP address to a LAN device, this post is for you.

 

FYI, I am a network administrator with 30 years of experience so I'm not posting a question but rather our experience (so others may avoid the same mistakes) after ordering and installing AT&T U-verse over Fiber, also known as GigaPower, for a business that required a small number of Static IP addresses. The business also required the continued operation of a SonicWall router for a VPN to the main office and which was fully known from the beginning. This post, however should be applicable to almost any router-behind-router situation. I further suppose this would apply to non-Fiber installations, as well.

 

The gateway provided by the installer was an Arris BGW210-700, the same router provided to residential users. I was really disappointed because I had expected a Cisco-branded router. Even so, I was willing to try it in spite of configuration settings being extremely limited.

 

When the install was "complete," it was obvious the local installers knew nothing about routing Static IP addresses or how to correctly configure them beyond what they were "trained" to do. I'm not blaming them, just stating the fact that all they really knew was testing the installation with default settings and that was it. It is the responsibility of the customer to "figure out" how to do anything else.

 

It soon became apparent that the assigned Static IP addresses were not working because absolutely no traffic was being transmitted or received beyond the gateway. I could ping the gateway from the SonicWall, the gateway could ping the SonicWall but nothing else. This was the beginning of more than 12 man-hours over a 2-week period on the phone with well over a dozen people beginning with AT&T "Tech" Support and ending with the AT&T Advanced Resolution Team. Finally, my call landed with one "Joshua" who, not unlike a Rottweiler, didn't let go until the issue was resolved and deserves many, many thanks.

 

I already knew my diagnosis was correct because neither a ping nor a traceroute from the outside to any Static IP (one is assigned to the BGW210) could get further than the 12.xxx.xxx.xxx AT&T cloud. Too, it was not possible to ping or traceroute an outside IP address from any device with a Static IP assigned. Until "Joshua" took it seriously, every single support person treated me as if I were saying the SKY was GREEN and that what I was saying just was not possible. It was beyond ridiculous trying to convince personnel who should have recognized the traceroute issue immediately who instead blamed everything (and I do mean EVERYTHING) else. I'm surprised I didn't hear sunspots as a possible culprit.

 

So, step-by-step, what follows is what should and NOT be done to get Static IP addresses working correctly and how to confirm they are fully functional.

 

Gateway Prerequisites.
The gateway must have the following settings for testing purposes. They can be changed back later. This uses the provided Arris BGW210 as an example but similar settings should exist on other gateways.
1) From the main page, "Firewall" > "Firewall Advanced" > "Drop packets with unknown ether types" should be set OFF.
2) "Firewall" > "Firewall Advanced" > "Drop incoming ICMP Echo requests to LAN" should be set OFF.
3) "Firewall" > "Firewall Advanced" > "Drop incoming ICMP Echo requests to Device LAN Address" should be set OFF.
4) "Firewall" > "Firewall Advanced" > "Drop incoming ICMP Echo requests to Device WAN Address" should be set OFF.
5) "Firewall" > "Firewall Advanced" > "Suppress ICMP error responses" should be set OFF.

 

Because this install also uses a SonicWall behind which all internal LAN devices will connected, there is no need for any special settings or restrictions with regard to "Packet Filter," "NAT/Gaming," "IP Passthrough," "Cascaded Router" or Public Subnet Hosts. All of this can be disabled or left blank for this situation.

 

Also, be aware that on any AT&T gateway, it is strongly advised to use DHCP to assign a Static IP Address(es) to the WAN interface of any device(s) you intend to use via "IP Allocation" under the "Home Network" tab. This is the only supported method by which AT&T gateways can discover names of devices on the LAN for configuration purposes.

 

Enter Static IP Information Correctly

To enter your Static IP information on the BGW210 gateway, from the main page, go to "Home Network" > "Subnets & DHCP" and view the Public Subnet section.
1) "Public Subnet Mode" should be set ON.
2) Allow Inbound Traffic" should be set ON. (ONLY for a router-behind-router situation such as the SonicWall used at this installation. Not for unprotected equipment!)
3) Enter the "Public Gateway Address" assigned by AT&T.
4) Enter the "Public Subnet Mask" assigned by AT&T.
5) Enter the "DHCPv4 Start Address" assigned by AT&T.
6) Enter the "DHCPv4 End Address" assigned by AT&T.
7) Primary DHCP Pool should be set Private by default and remain so if Administrative access directly to the BGW210 is (and should be) required.
😎 Again, ignore the "Cascaded Router" section which is irrelevant and should be OFF by default.

 

At this point, if AT&T provisioned the Static IP Addresses correctly and NO MATTER what ANY AT&T tech tells you, you or a friend should be able to ping and/or traceroute from an external location to the "Public Gateway Address" just entered. Personally, I use the free online ping and traceroute utilities at http://centralops.net/co/ which work great.

 

In our case, it was "discovered" that Static IP assignments MUST be within address ranges that are ALLOWED in the region of the installation. The first three (yes, THREE) sets of Static IP addresses assigned to us were not intended for our region and therefore could not possibly work. I am told provisioning has been corrected but I imagine there are hundreds or possibly thousands of incorrectly-assigned Static IP addresses out there right now!

 

If everything is configured as shown above, a traceroute performed from an external location to the "Public Gateway Address" will have something similar to the following result:

 

 

(real IP address hidden)
Tracing route to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx]...
hop rtt rtt rtt ip address fully qualified domain name
1 0 0 0 208.101.16.73 outbound.hexillion.com
2 0 0 0 66.228.118.157 ae11.dar02.sr01.dal01.networklayer.com
3 0 0 0 173.192.18.212 ae6.bbr02.eq01.dal03.networklayer.com
4 42 30 29 12.252.114.29
5 15 15 16 12.123.235.66
6 11 11 12 12.122.157.33
7 * * *
8 17 24 17 99.183.77.137
9 25 25 2 99.24.65.143
10 25 24 24 xxx.xxx.xxx.xxx
Trace complete

 

 

It is important to note that two (2) routers beyond the 12.xxx.xxx.xxx AT&T cloud are shown between said cloud and the Public Gateway Address. We were previously unable to get anything past the cloud and THAT is when I KNEW something was broken.

 

Remember this is for a router-behind-router situation. If your situation only requires a simple server or two, "Allow Inbound Traffic" in the "Public Subnet" section would have to be turned OFF and "Public Subnet Hosts" under the "Firewall" tab would have to be configured to accommodate your needs.

 

Hope this helps someone else. Good luck!