ATT Uverse RG Bypass (0.2 BTC)
-
What NIC are you using?
-
@fresnoboy When I tried it on ESXi 7 wireguard wasn't out and I wasn't terminating VPN tunnels on my pfsense, but I do remember there to be the same CPU usage delta between hypervisor and bare metal.
-
@gpz1100 I've never tried proxmox other than one time playing around with unraid which I believe runs proxmox under the covers.
Were you defining your vNIC's with your VLANs as "vlan aware"?In ESXi I would just assign the vlan 0 as well as set the MAC address to my att provided gateway MAC in the interface options for the virtual machine for the WAN interface and that was it. Didn't have to do anything on the pfsense guest itself outside of running a simple wpa_supplicant script to get a DHCP address from Att.
-
@stephenw10 https://reviews.freebsd.org/D31515 had to be updated on FreeBSD for the VLAN 0 to actually be able to get DHCP, I wonder if the same thing needs to happen to wpa supplicant.
-
@stephenw10 test box has a 4port 1Gbe intel nic, em. Also has an ionboard Realtek nic that I tried.
-
OK, well it won't work using netgraph and that Intel NIC in 23.01/2.7.
It should work using netgraph with the Realtek NIC AFAIK though I've not tried it.
To use it without netgraph you would need to disable vlan hardware filtering on the em NIC. Though I have no way to test if it's possible.
-
@stephenw10 the intel driver bug was supposed to be fixed in 2.7/23.01. And I disabled -vlanhwfilter. I'm not testing netgraph,my goal was to eliminate netgraph and just be able to auth with wpa_supplicant in its own.
-
The e1000 driver bug is not fixed. I tested it last week when confirming the igc is not affected.
If you disable vlan hardware filtering and run a pcap you will see the incoming tagged packets.
I would try that and see what's responding or not from pfSense.Presumably you have some other script running to activate the wpa_suplicant with the appropriate certs etc?
-
@bigjohns97 said in ATT Uverse RG Bypass (0.2 BTC):
@gpz1100 I've never tried proxmox other than one time playing around with unraid which I believe runs proxmox under the covers.
Were you defining your vNIC's with your VLANs as "vlan aware"?In ESXi I would just assign the vlan 0 as well as set the MAC address to my att provided gateway MAC in the interface options for the virtual machine for the WAN interface and that was it. Didn't have to do anything on the pfsense guest itself outside of running a simple wpa_supplicant script to get a DHCP address from Att.
I tried defining the vlan with both vlan aware enabled and disabled. Made no difference as far as wpa_supplicant being able to receive the eapol traffic.
I tried with both the intel nic and a usb rtl8153 based nic, both failed.
My "production" firewall is sophos utm under proxmox. The intel nic is in passthrough mode for the wan. There I run wpa_supplicant directly, without anything additional to handle vlan0. It's been working fine for a number of years. UTM is going EOL so exploring other options.
-
Well since there is no gui options for that in pfSense you would need, at a minimum, something like this: https://redmine.pfsense.org/issues/5474
-
@gpz1100 you're not passing the NIC through on proxmox are you?
-
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.
