ATT Uverse RG Bypass (0.2 BTC)
-
This thread originally was for getting the eap_proxy working on pfsense. Has that just been given up on? It would really be nice if we could get a hands-off method working.
-
How do you figure the dumb switch method works with other firewall such as sophos utm, or even a basic rtac68u router, but not pfsense for some?
-
-
Should work all the same if you have the ability to spoof your AT&T RG MAC on the device you are trying.
It does work, when ip is assigned statically, but won't pull via dhcp.
-
I've been bypassing my RG (now powered off and unplugged) for at least 6 months using the very first method described in the dslreports thread with a GS108 switch. I'm using a Netgate SG-4860. DHCP works fine with the spoofed MAC address, but IPv6 requires either pfsense 2.4.3, or using a patch to enable DUID-EN (https://github.com/pfsense/pfsense/pull/3889).
See this post by the author of the patch for more details on getting IPv6 to work bypassed: https://github.com/pfsense/pfsense/pull/3889
Hope this helps…it would definitely be great if we could get something like the eap_proxy approach to work on pf.
-
The GS108 is pretty much the same switch I have tried it with, (GS105. just 3 less ports) only static with pfsense worked for me. What exactly are you changing in the WAN settings of pfsense thats allowing yours to pull a DHCP IP?
-
Has anyone worked on a solution (other than the dumb switch method) for OpenBSD, by chance? I was thinking PF could just redirect EAPOL traffic to the RG but it looks like it can only filter on layer 2 on bridge interfaces (and even then, only by MAC address).
-
Has any more work been done on either the eap_proxy or the ng_ package?
-
@bulldog5 said in ATT Uverse RG Bypass (0.2 BTC):
The GS108 is pretty much the same switch I have tried it with, (GS105. just 3 less ports) only static with pfsense worked for me. What exactly are you changing in the WAN settings of pfsense thats allowing yours to pull a DHCP IP?
Not sure if you've already tried this, but I was having the same problem with OPNsense where static IP worked, but it wouldn't pull the IP w/ DHCP. I had been flipping the VLANs (from Pace GW & ONT to my FW & ONT) when I was using an Asus router and that worked with DHCP, but not with OPNsense.
I recently tried swapping the cables on the switch instead of changing VLANs and for some reason that works with DHCP. It hasn't been long enough for me to see if it will work past the 14 day mark, but it's at least working initially.
-
@danieljay23 said in ATT Uverse RG Bypass (0.2 BTC):
Has any more work been done on either the eap_proxy or the ng_ package?
I'm also hoping someone figures out a way to make this work in FreeBSD with an EAP proxy or something like that. Nothing I've tried seems to work except the switch method.
-
Hi all!
Apologies for the delays, but I finally got around to cleaning up my notes on pfSense + netgraph. Hopefully this helps you guys. Thanks again to @rajl for trailblazing most of this!
Working:
True Bridge mode
IPv6
Survives reboots / power outages
Survives re-authentications
DHCP lease expirations
No performance impacts
Physical hardware
Virtual machine
Multiple gatewayshttps://github.com/aus/pfatt
Now someone just needs to package this into a pretty pfsense package.
-
@aus I've been patiently waiting for this...Congrats and Thank You!! Want to tackle this very soon on 2.4.4 (11.2 bsd). Hopefully, pfsense pros integrate a bypass function easily operated with a checkbox and MAC cloning. Thanks again for your work...
-
Thanks. I got this implemented last night. So far on my Supermicro C2558 box I have only been able to hit mid 600Mbps using this method of of the gig I get. Have not looked yet at adding my static IP. When I do a speed test I do see the CPU go from 1-2% up to 26% and never go above that. Am I correct and thinking that this is due to the process running on only a single core?
-
@jjb said in ATT Uverse RG Bypass (0.2 BTC):
@aus I've been patiently waiting for this...Congrats and Thank You!! Want to tackle this very soon on 2.4.4 (11.2 bsd). Hopefully, pfsense pros integrate a bypass function easily operated with a checkbox and MAC cloning. Thanks again for your work...
Thanks! And yes. I want to give this a shot too. I don't expect any problems. Worst case, I think I just need to recompile the ng_etf.ko kernel module from FreeBSD 11.2. Might give this a shot this weekend. I'll add any changes to Github if needed. Or if you beat me to it, submit a PR!
EDIT: No issues updating to 2.4.4!
@danieljay23 said in ATT Uverse RG Bypass (0.2 BTC):
Thanks. I got this implemented last night. So far on my Supermicro C2558 box I have only been able to hit mid 600Mbps using this method of of the gig I get. Have not looked yet at adding my static IP. When I do a speed test I do see the CPU go from 1-2% up to 26% and never go above that. Am I correct and thinking that this is due to the process running on only a single core?
How are you running your speed test? If you run speedtest-cli (which is just python) directly on your pfSense box, you get CPU bound pretty quickly.
I've been testing with the speedtest.net desktop application. For pfSense, I'm running a Dell R210 ii / E3-1220 on a symmetric gigabit link. I get ~940 Mbps down on a few speedtest.net servers. I have a hard time breaking 800 Mbps on my upload though, but I don't think thats due to my R210 ii. I get the exact same results when testing with just my residential gateway+PC (no bypass or passthrough). iperf3 gives similar results.
I should also note that there's no running process with this method. I'm no expert on FreeBSD internals, but I believe this is entirely in kernel space, so you'll see an uptick in CPU interrupts, but not significantly enough to impact performance. At least on decent hardware. Which in my opinion, makes netgraph the better solution over some of these EAPOL userland proxies that I've seen.
-
-
@aus said in ATT Uverse RG Bypass (0.2 BTC):
How are you running your speed test? If you run speedtest-cli (which is just python) directly on your pfSense box, you get CPU bound pretty quickly.
Sorry for not responding right away. I was running the speedtest.net website through my Chrome browser on my desktop. I will have to download the desktop app and see if that gets any better results.
-
@aus thank you for developing this and making it available to the community.
Seeing some speed degradation when testing off pfsense 2.4.4 vs. directly off RG BWG210 (using same equipment/tools, Ookla speedtest app). Differences in this test case vs. your Github repo appear to be ng_etf.ko module compiled on FreeBSD 11.2 release (vs. yours compiled on 11.1) and lack of IPv6 setup (skipped).
In your opinion, could any of these differences cause the speed drop? Pfsense box (hardware) should not be bottleneck. However, there may be some pfsense software setting possibly slowing things down as speed loss seems to occur both with and without Netgraph (pfsense connected either through RG passthrough or via Netgraph bypass), with Netgraph being the slowest (roughly - testing off RG direct ~900Mbps; pfsense via RG passthrough ~800Mbps; pfsense via Netgraph ~700 Mbps). Thanks for any feedback.
-
@aus Everything working well. However, when I reboot/lose power, I have to set my interfaces again and ngeth0 is NOT available at the console. I just set igb3 or whatever as wan, set my lan. No internet. I log into webgui and I can assign ngeth0 as WAN there and everything is good again. Not sure what's happening and read someone else was having similar issue. I did find if I reboot from console (Option "5") with 'Reroot' (R) option, everything is great. Also, if someone has compiled the 11.2 FreeBSD netgraph module, please upload and share link (would love to see if that's an issue at all). Thanks all!
-
@t41k2m3 I haven't been able to get to the bottom of some of the speed impact issues. It's hard to compare apples to apples in these benchmarks. What kind of hardware are you using for pfSense?
The kernel module shouldn't make a difference, since there were no changes changes in ng_etf.c from 11.1 to 11.2. You're welcome to try though. Instructions on how to build are on the README. It's pretty straight forward to do in a FreeBSD VM.
I made a PR for disabling Promiscuous Mode, which doesn't need to be enabled. In theory, if your NIC is trying to route/drop a lot of traffic that is not intended for your NIC (example: broadcast), then disabling promisc mode could help. Unfortunately, I think that's probably unlikely in a standard setup. You might give it a shot:
https://github.com/aus/pfatt/pull/7
@JJB Can you confirm that
pfatt.shis getting executed at <earlyshellcmd> ? if pfSense loads beforepfatt.shhas created the ngeth0 netgraph interface, it will not know which interface to assign to WAN/LAN. -
@t41k2m3 I haven't been able to get to the bottom of some of the speed impact issues. It's hard to compare apples to apples in these benchmarks. What kind of hardware are you using for pfSense?
Thanks for your reply @aus . Hardware tested on is Netgate quad Atom C2558, 8 GB RAM, bare metal pfS install (not virtualized). Would seem hardware should not cause performance issues (unless some obscure NIC hardware - Intel I350 - or driver issue?).
The kernel module shouldn't make a difference, since there were no changes changes in ng_etf.c from 11.1 to 11.2. You're welcome to try though. Instructions on how to build are on the README. It's pretty straight forward to do in a FreeBSD VM.
I made a PR for disabling Promiscuous Mode, which doesn't need to be enabled. In theory, if your NIC is trying to route/drop a lot of traffic that is not intended for your NIC (example: broadcast), then disabling promisc mode could help. Unfortunately, I think that's probably unlikely in a standard setup. You might give it a shot:
https://github.com/aus/pfatt/pull/7Tried new PR while at the same time swapping the kernel module to the 11.1 version (like yours, compiled in a VM). Not sure if it was the script changes (i.e. spoofing MAC to RG MAC, disabling promiscuous mode) or the kernel module change, but it did not connect at all (no IP via DHCP). Should probably try the module and script changes separately to isolate any potential issues. I assume the PR worked in your testing (able to connect, speed comparable to before)?