pfSense Support Subscription

Author Topic: ATT Uverse RG Bypass (0.2 BTC)  (Read 2900 times)

0 Members and 1 Guest are viewing this topic.

Offline dc81

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
ATT Uverse RG Bypass (0.2 BTC)
« on: April 29, 2016, 02:30:43 pm »
I'm trying to avoid using the gateway provided by ATT. It seems like it's been solved for EdgeRouter and *nix based routers (https://www.dslreports.com/forum/r29903721-AT-T-Residential-Gateway-Bypass-True-bridge-mode~start=264). Hopefully someone will be able to get this working on pfsense too.

0.2 Bitcoins (~$90) to anyone that can get it done.

Offline zevlag

  • Jr. Member
  • **
  • Posts: 26
  • Karma: +2/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #1 on: May 09, 2016, 06:28:02 pm »
i'm willing to talk about this and help if you want.

But first we need to define the problem, and the desired solution.

Having read the linked thread, there are two options:
  • Bridge the ONT and RG interfaces filtering to allow only 802.1X packets
  • Run an application to Proxy 802.1X packets that are received between the interfaces
Which are you hoping for?

I think the first can be done with a kernel patch.  The latter would be more difficult for me.

Also, if I understand the thread correctly, this solves only the authentication issue, it isn't any configuration for TV or phone services.

Offline dc81

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #2 on: May 10, 2016, 01:11:22 pm »
Goal is for my traffic to bypass the RG. I have a pfsense box with multiple gigabit ports. I want to connect the ONT and RG to the pfsense box and have LAN traffic on the remaining ports.

Currently:

ONT > RG > pfSsense > LAN

Want:
Code: [Select]
ONT > pfSense
      |    |
      RG   LAN

So I'm not really concerned with any specific option, but I would want to be able to keep my gigabit speed. My box has an Atom C2558 if that matters.

Offline zevlag

  • Jr. Member
  • **
  • Posts: 26
  • Karma: +2/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #3 on: May 10, 2016, 01:23:59 pm »
If I provide a kernel patch, are you familiar with compiling kernels in FreeBSD?

Offline dc81

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #4 on: May 10, 2016, 02:04:43 pm »
I have not, but it seems fairly straightforward. I have a backup pfsense in a vm so the downtime is not an issue.

Offline dc81

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #5 on: June 02, 2016, 10:36:28 am »
any progress?

Offline dc81

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #6 on: April 26, 2017, 02:08:49 pm »
bump... anyone?

Offline ermax

  • Newbie
  • *
  • Posts: 13
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #7 on: May 11, 2017, 07:43:00 am »
I would love to see this too.

Offline pyrodex

  • Jr. Member
  • **
  • Posts: 30
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #8 on: September 21, 2017, 01:07:26 pm »
Looks like it maybe more viable now with a python script:

https://github.com/jaysoffian/eap_proxy

See https://github.com/jaysoffian/eap_proxy/issues/2 also since it seems PFRING is required but BSD doesn't have PFRING.

I've heard someone got this working on a debian box running shorewall so maybe just adapting it for BSD could be the solution.

Offline variance

  • Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #9 on: October 24, 2017, 05:00:15 pm »
Looks like it maybe more viable now with a python script:

https://github.com/jaysoffian/eap_proxy

See https://github.com/jaysoffian/eap_proxy/issues/2 also since it seems PFRING is required but BSD doesn't have PFRING.

I've heard someone got this working on a debian box running shorewall so maybe just adapting it for BSD could be the solution.

I've seen a report of this solution (https://github.com/kuwerty/eapolproxy)
eap proxy sucessfully compiled and running on pfsense after installing some dependencies  (libstdc++).
and it passing packets.


Quote
I checked out the eapolproxy, and successfully compiled it on my freebsd dev box.  After getting some dependencies (libstdc++) onto pfsense, it does start and appears to be passing the EAP traffic from the RG on OPT1 up to the WAN interface where the ONT is, but nothing ever comes back - it just keeps spamming the EAPOL start and logoffs.  I will have to keep playing with it, but I feel like the solution is close.  It would be good to have some others try this...


Source: (http://www.dslreports.com/forum/r31632582-)


as for pfring dependency.. i don't know if thats kernel or something that needs to be compiled specifically for freebsd...
my gigapower install doesn't happen for another day or 2. I'm going to go ahead and try compiling the this eapolproxy myself to see if I can get it working.
« Last Edit: October 24, 2017, 05:03:47 pm by variance »

Offline rajl

  • Jr. Member
  • **
  • Posts: 29
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #10 on: November 21, 2017, 01:11:42 pm »
If this feature bounty still open?  I may have an elegant FreeBSD solution to the problem.

Offline random003

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #11 on: December 08, 2017, 06:48:03 am »
I'll give you $100 in bitcoin for a set-and-forget solution that works on pfsense.
« Last Edit: December 08, 2017, 07:10:58 am by random003 »

Offline PnoT

  • Newbie
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #12 on: December 14, 2017, 08:43:39 am »
Any progress on this?

Offline random003

  • Newbie
  • *
  • Posts: 6
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #13 on: December 20, 2017, 08:12:41 pm »
$200 for a set-and-forget solution.

I may consider other payments methods besides bitcoin if preferred.

Offline rajl

  • Jr. Member
  • **
  • Posts: 29
  • Karma: +0/-0
    • View Profile
Re: ATT Uverse RG Bypass (0.2 BTC)
« Reply #14 on: January 10, 2018, 02:04:28 pm »
There's been a surprising amount of progress, although I've encountered some issues with PFSense specifically (vanilla FreeBSD and OPNSense work more smoothly).

Here's a summary so far of what I've done, and the issues I am encountering.

For background, here are links for Linux specific solutions:

http://blog.0xpebbles.org/Bypassing-At-t-U-verse-hardware-NAT-table-limits
https://strscrm.io/bypassing-gigapowers-provided-modem.html

To summarize, there are two Linux approaches:
(1a) Create a Bridge and enable the Bridge to Forward EAPOL traffic - Use ebtables (Linux layer 2 firewall) to filter what is forwarded across the bridge.
(1b) Run a Python script called EAP-Proxy that proxies EAPOL traffic in order to avoid creating the bridge
(2) Create a Virtual Interface for your WAN assigned VLAN 0 and assign your services to it.

However, FreeBSD is not Linux and there are some issues due to FreeBSD's undying commitment to standard's compliance:
(1) The FreeBSD bridge code does not allow for EAPOL traffic to be forwarded across the bridge because this violates the IEEE 802.1D standard.
(2) The EAP-Proxy Script that is circulating is pretty specific to Linux and requires a lot of massaging to work with FreeBSD.  Also, it requires installing python on your firewall, which you may not want to do for security reasons.
(3) FreeBSD's vlan code does not allow you to create a virtual interface assigned to VLAN 0 because IEEE 802.1Q specifies that vlan 0 is reserved.

So there are two technical issues that need to be resolved:
(1) Make FreeBSD forward EAPOL traffic between the RG and the ONT.
(2) Allow the FreeBSD WAN interface to communicate on vlan 0 so that it can communicate with the ONT.

I have solved the first problem and can demonstrate two working solutions on FreeBSD and OPNSense.  However, the preferred solution does not work on PFSense yet.  To briefly summarize my work:
(1) The universally working (but not preferred) solution is to patch the kernel's bridge code to forward EAPOL traffic.  I've created a kernel patch for the bridge code that allows you to enable or disable forwarding of EAPOL traffic on a bridge using a sysctl variable.  However, it's definitely not a set and forget solution as you have to manually patch your kernel and then potentially repatch the kernel with every update.  Long-term, it can be a set and forget solution once I submit the patch to -CURRENT and it migrates to -STABLE and it then makes it to -RELEASE.  But that's a long migration path.
(2) I've created a set and forget solution for forwarding EAPOL traffic using FreeBSD's builtin Netgraph framework.  Basically, I use Netgraph to create a layer 2 firewall that forwards all EAPOL frames between interfaces and forwards all other Ethernet frames on up the network stack per normal.  I've tested it successfully on vanilla FreeBSD and OPNSense.  However, it's not currently working on PFSense for two reasons. 
  • The first reason is a show stopper - there's a bug in the PFSense netgraph module ng_eth.  When ng_eth is loaded, it is supposed to automatically create a Netgraph node for each ethernet interface on your system.  Unfortunately, PFSense's ng_eth module only creates a netgraph node for some, but not all of the ethernet interfaces on my test system.  It also deletes nodes it has created when I try to switch the LAN and WAN interfaces to the existing ng_eth nodes.  Curiously, the ng_eth module works on FreeBSD 11.1 and OPNSense as expected.
  • The second reason is rather trivial to solve, but still annoying.  PFSense doesn't load all of the necessary netgraph modules by default and doesn't allow you to load kernel modules at run time.  While this is a good security behavior, it means you have to manually edit your boot configuration to load the necessary netgraph modules

I am still attempting to solve the second problem (communicating on VLAN 0).  Looking at TCPDump, I can see the DHCP request and response between my WAN and the ONT, but I am not getting an IP address assigned to my WAN interface.  I suspect this is because the traffic is tagged as VLAN 0 in a non-standard compliant manner, which is causing FreeBSD to disregard the DHCP response as invalid.  I may be able to solve this problem as well using Netgraph, but I need to investigate further when I have some more time and I can test my solution (which is when my family is not home streaming Netflix).

If anyone else is a networking ninja, I would be glad to partner with them to finish this project more quickly.