- AT&T Forums Home
- /
- U-verse Forums
- /
- U-verse Internet
- /
- Features and How To
- /
- Re: configuring devices behind the Public Routed S...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
01-03-2009 03:21:36 PM
It is a counter-intuitive configuration, so after trial and error for the past few hours, I've figured out how to do it. The directions are:
Open a web browser to your homeportal (default is 192.168.1.254)
Have the password for your 2Wire gateway handy
1. Click the Home Network icon and then click Advanced Settings
2. Enable the Public Routed Subinterface
3. Enter the public routable IP address that AT&T assigns you as the gateway into the Router Address box, and the Subnet Mask that they've assigned you in the Subnet Mask box.
4. To set up your first device, connect it to the 2Wire Home Portal, and set it up to use DHCP. The device will take a private address from the 2Wire.
5. Click the box on the right side of the Advanced Settings window named "Edit Address Allocation"
6. Find the device that you want to put the Public IP Address onto.
7. Uncheck the "Firewall Protection" box to turn off the inbound firewall to that device (if you wish, you can leave it checked and only open the ports that you need to use in the Firewall configuration)
8. In the "Address Assignment" associated with your device, click the dropdown box and find and select "Public (select WAN IP Mapping)"
9. In the WAN IP Mapping, choose the address that you want to use from the dropdown box
10. Click "Save" at the bottom of the page. When the page refreshes, you'll see that your device needs a "DHCP Renew"
11. Go back to the device that you want to connect, and refresh its DHCP address (on a Linksys or Netgear router, you can just click Save Settings or Apply on the Setup window to refresh the DHCP address). The results of the DHCP renew can be seen on the Status page of either device, or on a Windows PC, using the "ipconfig /all" command in a CMD window.
12. On the 2Wire Home Portal, click Cancel to return you to the Home Network > Advanced Settings window, and you'll see that your device has taken the new public IP address. If you click on the "Edit Address Allocation" again, you'll see that your Device Status is "Connected DHCP"
13. After doing this, I went back to my device and set the IP address in the setup to a static IP.
Adding a second device is a basic repeat of the procedure. I'm having problems right now adding a 3rd device, which may require that I restart the Home Portal - I'll do that later tonight and report back on the status of the 3rd device.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
01-03-2009 03:49:19 PM
Good job airwrck! Very useful info... ![]()
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
01-03-2009 06:19:19 PM
That's awesome. It's nice to know that static IPs are available, and that it works with publically routable IPs. This enables using enterprise-class routers for doing things that won't work behind NAT, like IPSec VPN tunnels.

Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
01-24-2009 09:43:17 AM
How do you do this without DHCP? We had UVerse installed with 32 IP addresses for a client install and the technician had no idea how to make it work. I need my firewall behind the router to have all the IP addresses assigned to it, and obviously it cannot DHCP all of them from the RG. The installation tech had no idea how to do it. She didn't even know what a 66-block was and we had to terminate the pairs for her.
Chris Green
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
03-02-2009 08:18:59 PM
I have the same need. The devices I have behind my RG can't do DHCP (firewalls, etc). Right now I don't see another option other than plugging in 14 random PCs into it so an entry will show up in the RG web interface and allow me to turn the firewall off.
If I don't do this, and instead just statically configure a device with one of my assigned IP addresses behind the RG I can make outbound connections, but the RGs firewall drops any incoming connections. That's unacceptable. I have a business u-verse line, with static IPs. I don't want the RG stepping on my connections.
There needs to be an easier way to turn the firewall off for these static IP plans. I can't imagine how you would do this with larger blocks. Seriously annoying!
Has anyone figured out how to setup the static IP addresses properly without resorting to DHCP?
Thanks,
Doki
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
03-13-2009 06:14:47 PM
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
03-15-2009 09:29:03 AM
From the "Firewall Settings" page (this is a "radio button option at the bottom of the page):
"Allow all applications (DMZplus mode) – Set the selected computer in DMZplus mode. All inbound traffic, except traffic which has been specifically assigned to another computer using the “Allow individual applications” feature, will automatically be directed to this computer. The DMZplus-enabled computer is less secure because all unassigned firewall ports are opened for that computer.
Even though the "real" outside gateway address is different than that block you were issued, the addresses in the block you were issued are (should be) in the routing table on the provider side (like "get to this block of addresses (the block of public IPs), via this address" (which it the outside address of the RG).
Once you are "inside" your firewall/gateway/border device, any of the addresses in your public block should be valid for whatever you wish to do with them (as long as the port has not been assigned in the RG's port forwarding table), at least that's the way I'm reading it.
It does sound like you'd need one extra device, so the NAT from RG{outside} to FW{outside} gets you to your block, then the assigned publics would be available for whatever further translation you need (i.e., one address for Web, one for email, one for VPN ...). So something like a traditional "choke" router or straight-up firewall feeding the "outside" interface of your "real" router would fit the bill.
Your other (probably more normal) setting would be under the "Advanced Settings" button under "Home Network" tab. At the lower left is a box with a checkbox and config fields for "Public Routed Subinterface" where you specify the address and block.
The instructions are here:
http://support.2wire.com/?page=view&article=126&te
They cover several versions of firmware, but I think you want the info provided from ~"2b" on down.
That link came from the 'help" button at the topright of the "Advanced Settings" button under the "Home Network" tab, then entering "Public Routed Subnet" in the search bar at the top of the 2Wire help screen.
Good Luck
Scott
I am an AT&T employee and the postings on this site are my own and don’t necessarily represent AT&T’s positions, strategies or opinions.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-09-2009 08:31:17 PM
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-10-2009 08:13:52 AM
fleish wrote:
I'm having problems with this also. No matter what I do (even if I make no changes to the address allocation page), when I hit submit I get the "Invalid address assignment" error.
What settings are you trying to add / change?
You may first have to power cycle either the RG, the attached device, or both between steps. The attached device will not get it's proper address assignment (to the device's WAN port) won't happen until you restart the device (it has to be DHCP enabled, and the RG will give it the address of its outside/WAN port).
I am an AT&T employee and the postings on this site are my own and don’t necessarily represent AT&T’s positions, strategies or opinions.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-10-2009 10:32:30 AM
"What settings are you trying to add / change?"
I tried both changing a device from a private IP to a public. I also tried changing nothing & just hitting submit. Why would the device or the Uverse GW need to be power cycled? One thing I've been very impressed with is the Uverse GW's "reboot resiliency" compared to the more common Linksys home GW products. That is to say for many changes I've made to the Uverse GW a reboot was not required, while those same changes on a Linksys GW would trigger a reboot. It doesn't make sense technically that a reboot would be required, and if one really was then you'd think the Uverse GW's OS/firmware would perform one. In this case, I suspect something else is wrong because even without making any changes, submitting this page throws the same error.
The more I try to work with this service the more I want to throw it out in favor of something else. Spent 55 minutes on hold last night for tech support on my way home & then AT&T Wireless decided to drop my call. Not good.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-10-2009 12:39:19 PM
Once you configure the target device as the DMZ device in the RG's firewall config, the RG uses the IP address you give it as pull the MAC of the device. A flag is set in the RG to provide that MAC with the same IP address as the external interface of the RG.
The hook is that if you don't reboot the DMZ device within a few minutes, the configuration reverts (i.e., it goes back to getting another internal address. The DMZ device also needs to be set for DHCP on its external interface (which should be plugged into one of the RG's Ethernet ports).
If the DMZ device is not set for DHCP, if the DMZ device is not power cycled (or otherwise inspired to ask for a DHCP address), if you wait too long, if the RG firewall is not configured for a DMZ device ..... then it won't work. There are probably a few more "ifs" but these are the most-often missed.
Good Luck
I am an AT&T employee and the postings on this site are my own and don’t necessarily represent AT&T’s positions, strategies or opinions.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-10-2009 04:06:51 PM
You don't have to reboot the device or the RG.
The RGs broadband IP address is "shared" with the DMZplus host. You can just disable and enable the NIC. For many users it is just easier to restart the computer then figure out how to disable and then enable the NIC. For the DMZplus feature to provide the public IP address to the client configured in the DMZplus, the client needs to get the public IP.
Dave
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-10-2009 04:52:31 PM
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-11-2009 06:34:35 AM
No, recent posts have been on the basic changes that require a restart or not.
Could you explain your configuration in a lttle more detail? For example how many Public Routable IPs do you have and why do you want to use DHCP to provide the public IP to a client device?
The normal purpose of public routable IP addresses is to have a known public IP address assigned to a specific host. The RG will work very well if you just configure the "Public Routed Subinteface" http://192.168.1.254/xslt?PAGE=J09&THISPAGE=J10&NE
Yes the RG can manage / provide pubic routed IPs via DHCP here: http://192.168.1.254/xslt?PAGE=J10&THISPAGE=J09&NE
The error message that you are reporting is on what page and what steps lead you to the action that is producing the error?
Dave
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-15-2009 12:30:26 AM
"Could you explain your configuration in a lttle more detail? For example how many Public Routable IPs do you have and why do you want to use DHCP to provide the public IP to a client device?"
It's pretty simple really. Currently I have a client that has a static, private IP address. I have a /29 of public routable IPs. I don't want to use DHCP to provide the public IP to the client device. However, I've tried assigning it a static address out of the public range and that fails just the same.
"The error message that you are reporting is on what page and what steps lead you to the action that is producing the error?"
It's on the edit address allocation page. To reproduce it I only need to hit submit, without even changing anything.
Since I've not gotten it to work before, how does it do it? Does it just setup a 1:1 NAT and still assign the "client" a private IP address? Or does it actually hand the client a public IP?
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-10-2009 07:01:40 AM
Howdy Dave006 and others
You posted that 'The RG will work very well if you just configure the "Public Routed Subinteface" http://192.168.1.254/xslt?PAGE=J09&THISPAGE=J10&NE
I looked at my page and it did not have anything. I then went to http://192.168.1.254/xslt?PAGE=C06&THISPAGE=C01&NE
Do you know why the two pages are different?
Thanks,
Gary
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-20-2009 07:44:48 PM
Hi. I just got U-verse installed yesterday so I'm still struggling with it. Your problems sound very familar, starting with the complete and utter lack of training and support by the AT&T people. But I've been playing with TCP/IP for a long time, and I enjoy a challenge.
I rediscovered what others here have already discovered: that if you just start using your static IP address block, the gateway will allow only outbound connections and block all incoming ones. What's the point of static IP addresses if you can't accept incoming connections!!! There really needs to be a button to simply disable all this firewall crap for static addresses.
I also discovered that in order to turn off the firewall for a static host, you must first have that host pick up a dynamic IP address with DHCP just to get it to appear in the table so you can select it to change its settings.
And I discovered something else that is pretty much of a show stopper, at least with my present configuration. My Linux servers MUST have two IP addresses, one in the static block so they can be reached from the outside world AND they must have an address in the non-routed 192.168.1.0/24 block so that their local clients can talk to them directly.There being no way within the gateway configuration pages to assign more than one address to each host, I simply added a second IP address from the 192.168.1.0/24 range, below the DHCP allocation block, to the Linux machine's ethernet interface. But the U-verse gateway apparently detected this, probably by observing its ARP broadcasts, and revoked the global static address I'd previously assigned to it, thus taking it off the outside network! This is obviously unacceptable.
I'm learning again a lesson I've learned many times before: use the absolute minimum of services and features from a network carrier's equipment, because they're probably broken or brain-dead in some unacceptable way. Provide as many of those features yourself as you possibly can.
So my plan is to insert a Linux-based router between the U-verse gateway and my local network and have it run a DHCP server for all the computers in our house except the U-verse settop box, which will remain plugged directly into the U-verse gateway. My router will proxy-arp for every address in my static block and route those packets to my main local network; hopefully this won't confuse the U-verse gateway too badly.
This will prevent the computers on our network from talking directly to the set top TV box, but I'm not sure that matters; are there any useful services running on the set top box? I see it listening on ports 8080 and 8086 but they don't seem to be webservers.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-21-2009 02:18:36 AM
Yeah, I only got Uverse installed on Thursday but I'm having trouble believing that the software in this piece of junk really IS this badly designed. I must be missing something simple. But if so, then so are you guys. I'll keep beating my head against it through the weekend, and if I still can't figure out a workaround I'll disconnect Uverse in disgust. I'm beginning to think that the only way I'll ever get anything resembling a simple block of unfiltered static IP addresses at home is to set up an OpenVPN node in a colo somewhere.
It must have taken a lot of effort to screw up something as conceptually simple as routing a static IP address block. Why would anyone want static IP addresses on which you can't turn off a firewall?
No wonder you can only get 2WIRE products through a service provider. Nobody in their right mind would buy one on the open market if they had a choice to buy anything else.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-21-2009 07:26:14 AM
Tell ya what, cut all the flak and just explain what you want to do.
Whine whine whine ....
I am an AT&T employee and the postings on this site are my own and don’t necessarily represent AT&T’s positions, strategies or opinions.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-21-2009 02:27:25 PM
What do I want to do?
I bought a block of static IP addresses. I actually want to use that block of static IP addresses with the computers on my home network.
I DO NOT want my host computers to have to speak DHCP to get one of those static IP addresses. I just want to statically configure each system with an address from the block.
I DO NOT want ANY kind of firewalling, port or protocol blocking on these static IP addresses, in either direction. None whatsoever.
Is this too much to ask for?
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-21-2009 03:12:33 PM
Sounds easy, the 2-Wire RG can help you with each of your stated requirements. You just have to understand that the RG is a router in addition to being just a VDSL modem. I responded inline each of your questions.
ka9q wrote:What do I want to do?
I bought a block of static IP addresses. I actually want to use that block of static IP addresses with the computers on my home network. Fully supported by the RG, just hardcode one of your Public Routed IP addresses, subnet, and the Public Routed Gateway address in each client machine that you want use in the public routed block.
I DO NOT want my host computers to have to speak DHCP to get one of those static IP addresses. I just want to statically configure each system with an address from the block. Not an issue, the RG will auto detect the usage of the Static IP if you choose to use that instead of using one of the 3 DHCP mapping options that 2-Wire recommends.
I DO NOT want ANY kind of firewalling, port or protocol blocking on these static IP addresses, in either direction. None whatsoever. Again the RG supports this but by default it provides inbound protection, yet allows you to easly configure the Firewall to allow individual services or use the "Allow All Applications" setting on the Firewall configuration page to allow all unsolicited inbound traffic through to each client.
Is this too much to ask for? No, and the RG meets all your stated requirements, please let us know if you need additional assistance configuring your Static block of public routed IP addresses....
Dave
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-21-2009 09:29:58 PM
I understand that it's not just a VDSL modem. That's precisely the problem.
I am making progress, though. I disconnected everything on my network and cleared the gateway list of local hosts. I set "Auto firewall open" on the Edit Advanced Home Network Settings page. Then I connected one host at a time, statically configuring each one and checking that it could ping the router.
It took several minutes, but each host eventually showed up in Home Network - Summary. I clicked on Edit Firewall Settings for the new host and verified that it had "allow all applications (DMZplus mode)" checked.
My underlying problem was that the Uverse gateway changes its state when it discovers a statically configured host, which it apparently does by snooping on ARP broadcasts. This is both undocumented and not something I expected a router to do. And it took me a long time to realize what was going on because it takes the gateway several minutes to discover each new host. Definitely not in keeping with the Principle of Least Astonishment.
The reason this is a problem for me is that I want each of my servers with a globally routable IP address to also have a secondary local address so they can talk to their local clients without looping any traffic through the Uverse gateway. (I have a lot of gigabit Ethernet.) Whenever one of my servers used a secondary address in the 192.168.1.0/24 block, or in fact ANY secondary address, the Uverse gateway snooped on it, got confused and apparently assumed the server didn't need its globally routable address anymore. It apparently never occurred to the designers of the Uverse gateway that anyone would ever want a server to have more than one address.
To work around this, I've had to separate the Uverse LAN and my regular home LAN. (The Uverse set-top box remains directly connected to the Uverse gateway, of course). Each server has two physical Ethernet interfaces. The one on the Uverse gateway has the globally routable Uverse address and the other interface has an address in the 192.168.2.0/24 block on my regular home LAN. This keeps the Uverse gateway from seeing and becoming confused by my intra-LAN traffic.
One of those dual-homed servers is a homegrown Linux-based router that uses its static routable Uverse address to provide DHCP, NAT and 6to4 services to the clients on my regular LAN. This lets me specify the DNS server and search domain, something the DHCP server in the Uverse box apparently doesn't do.
I'm still able to talk from the house LAN (192.168.2.0/24) through the NAT in the Linux server to the configuration webserver in the Uverse gateway (192.168.1.254), but any clients on the Uverse LAN are unable to talk to servers on the regular house LAN. That means the WiFi AP that's built into the Uverse gateway isn't very useful, but that's no big loss since it's 802.11g only.
At some point I might look into using a filtering bridge instead of an IP router between the Uverse gateway and my house LAN to block traffic that I don't want the Uverse gateway to see.
Thanks for your help and advice.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-22-2009 08:37:37 AM
As you've discovered, the RG routes traffic by MAC address, not by IP. The limitation in this method is that the RG does not handle multihomed interfaces (e.g. more than 1 IP address with the same MAC address).
If you can configure your Linux servers with multiple logical subinterfaces on a single NIC, and have each subinterface use a different MAC, you can use only 1 NIC instead of 2.

Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-22-2009 04:01:22 PM
Actually, I can't say I'd discovered that the RG routes traffic by MAC address. If it did, that would make it a bridge, and I'd be far happier with a simple bridge. All IP routers, by definition, route by IP address. The problem with the Uverse gateway is that it tries to be clever and only shoots itself (me, actually) in the foot.
If it is also going to act as a DHCP server, a feature I should be able to turn off, it should give me a simple means to enter a list of MAC addresses and desired fixed IP address allocations. MAC addresses not on the list should either be given an address from a dynamic pool or rejected, at the user's option. The box should use ARP only for its intended purpose and not modify its firewall state in response to what it sees in those packets. (I haven't confirmed that it's definitely using ARP in this way; it might also be monitoring what Ethernet and IP source addresses appear in regular data packets. This is hinted at by the "enable router behind router alert" option. Naturally, none of this is documented in any meaningful way.)
And there's no way to get all of this brain damage out of the way. Even with the firewall still supposedly open I still see it filtering some incoming TCP ports (at least 445, 139, etc). I don't know yet whether it blocks any other protocols, as there's no mention of anything but UDP and TCP on the firewall page.
I also see that outbound TCP port 25 is blocked. I strongly prefer to run my own outbound mail relay, and this was one of my reasons to get a static block since so many ISPs misguidedly reject mail from dynamic and dialup IP pools. I don't know if the Uverse gateway is doing this, or if it's somewhere inside AT&T's network. I am not a spammer, and I resent the assumption that I am. I just want to use the Internet in the way that it was originally designed.
As a matter of principle I don't want my service to block ANY TCP or UDP ports or IP protocols whatsoever. My computers can protect themselves. For addresses in the the static block there's no reason for any router to even look past the IP header at the transport (TCP, UDP, ICMP, etc) header. Probably the biggest mistake we ever made in developing TCP/IP was in not making IPSEC mandatory on all traffic to stop this kind of filtering nonsense and to kill NAT in its infancy before it became the horrible monster that it is today.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-22-2009 04:29:56 PM
It technically doesn't "route" by MAC address, it still routes at layer 3. But once it has learned of a MAC address on the network, it continuously sends ARP packets to it and updates it's internal ARP cache with whatever IP is there. This is why multihomed devices don't work - the ARP cache table constantly changes as it sees different packets with different IP addresses.
The DHCP server can't be turned off because the U-Verse STBs need to get the AT&T DNS server information via DHCP. If you ran your own DHCP server, you would have to program specially to hand out the correct info to the U-Verse STBs.
If you have set a device to DMZPlus, the RG should allow everything. I have run a Cisco 2811 router behind the RG in DMZPlus, and was able to pass non-TCP/non-UDP IP protocols like GRE/ESP/AH with no problems.
Outbound port 25 is blocked in AT&T's network by default (not blocked in the RG) for spam control. AT&T will turn off the port 25 block on request, just call technical support and tell them you want them to unblock port 25 for you.
Just so you know, the proper way to set up your servers to use a static IP with no blocking is:
- Log into the RG, go to Home Network -> Advanced Settings.
- Enable the Public Routed Subinterface, put the IP address within that block that you want the RG to have, and put in the subnet mask. You probably already know, but the first and last addresses of your static IP block (likely a block of 8) are not usable.
- Assign a static IP from your block to a server. From that server, ping the RG's static IP so that the RG caches it's MAC address and IP in the ARP cache.
- Go back to the RG, go to Home Network -> Advanced Settings.
- Click the "Edit Address Allocation" button in the lower right.
- Find your server in the list. Under the Address Assignment, verify it says "Static IP - no DHCP".
- Under the WAN IP Mapping, select the IP address from your static block that you assigned to the server.
- Uncheck the "Firewall Protection" checkbox on the left.
That server should now be open to all traffic from the internet on that static IP.

Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-22-2009 05:54:48 PM
Hi Joe, thanks again for the information, you've helped me get everything here into a fairly reasonable state.
I haven't tested all the protocols I'll want to use, but at least one of them (IPv6 in IPv4 tunneling) does indeed seem to work.
Thanks much for the information about port 25 blocking, that's just what I suspected. I'll call AT&T as you suggest.
I note an unused RJ-45 on the back of the gateway labeled "Broadband". Apparently it can work with an external modem, connected by Ethernet. Perhaps if I can find a standalone VDSL2 modem somewhere, I could use it in place of the one built into the gateway and thereby gain direct access to the network for my own router. It should be easy enough to figure out the necessary VLAN IDs and so forth.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-22-2009 06:06:11 PM
ka9q wrote:
I note an unused RJ-45 on the back of the gateway labeled "Broadband". Apparently it can work with an external modem, connected by Ethernet. Perhaps if I can find a standalone VDSL2 modem somewhere, I could use it in place of the one built into the gateway and thereby gain direct access to the network for my own router. It should be easy enough to figure out the necessary VLAN IDs and so forth.
The broadband port is used with Fiber-To-The-Premises (FTTP) installations. The Optical Network Terminal (ONT), which replaces the NID on the side of the house, feeds the RG through this connection.
Unfortunately, standalone VDSL/VDSL2 modems won't work with U-Verse. The RG authenticates with the upstream servers using unique X.509 certificates that are stored in the RG. Stand-alone VDSL products will not authenticate, and the virtual circuits will never come up.

Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-22-2009 07:13:24 PM
I'm not trying to turn off the uverse gateway entirely; why can't I connect it and my own router with an Ethernet hub to a standalone VDSL2 modem and let the U-verse box handle all the authentication? The U-verse gateway box should continue to handle the original dynamic IP address, any of its NAT users, and all my video traffic just as though I never had a static IP address block. That would be handled separately by my own router.
By the way, on your advice I fired up a chat with AT&T customer service and asked them to turn off port 25 blocking. Within minutes it was off and I was sending my own mail. I can't believe it was that easy! Thanks.
Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-22-2009 07:24:46 PM
I don't think anyone has ever tried that, but it doesn't seem like it would work. If you had your own VDSL2 modem, and it connected to a switch in which you had both the RG and your router plugged in, it's possible the RG would be able to authenticate and come up, but your router wouldn't. All traffic from AT&T would be directed to the RG, and your router, even if it authenticated, couldn't get an outside IP address, and it can't share the one assigned to the RG.
I doubt seriously that you could get AT&T to route your static IP block to your own router.

Re: configurin g devices behind the Public Routed Subinterfa ce
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
11-22-2009 11:48:15 PM
One problem I'm still having: traceroute doesn't work. I don't seem to be getting ICMP messages back. I can't see any reason they shouldn't come back to a host with a routable address (no NAT) unless a firewall is blocking them.








