AT&T Fiber Uverse Gateway Elimination

AT&T Fiber Uverse Gateway Elimination

Those home users fortunate to be in a fiber area have been forced to use the supplied gateway to gain internet access.  The gateway does a double nat of sorts, even in the so called passthrough mode. Limitations include 8K (or less) nat table.

Through a series of convoluted steps, it's now possible to completely eliminate the gateway box allowing UTM to handle the connection directly from the ONT.

In essence, one must obtain the certificates/credentials from a gateway box.  The easiest method for the lay person (me) was to obtain a gateway on ebay that hasn't been updated and was still rootable.  Other methods include pulling the flash chip and reading in a chipreader and/or other root methods not publicly disclosed. Using another tool the necessary credentials are extracted from this data resulting in several certificate files.

The 802.1x authentication used by the ONT will handled by a third party wpa_supplicant component as this module is not present in the utm OS.

Other functions include starting the wpa_supplicant daemon at startup and a watchdog in case it crashes.  Scripts are not the most robost or efficient but are enough to get the job done.

For full details, see this thread on dslreports -  Note the link in the first post referencing a later post (in the same thread). Usual disclaimer; installing third party components is not supported nor recommended, so proceed at your own risk.

  • Next challenge is to get ipv6 working.  Seems UTM pulls absolutely nothing.

    Anyone with UTM using any sort of bypass method with att fiber get ipv6 working?  How?

  • Thread over at dslr updated with some resolved issues.  See links in the first post.

  • In reply to Jay Jay:

    Made some headway in getting ipv6 going - content below is from a recent post in the dslr thread but is probably better suited to be posted here.


    Somehow (still not exactly sure), I managed to get the /60 delegated prefix. After having the bgw210 (att provided gateway) hooked up it would only get a /64 DP, not /60. According to the logs, around 3pm (3am too), it switched over to /60. Still a big question mark how??

    The pic below is based on using the cert's (802.1x, different gateway) mac, not the bgw's. The key lies in deleting the /var/sec/chroot-dhcpc/var/db/ethX_na.leases6 file before issuing a renew using (change eth reference to that of your wan ethX port).

    chroot /var/sec/chroot-dhcpc /usr/sbin/dhclient6 -6 -P --prefix-len-hint 60 -d -D LLT -cf /etc/eth4.conf6 -lf /var/db/eth4_na.leases6 -pf /var/run/ eth4

    As noted from above, this results in a 2001::x/128 address assigned to the wan interface and 2006:xx/60 DP.
    Enabling ipv6 on a windows pc yields this.

    IPv6 Address: 2600:1700:xxx:xxxx:xxxx:xxxx:xxxx:xxxx
    Temporary IPv6 Address: 2600:1700:xxx:xxxx:yyyy:yyyy:yyyy:yyyy
    Link-local IPv6 Address: fe80::xxx:xxxx:xxxx:xxxxs
    IPv6 Default Gateway: fe80::yyy:yyyy:yyyy:yyyys

    1) Is this desired outcome? Note there's no subnet defined (like in one of the pics you sent me).

    2) Web browsing appeared to be broken with web filtering enabled. Disabling it still didn't work until I added the internet ipv6 object as a destination to the firewall rules. This means web filtering isn't working for this arrangement even though internal network is defined under web filtering, allowed networks.

    I can sort of understand why. In essence the client is assigned a public IP, not one that's routed through the utm. BUT..... this defeats the purpose of using web filtering in the first place. Thoughts on how to fix this?

    3) Other observations;

    a) Anytime interface object is edited, wpa_cli shows an 802.1x authentication sequence ~35 seconds later. Lots of wasted 35s intervals during all the testing!@# Work around: after making interface change, in wpa_cli, issue a logoff, then ~2-3 s later, a logon. It will reauthenticate immediately.

    b) Mac address changes. As noted above, delete the leases6 file first.

    c) Dhclient6 doesn't seem to always start after enabling ipv6. Run the command above. After doing so, it seems to start properly on its own after a reboot.

  • In reply to Jay Jay:

    Partial success, including transparent web filtering, no use of SNAT.


  • In reply to Jay Jay:

    In reference to the April 16th post -,

    /60 Prefix deligation success -

    One must manually execute the dhclient6 command with the --prefix-len-hint 60 option. Delete the leases6 file and change wan mac first is needed (so new duid can be generated). Do this while wan interface is down or off.

    For transparent webfiltering to work, internal ipv6 network should be added to web filtering/global/allowed networks.

  • In reply to Jay Jay:

    Latest scripts uploaded to .

    Everything is working including ipv6.

    Anyone try this out?