MonkWho / pfatt

Enable true bridge mode for AT&T U-Verse and pfSense (this is a fork of an original repository https://github.com/aus/pfatt. Since it is not available anymore, I'll do my best to maintain a copy for people that still need a bypass)
449 stars 175 forks source link

PfSense 23.01/2.7 (FreeBSD 14.0) #79

Closed bigjohns97 closed 1 year ago

bigjohns97 commented 1 year ago

With the new release coming up and quite a few changes I figured it was time to start a discussion on bypass scripts for the new version of PfSense about to release.

A couple of notes that hopefully saves some people some time.

https://redmine.pfsense.org/issues/12821?next_issue_id=12820

Looks like we won't have to be using netgraph moving forward which would be nice

With the introduction of native PCP VLAN0 tagging in pfSense Plus 23.01 and the new bridge filtering to pass along EAP traffic from another interface natively integrated into pfSense Plus

Which is good because the src isn't available for 14.0 yet so we wouldn't be able to compile a new Intel driver against it.

But this does mean we are going to need to build a new script with new commands to tag VLAN and authenticate EAP traffic.

MatthewGCampbell commented 1 year ago

After playing around with settings I got it to work. A few notes/steps below may help others. Referring back to what @ChronicledMonocle mentioned a couple of posts above.

* Upgrade to 23.05-RC to get the option for Ethernet Filtering

* Attached a USB NIC for my connection to the modem (if you have a free port on your pfSense you can use that)

* Added the new USB interface via Interfaces -> Assignments

* The only setting I changed on the new USB NIC interface for the Modem is to enable "Promiscuous Mode"; left the IPv4 and IPv6 Configuration types as None

* I couldn't find the "PCP" setting on the WAN interface (I guess it's called Priority Tag?), I left it blank; just ensured that the MAC Address field is set to the MAC of the AT&T Modem

* Added the two rules mentioned by @ChronicledMonocle  in the screenshot under Firewall -> Rules -> Ethernet

* Need to use the Advanced Options and set the Bridge To field; and the first rule needs to have the Protocol set to IEEE 802.1X

This worked for me without any restarts (except when upgrading pfSense to 23.05-RC). I haven't tried to see if this will survive a reboot of the modem and the pfSense router yet.

We have a documentation recipe going up on docs.netgate.com that will have a configuration example of how to do this step by step. I wrote this with input from the pfSense Plus TAC and Development teams for editing and feedback. Attached is a PDF of the draft before it goes live there. Bear in mind you need to be on pfSense Plus 23.05 RC for these instructions to work: Configuring WAN Connectivity for 802.1X Authentication Bridging and VLAN0 PCP Tagging.pdf

I really think this pdf document is great and the write up on docs.netgate.com is even better but I still can’t get this setup working with my SG-5100 I think it may have something to do with the nic’s and not liking the new Ethernet firewall rules, but I get a DHCP address but I’m unable to route traffic. Not sure if anyone else is having this issue or not.

bigjohns97 commented 1 year ago

Going to close out this issue as there is a newer version of 23.05 which when included with the new wpa_supplicant binary not only eliminates the need for Netgraph but also the need for stripper switches and even PCP (vlan0) values!

TTK-199837 commented 1 year ago

After playing around with settings I got it to work. A few notes/steps below may help others. Referring back to what @ChronicledMonocle mentioned a couple of posts above.

* Upgrade to 23.05-RC to get the option for Ethernet Filtering

* Attached a USB NIC for my connection to the modem (if you have a free port on your pfSense you can use that)

* Added the new USB interface via Interfaces -> Assignments

* The only setting I changed on the new USB NIC interface for the Modem is to enable "Promiscuous Mode"; left the IPv4 and IPv6 Configuration types as None

* I couldn't find the "PCP" setting on the WAN interface (I guess it's called Priority Tag?), I left it blank; just ensured that the MAC Address field is set to the MAC of the AT&T Modem

* Added the two rules mentioned by @ChronicledMonocle  in the screenshot under Firewall -> Rules -> Ethernet

* Need to use the Advanced Options and set the Bridge To field; and the first rule needs to have the Protocol set to IEEE 802.1X

This worked for me without any restarts (except when upgrading pfSense to 23.05-RC). I haven't tried to see if this will survive a reboot of the modem and the pfSense router yet.

We have a documentation recipe going up on docs.netgate.com that will have a configuration example of how to do this step by step. I wrote this with input from the pfSense Plus TAC and Development teams for editing and feedback. Attached is a PDF of the draft before it goes live there. Bear in mind you need to be on pfSense Plus 23.05 RC for these instructions to work: Configuring WAN Connectivity for 802.1X Authentication Bridging and VLAN0 PCP Tagging.pdf

I really think this pdf document is great and the write up on docs.netgate.com is even better but I still can’t get this setup working with my SG-5100 I think it may have something to do with the nic’s and not liking the new Ethernet firewall rules, but I get a DHCP address but I’m unable to route traffic. Not sure if anyone else is having this issue or not.

Hi!

Were you able to get things working for your SG-5100?

TTK-199837 commented 1 year ago

And a question for the experts (@bigjohns97) if I update pfsense via the GUI and keep all the current pfatt bypass files and earlyshellcmd scrips intact, will something break? Or will everything work like now, and give me the opportunity to switch over to the new method?

My current plan is to:

Is this the correct way of doing things?

Thank you!

bigjohns97 commented 1 year ago

And a question for the experts (@bigjohns97) if I update pfsense via the GUI and keep all the current pfatt bypass files and earlyshellcmd scrips intact, will something break? Or will everything work like now, and give me the opportunity to switch over to the new method?

Unfortunately I can't answer this as I wasn't running the ngeth based script once 23.05 dropped, I was using a stripper switch by then.

aholmes55 commented 1 year ago

@TTK-199837 I just did this. I ended up reflashing to 23.05 as I could never get the upgrade to work correctly. I was using pfatt.sh tethered and then with supplicant on 23.01. On 23.05, I am using the tethered authbridge builtin to pfsense 23.05. Their manual outlines the steps perfectly - make sure you don't miss any steps. One thing I've noticed is that there is a long ~60s delay waiting for the WAN interface during the boot sequence. Not sure what thats all about but it seems like I read other people have it too.

gpz1100 commented 1 year ago

One thing I've noticed is that there is a long ~60s delay waiting for the WAN interface during the boot sequence. Not sure what thats all about but it seems like I read other people have it too.

Ahh... That dreaded 60s pause at "configuring wan interface..."

That happens specifically because eapol auth hasn't taken place yet and dhcp can't pull an IP. We ran into the same issue with wpa_supplicant method. The work around was to start the supplicant daemon as earlyshellcmd. Then once past the configuring wan.... something happens to the wan interface leaving wpa_supplicant in an unresponsive (to eapol requests) state. So the solution was to have wpa_supplicant launched twice, once as earlyshellcmd, once as shellcmd. The latter killing the existing process first.

Since you can't quite do that with the bridged method, your best best may be to change the wan dhcp timeout (under advanced wan settings) to something like 10-15s instead of the default 60s.

juvinious commented 1 year ago

Wait so are you guys still tethered to the RG like the docs mention? One nic to ONT the other to the RG? https://docs.netgate.com/pfsense/en/latest/recipes/authbridge.html

Is it possible to use extracted certs with wpa_supplicant? I see no mention of it in the docs. Was hoping to upgrade from 2.6 and continue to use my setup without having to pull the router out of the closet.