U-verse fun with static-IP

I recently switched to U-verse for TV and Internet. My original plan was to have that while retaining my DSL link for its static IPs.

That turned out to not be possible. But I could get a /29 allocation with U-verse - perfect! Or so I thought.

Installation

The tech who came to do the install was great. Very pleasant guy, who really seemed to know what he was doing. Which was good because we live in Sunnyvale - where the lines are really poor.

He had to get all sorts of things done just to get a clean enough signal to our house, then had to run new line around the house because the existing internal phone lines were a mess.

All in all very happy with the installer.

Configuration

Basic setup was simple enough. We confirmed we were getting at least the speed we were paying for which was nice.

Changing the wireless SSID on the RG (U-verse supplied gateway), was simple enough. Dealing with the static IP's however was not.

My home network sits behind an ns5gt firewall, which used to double as my DSL modem. Some of the initial fun was caused by the non-obvious issue that although the ns5gt had been reconfigured to use its untrusted ethernet port rather than adsl, and showed the physical link was up, it wouldn't bring the logical link up.

Thanks to a Google search I found that only one interface can be in the "Untrust" zone and the ethernet port couldn't be there where it needed to be until the adsl port was removed.

What didn't quite work

Configuring the /29 as an additional subnet was what AT&T suggested. With an address allocated to the RG, and suitable configuration on the ns5gt, this mostly worked.

This would be the preferred setup, since the ns5gt would be able to make full use of the /29 (sans the address consumed by RG) for a NAT pool. As I say it mostly worked, I could get DNS traffic to my main server, inbound SMTP was ok too - outbound SMTP was a problem, more on that below.

However, despite configuration in the RG to allow it; I could not get inbound traffic (eg DNS) to my secondary server, it would be blocked at the RG.

This may be due to the issues described by http://www.ka9q.net/Uverse/static-ip.html in that the RG does not seem to cope with any MAC address appearing to have more than one IP.

What does work

The alternative to the above, is to configure the RG to consider the ns5gt as a cascade router with the /29 network behind it.

In this case the ns5gt needs an IP address allocated by the RG. This works fine - except that we lose a lot of functionality of the ns5gt.

We can configure Mapped IP (MIP) addresses - ie. a 1:1 mapping between a host and a public IP.

But we cannot do any Virtual IP (VIP) or Dynamic IP (DIP) configuration since the /29 is not in the same subnet as the outbound ethernet port.

This means that all traffic from hidden hosts must use a single IP with port mapping. This is not a huge deal considering my network is small, but its really anoying to be paying for a bunch of static IP's without being able to make full use of them.

Outbound SMTP

As mentioned above, outbound SMTP was being blocked upstream. I was able to confirm this by configuring the RG to block SMTP and note that it logged doing so.

When configured to not block it, it didn't claim to be blocking, yet connections were clearly not getting established.

After getting everything else working, a call to U-verse support got that issue resolved pretty quickly.

But don't listen to anyone who tells you they are not blocking outbound SMTP, they do - and considering the amount of SPAM on the net these days, I'm glad they do - by default anyway.

Six months later

Up until this morning (2016/04/19) the configuration above was working fine. The ns5gt had its untrust interface configured from the RG private network (192.168.1.*), and it was configured as DMZplus (ie. no firewall in the way).

This morning my wife reported that the network wasn't working...

Sure enough the ns5gt had no upstream connectivity. I reset the RG WAN link - usually fixes things.

It didn't. I reboot the RG. That didn't help either. Time to look deeper.

I could see from the IP Allocations page that the IP associated with the ns5gt had changed to something very different. For the life of me I could not recall which page on the RG web interface one needed to look at to see the config for the cascade router.

Foolishly I called AT&T - the stupid voice recognition thing always drives me nuts and the old trick of hitting 0 repeatedly doesn't work. By the time I got through to a human, I'd discovered that wireless via the RG was still working and found the answer I needed via Google.

So the issue was not WAN connectivity.

As I poke around I note that the IP now associated with the ns5gt is the same as the RG WAN interface - that isn't going to work well.

To play nice, I configured the ns5gt to use that address for its untrust interface. I could then ping the RG and things beyond it from the ns5gt itself, but from behind it nothing worked - not very surprising.

I tried to configure the RG back the way it had been for several months but it wouldn't let me. In particular, it would not let me give the ns5gt a static IP and then assign it the DMZ role in the firewall.

It claimed the DMZ role/flag could only be set for an IP obtained from DHCP - that seems to be new. Great; so I go reconfigure the ns5gt to use DHCP, and get an IP.

I can ping things from the ns5gt but not from behind it. I go back to the RG - need to reset the DMZ flag to get rid of the silly firewall, it says doing that will trigger getting a new IP from DHCP - Ok, who cares right?

But the ns5gt didn't get a new IP and things stopped working again. Go back to the Link Configuration page and we once again have the WAN IP address associated with the ns5gt. Back to square one.

By this stage I'm totally unimpressed, and AT&T tech support was no help at all. They kept trying to tell me I needed to hire someone to tell me how to configure the ns5gt; I'd explain that no, I needed someone to tell me how to make the ATT box behave.

Workaround?

So right now I have connectivity re-established but no telling for how long.

After the RG again associated the WAN IP with the ns5gt, I just entered a static IP for the cascade router that matches what the ns5gt got from DHCP.

Everything works again - I can ping the world, and inbound services work as they should so the RG firewall has not kicked back in.

But whether it will still be working in 24 hours remains to be seen.

Fixed?

Sure enough next morning we were broken again. The ns5gt had been given a new IP by the RG - which is unusual; most DHCP servers will renew the same lease.

Time for more serious measures.

I configured the ns5gt to not use DHCP, and to use the .253 address and then reconfigured the RG DHCP pool to not include that address and set that static IP for the cascade router in the Link Configuration page.

BTW turning off DHCP on the ns5gt is much more painful than turning it on, since you have to first deconfigure half the firewall rules. Oh for the Junos configuration commit model....

The RG still thinks the ns5gt is using DHCP, and is allowing it to have the DMZ flag - which I hope is based on its mac address rather than any IP allocated to it.

Maybe not... I just got a call from my wife, she says she cannot get to some web pages - she gets this from the RG:

Router Behind Router Detected
   Error: The Connection Monitor has detected a third party router
   connected to the 3801HGV
   If you want to connect additional computers or devices to your
   network:
   Click the Resolve button below to enable the Connection Manager to
   correct the problem. There may be a delay of up to one
   minute while the Connection Manager resolves the problem.
   Click the Disable button below if you want to continue
   using your Router behind Router.
   WARNING: Many applications may not work in this case.
   For detailed information regarding this issue, please click on the
   link
   below:
   Router / Router Information

   Please enter the password here before proceeding:
   Password: ____________________
   Resolve Disable

Sure enough when I get home I see we lost the DMZ flag, and could not get it back unless I use DHCP again. What a crock.

So its working now but who knows for how long. I increased the DHCP lease time to 10 days to reduce the damage.

This 3801HGV thing is rubbish

Ok, lost connectivity again. When I left for dinner the ns5gt had been given the IP 192.168.1.10

Now when I look at the RG configuration, every page shows a different IP associated with the ns5gt!

On the Link Configuration page it shows the cascade router assigned to ns5gt-adsl-wlan with IP 192.168.1.64

On the LAN page it showed ns5gt-adsl-wlan with IP 192.168.1.98

On the Firewall page it shows DMZ for ns5gt-adsl-wlan with IP 99.46.... (same as RG WAN interface)

And the ns5gt still had the same 192.168.1.10 it had been given earlier.

If I go to the details page for ns5gt-adsl-wlan it too shows IP as 192.168.1.10.

Everywhere I look there is a different IP associated with that same MAC.

This would be so simple to fix, if the stupid thing would just let me statically configure IP's and set the DMZ flag or otherwise disable the firewall for that IP.

Despite DHCP being told to use 10 days as default lease time this RG is giving the ns5gt a new IP every time I look, and everytime it changes the IP, it drops the DMZ flag. Absolutely and utterly useless.

I have no objection to a box like this being super nanny by default, but you should be able to configure it, and it should keep the configuration.

Log

Let's start logging....

2016/04/19      had to reconfig (several times)
                link connection page had junk, and DMZ flag lost again

2016/04/20      had to reconfig
                link connection page had junk, and DMZ flag lost again

2016/04/23      had to reconfig
                link connection page had junk, and DMZ flag lost again

In fact I now have an hourly cron job to test Internet access and the IP address of ns5gt, which should help show if the loss of connectivity corresponds with change of that IP:

Apr 23 08:30:17 bad webcheck[362]: web access: NO IP: 192.168.1.11
Apr 23 17:12:58 bad webcheck[14812]: web access: OK IP: 192.168.1.12
Apr 25 08:20:24 bad webcheck[25574]: web access: NO IP: 192.168.1.12
Apr 25 08:31:13 bad webcheck[24488]: web access: NO IP: 192.168.1.11
Apr 25 08:31:51 bad webcheck[15439]: web access: NO IP: 192.168.1.11

The above are all from manual runs - the cron job ran at 08:05 and everything was ok - at 08:17 my wife couldn't access some web page getting the above Router Behind Router message again.

So I ran the checker at 08:20 - interesting we can lose the DMZ flag without getting a new IP.

I go to the RG web ui, it still has the correct configuraton on the Link connection page, but the firewall lost the DMZ flag. Set it again - it won't let me it says the device has a static IP. No it doesn't...

So I go back to the ns5gt to get it to try to renew its lease (which it shouldn't need to do for several days). Eventually at 08:31 we get a new IP, but still not working.

I go set the DMZ flag on ns5gt, still not working. Now the Link connection page needs changing. Still not working, we lost the DMZ flag again.

Try to set it, it won't let me since it says another device has it. I probably forgot to do the stupid select device step. Go change setting for that device. Now try to set it for ns5gt - it still says the other device has it.

Reboot the bloody thing.

Didn't help. Damn it, I cannot get the DMZ flag to stick to the box I want it on and now I cannot remove it from the box that accidentally got it! Which means I cannot set it on the box I want it on.

Ok, the only way to get rid of DMZ flag on the other box was via the IP Allocation page - obvious. Finally:

Apr 25 08:56:46 bad webcheck[26895]: web access: OK IP: 192.168.1.12

but for how long...

Not long as it turned out. Almost as soon as I left:

Apr 25 09:06:15 bad webcheck[27872]: web access: NO IP: 192.168.1.12
Apr 25 10:05:30 bad webcheck[383]: web access: NO IP: 192.168.1.12
Apr 25 11:05:30 bad webcheck[26812]: web access: NO IP: 192.168.1.12
Apr 25 12:05:30 bad webcheck[12470]: web access: NO IP: 192.168.1.12
Apr 25 13:05:30 bad webcheck[18493]: web access: NO IP: 192.168.1.12
Apr 25 14:05:31 bad webcheck[21766]: web access: NO IP: 192.168.1.12
Apr 25 15:05:31 bad webcheck[15443]: web access: NO IP: 192.168.1.12
Apr 25 16:05:30 bad webcheck[556]: web access: NO IP: 192.168.1.12
Apr 25 17:05:30 bad webcheck[22661]: web access: NO IP: 192.168.1.12
Apr 25 18:05:30 bad webcheck[17819]: web access: NO IP: 192.168.1.12
Apr 25 19:05:30 bad webcheck[657]: web access: NO IP: 192.168.1.12
Apr 25 20:05:31 bad webcheck[20339]: web access: NO IP: 192.168.1.12

The Link configuration page - again had wrong IP associated with cascade router...

Kudos to AT&T - new box 5268AC

I mentioned my hassles on their forums, and that I was going to call for a new router, and within a few hours got an offer take care of that.

Sure enough within 48 hours I have a new box - powering itself up. That's pretty good by any standard.

Interestingly, this new box won't let me disable the firewall from a private address DHCP or not and the ns5gt doesn't even show up in the firewall page.

But that does not appear to interfere with out going web activity. Let's check inbound services... DNS, HTTP, SMTP all Ok.

Apr 26 21:01:40 bad webcheck[11737]: web access: OK IP: 192.168.1.64

That's all that matters. The switch over was totally painless too. Let's hope it lasts.

Update 2018

Nothing lasts forever...

A couple of times now, the UVerse RG has lost track of what the cascade router should be.

I have to go to it's web-ui and find the Settings->Broadband->LinkConfiguration page, and set the cascade router again to be ns5gt.

Lesson: keep notes

Update 2019

Over the last 12 months I have had to reconfigure the cascade router selection on average once per month.

I have replaced the ns5gt with a much newer (bigger and noisier) srx box.

The srx has a much nicer user interface (CLI) and provides much better controll over NAT. It is now possible for me to utilize the unused addresses in my /29 as a NAT pool.

IPv6

AT&T provide a routable IPv6 prefix, but turns out to be a /64 which I'm told is not subnetable. This rules out any useful config and effectively makes IPv6 (the answer to IP address shortage) of less use to me than IPv4 with my /29 allocation. Ridiculous.


Author:sjg@crufty.net /* imagine something very witty here */