Helpful Links

How to fake bridged mode with U-Verse

Teacher

How to fake bridged mode with U-Verse

I have worked out a way to simulate full bridged mode between a U-Verse RG and an enterprise grade router.

 

It's not identical to uverse in bridged mode, but it is pretty close.

 

Prerequisites:

  • AT&T U-Verse VDSL service with the Static IP add-on. (I'll be using the 8-ip block in this case)
  • A router capable of running a routing redundancy protocol, such as HSRP, VRRP, or GLBP.
  • A device connected to the internet that is NOT using your u-verse service (For testing functionality from the outside, where it matters. Smart phones work great for this, or just call a friend who has a PC handy)



The problem:

The AT&T RG abuses ARP to ensure that a static IP has to be assigned by MAC address. One MAC = One static IP. This effectively prevents you from routing the whole block to an internal router or firewall, because such devices will respond for all usable addresses using the same MAC. Why the RG chooses to do this is beyond me, but it is what it is and we have to work around it.

(When the RG sees what it thinks is the internal device changing its IP while keeping the same MAC (due to multiple IPs on one interface), the RG will update the device's "current IP address" in the IP Address Allocation tab, and sever all TCP connections to the old address, and the firewall will block all attempts to connect to the old address as it does not see it being registered to any internal device.

Ultimately, this means that if we intend to use our own internal device to protect and control our static IP block, we have to get our device to lie to the RG and present itself as several unique MAC / IP pairs.

This is difficult because by definition, most routers and firewalls only have one MAC and are not capable of generating more. Even high-end Cisco routers do not allow you to add an arbitrary number of MAC addresses to an interface because it shouldn't be necessary -- they assume other devices know how to use ARP.)


The solution:

To solve this, we have to fake out the RG into cooperating. We can accomplish this fakery by doing some protocol abuse of our own -- running a routing redundancy protocol even though we have no peer router to balance with. In this example I'll be using Cisco's HSRP, although in theory this will work with any redundancy protocol that creates virtual IPs and MACs. Routing redundancy protocols use these fake MAC + IP Pairs as floating "virtual interfaces" that would normally flip between two routers running the protocol, so that in the event of a failure none of the clients have to re-learn a MAC and IP. Nobody has to ARP and you get a very quick failover. We're going to use that to fake out the RG.


Assumptions:

  • The static IP range AT&T gave us is 9.1.1.0/29 (.1 through .5 usable, .6 is the RG)
  • We will use .5 as our router's actual address, .1 through .4 will be virtual.
  • When I say "LAN IP range" I am NOT talking about the RG's default LAN range of 192.168.1.0/24, I mean the addressing space we choose to use behind our router handling the static IPs.
  • The LAN IP range behind our router is 172.16.0.0/24
  • We have two computers on the LAN:
  •         PC1 = 172.16.0.100/24, on which we want to expose all services to the world as 99.1.1.2
  •         PC2 = 172.16.0.200/24, on which we want to expose JUST a web server to the world as 99.1.1.3:80
  • We want to provide outbound internet access to all hosts in 172.16.0.0/24 using the router's actual static IP, 99.1.1.5. We will use a NAT overload (or PAT) to accomplish this.

Setup:

Step 1) Log in to the RG and make the following settings changes:

    * Settings
        * Broadband
            * Link Configuration
                * Supplementary Network
                    * Check Enable
                    * Place the router's address (Last usable of the subnet) into the Router Address field.
                    * Fill in the subnet mask
                    * DO NOT check Auto Firewall Open
                    * Save
        * LAN
            * DHCP
                * Make sure "New Device DHCP Pool" is set to "Private Network"
                * Save
        * Firewall
            * Advanced
                * Enhanced Security
                    * Disable Stealth Mode (Useful for troubleshooting)
                    * Disable Block Ping (Useful for troubleshooting)
                    * Disable Strict UDP Session Control (I have found that this can interfere with VOIP apps)
                * Attack Detection
                    * Disable Excessive Session Detection (The RG's definition of "excessive" is a bit small)
                    * Disable Invalid Source/Destination IP Address (For some reason this seemed to interfere)
                    * Disable Invalid ICMP Detection (Seems to block ALL ICMP??)
                    * Save

Step 2) Unplug all but your configuring PC from the RG.

Step 3) Under Diagnostics -> Resets, Clear the RG's device list.

Step 4) Unplug your PC from the RG and reconnect.

Step 5) The RG is now ready to accept statically assigned addresses from our router.

Step 6) Configure the router. This part will require familiarity with your chosen device. I'll provide the commands as a Cisco IOS configuration file with comments. If your device is not a cisco box, hopefully this will give you enough information to configure it properly.


    ! Cisco IOS Configuration File
    ! Version 12.4

! Set up the inside interface
    interface FastEthernet0/0
        description LAN (TO SWITCH)
        ip address 172.16.0.1 255.255.255.0
        ip nat inside
        no shutdown

! Set up the outside interface
    interface FastEthernet1/0
        description WAN (TO RG)
    ! Assign the router the last usable IP in the range (right before the RG)
        ip address 99.1.1.5 255.255.255.248
        ip nat outside
        no shutdown
    ! Slow the HSRP timers down (Don't need to check for a non-existent peer every 1 second)
        standby timers 254 255
    ! This router should be the master (It will never come up otherwise)
        standby preempt
    ! Create a virtual HSRP IP+MAC pair for each usable ip address (Except the one already assigned above)
    ! Make sure that your MACs are unique. I like to start them with 0000 to signify a locally-administered address, and end them with 1 + the three digit last octet of the IP it's associated with. This makes it easier to figure out which is which in the RG's configuration later if anything gets messed up.
        standby 1 ip 99.1.1.1
        standby 1 mac 0000.0000.1001
        standby 2 ip 99.1.1.2
        standby 2 mac 0000.0000.1002
        standby 3 ip 99.1.1.3
        standby 3 mac 0000.0000.1003
        standby 4 ip 99.1.1.4
        standby 4 mac 0000.0000.1004

! Configure our default gateway and default route to be the 3600HGV's address in the static block
    ip default-gateway 99.1.1.6
    ip route 0.0.0.0 0.0.0.0 99.1.1.6

! Use NAT to expose PC1, 172.16.0.100, to the internet on all ports as 99.1.1.2:
    ip nat inside source static 172.16.0.100 99.1.1.2

! Use NAT to expose JUST the web service on PC2, 172.16.0.200, as 99.1.1.3:
    ip nat inside source static tcp 172.16.0.100 80 99.1.1.3 80

! Create a NAT overload (PAT) to allow listed devices share our router's address for internet access:
    ip nat inside source list ACL-INET interface FastEthernet1/0 overload

! Create the ACL-INET Access List and configure it to allow all PCs to use the overload:
    ip access list standard ACL-INET
        10 permit 172.16.0.0 255.255.255.0

 

(CONTINUED IN NEXT POST)

11,998 Views
Message 1 of 18
Tutor

Re: How to fake bridged mode with U-Verse

I'm beginning to understand the 2wire 3801 firmware design:

 

"This is how the RG is behaving. So yes, even with your Static IP's, the RG will still have a WAN address that is outside your static IP range. It doesn't matter though -- because the RG is Routing and not NATing, they will still show up as their rightfully assigned addresses on the internet."

 

It is doing both nat (att IP) and route(att static block) jobs actually.  Your explanation is helpful but I figured that out after it was all setup.  It nat's the att provided IP to my home network on my chosen LAN subnet or 172.x/192.x in the setup page ... which is kinda cool and useful because it gives that network everything it needs (fwall) and the supplemental setup is fairly close to what I would setup if I had a enterprise router.   I hope no problems come from the supp network setup.. i.e.  ... packets aren't  free and clear of interference from the 3801.  That remains to be seen.  I've read of the 3801 interfering with traffic i.e. firewalling when it shouldn't do anything to the packets or only one subnet is allowed to use the full open features.  My config page shows the 3 wide open though. The logs show it is doing some weird stuff  right now to udp traffic.  I might have to monitor things with a packet mon. to be sure like wireshark-tcpdump later. 

 

Thanks d3p~.

 

 

 

Message 16 of 18
Contributor

Re: How to fake bridged mode with U-Verse

Any chance this could be done with a DD-WRT router?

Message 17 of 18
Highlighted
Teacher

Re: How to fake bridged mode with U-Verse

I'm not sure. DDWRT appears to lack the required routing redundancy protocol capabilties that I'm abusing to work around the RG's ARP issues.

 

You might be able to pull it off if you can assign multiple virtual MAC addresses on the DDWRT's WAN interface, but I haven't used it enough to know if that is possible or not.

 

It boils down to this: You have to present your WAN interface to the RG as a set of unique MAC address + IP pairs that will respond to the RG's ARPs as such. If you can pull that off (and then NAT from there), it should work.

Message 18 of 18
You must type a description before you click preview or reply.
Share this topic
Announcements

Welcome to the internet boards! Check out our troubleshooting articles below and don’t forget to search the forums - your question may have been answered already!

Service acting up? Click here to troubleshoot now!

For DSL related issues. We highly recommend chatting with our teams to address this as quickly as possible.

Additional Support