ATT Uverse RG Bypass (0.2 BTC)
-
When passing the nic, the netgraph method works for dealing with eapol.
I was testing NOT passing the nic but creating a bridge specifying .0 as a bridge member as indicated in the proxmox link (https://forum.proxmox.com/threads/how-to-pass-vlan-0-priority-tags-to-pfsense-for-dhcp.112374/ post 2). Which did not work. I got no auth.
Also tested specifying different interface drivers (virtio, vmxnet3, and e1000). The eapol data was just not coming through.
-
Someone over on the discord channel mentioned they were able to get opnsense 23 to work without using netgraph at all.
Wpa_supplicant is still required, but the only change is flagging the wan port with vlanpcp 7. No promisc, no -vanhwfilter, etc.
ifconfig igb0 vlanpcp 7I could not replicate this. In testing, eapol traffic was coming as 888e from the ONT. A logon command from wpa_cli would leave as 8100 from the wan interface.
It was then suggested to use a smart switch with port based vlans. That is configure 2 unused ports on a separate untagged vlan. Similar to the old school dumb switch method.
I first tested with a dumb switch (dgs-1005) with no success. Same issue as above
Then used a managed switch. Looks like this on a dlink dgs-1100-08;
A comparable configuration on a netgear gs308t did NOT work. There was no traffic passed as the switch completely ignored the inbound vlan0 tagging from the ONT.
On the dlink however, this was successful. Tcpdump showed no vlan or priority tags for the wan interface. Wpa_supplicant worked flawlessly without netgraph as did dhcp. It would appear the dlink switch successfully striped the vlan0 tags.
All eapol traffic contained 888e for ethertype in both directions. Success present in both opnsense 23.1.5.x and pfsense+ 23.01. I did not test older versions.
I expect other switches to work as well, but it matters in what the default behavior is with vlan0 packets. Does it ignore the traffic entirely (netgear gs308t), or does it treat it as native vlan and allow to pass (dlink dgs-1100-08)? -
@gpz1100 said in ATT Uverse RG Bypass (0.2 BTC):
Someone over on the discord channel mentioned they were able to get opnsense 23 to work without using netgraph at all.
Wpa_supplicant is still required, but the only change is flagging the wan port with vlanpcp 7. No promisc, no -vanhwfilter, etc.
ifconfig igb0 vlanpcp 7I could not replicate this. In testing, eapol traffic was coming as 888e from the ONT. A logon command from wpa_cli would leave as 8100 from the wan interface.
It was then suggested to use a smart switch with port based vlans. That is configure 2 unused ports on a separate untagged vlan. Similar to the old school dumb switch method.
I first tested with a dumb switch (dgs-1005) with no success. Same issue as above
Then used a managed switch. Looks like this on a dlink dgs-1100-08;
A comparable configuration on a netgear gs308t did NOT work. There was no traffic passed as the switch completely ignored the inbound vlan0 tagging from the ONT.
On the dlink however, this was successful. Tcpdump showed no vlan or priority tags for the wan interface. Wpa_supplicant worked flawlessly without netgraph as did dhcp. It would appear the dlink switch successfully striped the vlan0 tags.
All eapol traffic contained 888e for ethertype in both directions. Success present in both opnsense 23.1.5.x and pfsense+ 23.01. I did not test older versions.
I expect other switches to work as well, but it matters in what the default behavior is with vlan0 packets. Does it ignore the traffic entirely (netgear gs308t), or does it treat it as native vlan and allow to pass (dlink dgs-1100-08)?I tried pcp 7 as well and couldn't get it to auth either.
-
@bigjohns97 said in ATT Uverse RG Bypass (0.2 BTC):
I tried pcp 7 as well and couldn't get it to auth either.
To be clear did you try that with the switch reported working (dlink dgs-1100-08)?
-
@t41k2m3 Nope, this is just me using ifconfig to tag the WAN interface with pcp7 traffic trying to get an 802.1x auth without using netgraph.
https://github.com/MonkWho/pfatt/issues/79
You can see in the above discussion that someone was able to make this work but they did not have an intel NIC.
They were using a Marvell NIC and an ARM proc.
-
@bigjohns97 @GPz1100 or others - has anyone experienced issues with pfatt - ngeth0 and wpa supplicant post upgrade to 23.05? At bootup it seems to be trying to assign ngeth0 to WAN before ngeth0 is created via the earlyshellcmd script. Bootup therefore gets stuck waiting for manual interface assignment. That was not the case in 23.01 and earlier. Short of adding a switch or (new) modem/RG bridge options in 23.05, any thoughts on how the old setup could be kept running?
-
@t41k2m3 said in ATT Uverse RG Bypass (0.2 BTC):
@bigjohns97 @GPz1100 or others - has anyone experienced issues with pfatt - ngeth0 and wpa supplicant post upgrade to 23.05? At bootup it seems to be trying to assign ngeth0 to WAN before ngeth0 is created via the earlyshellcmd script. Bootup therefore gets stuck waiting for manual interface assignment. That was not the case in 23.01 and earlier. Short of adding a switch or (new) modem/RG bridge options in 23.05, any thoughts on how the old setup could be kept running?
Sorry I moved over to the stripper switch method to get rid of the complex ngeth0 scripts so I can't comment on this.
Would still love to run native using PCP 7 but waiting on the wpa supplicant to be patched to be able to support VLAN 0.
-
In 23.05 you can remove both and use the native ether bridge-to rules instead:
https://docs.netgate.com/pfsense/en/latest/recipes/authbridge.htmlWith the router authentication at least. If you're using the cert directly that doesn't apply.
Steve
-
@stephenw10 I am using certs, for those using certificates we have to wait for the wpa supplicant to be patched like the dhclient was recently.
-
@t41k2m3 yes .. same issue.
Every upgrade is a new surprise. I was so excited for this one because we were SO close to using the supplicant without netgraph. It appears interfaces are now assigned before the earlyshellcmd scripts are ran, so it's broken for me. Having to use another workaround at the moment.
edit: switched to the new GUI supported pass-through method and it's working well so far!
-
@bigjohns97 said in ATT Uverse RG Bypass (0.2 BTC):
Sorry I moved over to the stripper switch method to get rid of the complex ngeth0 scripts so I can't comment on this.
Would still love to run native using PCP 7 but waiting on the wpa supplicant to be patched to be able to support VLAN 0.
Could not get stripper switch to work on pfs 23.05 (one of the switches from https://github.com/MonkWho/pfatt/issues/82). EAP auth succeeds but will not get DHCP address. Might that depend on FTTN/FTTH and ISP upstream setup (hence why certain switches seem to work for some but not all)?
-
@t41k2m3 Does pfatt with netgraph work for you? I would expect a stripper switch to work as well then.
I haven't tested 23.05 yet, but 23.01 worked just fine with the switches mentioned in the https://github.com/MonkWho/pfatt/issues/82 thread.
If pfatt/netgraph works, verify you're using the correct mac for the wan.
-
@GPz1100 said in ATT Uverse RG Bypass (0.2 BTC):
@t41k2m3 Does pfatt with netgraph work for you? I would expect a stripper switch to work as well then.
I haven't tested 23.05 yet, but 23.01 worked just fine with the switches mentioned in the https://github.com/MonkWho/pfatt/issues/82 thread.
If pfatt/netgraph works, verify you're using the correct mac for the wan.
I'm on 23.05 and using stripper switch (5 port) successfully. Didn't have to change anything going from 23.01 to 23.05.
-
Do any of you have this to working with the newer AT&T gateways with a built-in ONT?
-
S stephenw10 referenced this topic on
-
Hi folks, I'm crossing over from a post I made in the general forum: Quirky bypass on 22.05 with AT&T fiber
-
I've got the 'official' bypass working with 23.05 and a BGW210, but my pfsense bootup is now quite a bit longer. It's taking about 75 seconds at "configuring wan interface" when it used to take just a few seconds before I performed the bypass.
-
The RG's LED indicator for 'broadband' flashes green while PFsense is booting, but then switches to flashing red after a few minutes, despite the baypass working and having full connectivity on my connection. This is a lesser issue, but I'm just confused by it.
I appreciate any insight as to why the wan config is taking so much longer, or why the RG wouldn't seem to detect the broadband connection. Thanks in advance!
-
-
@darkphox said in ATT Uverse RG Bypass (0.2 BTC):
Hi folks, I'm crossing over from a post I made in the general forum: Quirky bypass on 22.05 with AT&T fiber
-
I've got the 'official' bypass working with 23.05 and a BGW210, but my pfsense bootup is now quite a bit longer. It's taking about 75 seconds at "configuring wan interface" when it used to take just a few seconds before I performed the bypass.
-
The RG's LED indicator for 'broadband' flashes green while PFsense is booting, but then switches to flashing red after a few minutes, despite the baypass working and having full connectivity on my connection. This is a lesser issue, but I'm just confused by it.
I appreciate any insight as to why the wan config is taking so much longer, or why the RG wouldn't seem to detect the broadband connection. Thanks in advance!
I have the BGW320-505 gateway which AT&T started installing out about two years ago when I moved last. I’m curious if your method will work on mine. The ONT module is built-in, so they ran the fiber line directly to the back of the modem with an SFP module.
-
-
It's possible the authentication always takes a while but you wouldn't normally see that because the AT&T router does it before pfSense even connects in the double NAT setup. In the bypass mode the auth can only start once pfSense bridges to the router when it sets up the WAN. It seems unlikely it should take anything like 75s though.....
I don't have an AT&T connection to test. -
Since you can't really eliminate the newer AT&T gateways completely (thanks to AT&T's certificate-based authentication and integrated ONT module), then I don't even see the point of doing this. I just put mine in IP passthrough mode with my public IP going over to pfSense along with my /29 block and I haven't had any issues with latency or dropped packets. AT&T reboot time is still only about 20-30 seconds.
-
Mmm, interesting. Yeah I wouldn't expect the auth to take more than a fraction of a second really. Let's see if anyone else is seeing a delay there.
-
@stephenw10 Just to clear up any confusion, when I said 20-30 total reboot time, that is basically from powered off to a solid green light on the gateway. IP Passthrough mode (essentially bridging) does not add any additional time to the reboot cycle because it's still doing the auth.
