search

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)
438 stars 170 forks source link

Struggling after 2.5 upgrade #51

Open Frick opened 3 years ago

Frick commented 3 years ago

I had this working in bypass mode for more than a year previously, but after upgrading to 2.5 I've been unable to get it working again on a couple occasions. There's only so much time I can spend debugging with the internet down. :grimacing: Hoping someone here can help since everything seems set up correctly, but EAP simply fails to authenticate. I'm currently running in IP passthrough on the gateway (BGW210).

Setup:

netgraph image

tcpdump

I should have opened multiple terminals to dump the interfaces simultaneously for a clearer picture, but I think this gets the point across. The behavior seen below is exactly what happens in a ~30s loop. Of note - I don't know where this Thompson Telecom MAC address (00:90:d0:<snip>) is coming from since all of the NICs are Intel and there's nothing with that MAC in the path that I can tell (though I don't know the ONT's MAC).

RG

[2.5.0-RELEASE][admin@pfsense]/root: tcpdump -ei em3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em3, link-type EN10MB (Ethernet), capture size 262144 bytes
01:00:50.415180 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
01:01:04.566238 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL logoff (2) v2, len 0
01:01:04.566361 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
01:01:04.568231 00:90:d0:<snip> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 4
01:01:04.568238 00:90:d0:<snip> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
01:01:04.568478 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15

01:01:34.808218 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
01:01:34.810234 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15

01:02:04.138763 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
01:02:06.033682 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
01:02:06.035428 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
^C
11 packets captured

ONT

[2.5.0-RELEASE][admin@pfsense]/root: tcpdump -ei em0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:52:31.390323 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
00:52:33.151561 <RG MAC> (oui Unknown) > 01:80:c2:00:00:03 (oui Unknown), ethertype EAPOL (0x888e), length 60: EAPOL start (1) v2, len 0
00:52:33.153567 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype 802.1Q (0x8100), length 68: vlan 0, p 7, ethertype EAPOL, EAP packet (0) v1, len 15
00:52:40.001315 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:52:42.044655 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:52:45.011275 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:52:50.002502 <RG MAC> (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 346: vlan 0, p 0, ethertype IPv4, 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

ngeth0

[2.5.0-RELEASE][admin@pfsense]/root: tcpdump -ei ngeth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ngeth0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:56:02.021988 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:10.610531 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15
00:56:11.735256 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15
00:56:28.126180 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:30.101038 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:33.006751 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:37.002348 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
00:56:41.917670 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15
00:56:42.959443 00:90:d0:<snip> (oui Unknown) > <RG MAC> (oui Unknown), ethertype EAPOL (0x888e), length 64: EAP packet (0) v1, len 15
00:56:45.043872 <RG MAC> (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <RG MAC> (oui Unknown), length 300
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

pfatt.sh logs (prefix removed for brevity)

pfSense + AT&T U-verse Residential Gateway for true bridge mode
Configuration: 
       ONT_IF: em0
        RG_IF: em3
RG_ETHER_ADDR: <RG MAC>
attaching interfaces to ng_ether... OK!
building netgraph nodes...
  creating ng_one2many... OK!
  creating vlan node and interface... OK!
  defining etf for em0 (ONT)... OK!
  defining etf for em3 (RG)... OK!
  bridging etf for em0 <-> em3... OK!  
  defining filters for EAP traffic... OK!
  enabling one2many links... OK!
  removing waneapfilter:nomatch hook... OK!
enabling em3 interface... OK!
enabling em0 interface... OK!
enabling promiscuous mode on em3... OK!
enabling promiscuous mode on em0... OK!
ngeth0 should now be available to configure as your pfSense WAN
done!

Any help or similar experiences would be greatly appreciated! I'm kind of at a loss as to why it's not working, but also not 100% sure on exactly what traffic should or should not be tagged vlan 0 (primarily in regards to EAP).

septer012 commented 3 years ago

I think because you have eapol start to the RG you actually authenticated and are failing to get a dhcp address. There is a similar reddit post, unless this is your post. https://www.reddit.com/r/PFSENSE/comments/lw9uhl/att_fiber_pfatt_pfsense_25_dhcp_not_getting_ip_on

darkwhispering commented 3 years ago

@Frick I'm the author of the reddit post @septer012 linked above. As per my post, I had issues for weeks that I could not resolve. The eapol is successful, looks like yours is as well, but the router never gets the DHCP IP for some reason. I have no clue why.

I could only resolve the issue by going to pfSense 2.4.5. Since then my system have been running stable for more than 2 weeks.

Frick commented 3 years ago

Sorry for the radio silence. I've been incredibly busy with some other things. I'll give this a shot again in a couple of weeks. I'm traveling a bit right now and really love the Wireguard integration with pfSense 2.5 and so unwilling to downgrade to 2.4.5 for now. Really hoping to figure this out since I'm otherwise very happy with 2.5!

A-vesalius commented 3 years ago

Sorry for the radio silence. I've been incredibly busy with some other things. I'll give this a shot again in a couple of weeks. I'm traveling a bit right now and really love the Wireguard integration with pfSense 2.5 and so unwilling to downgrade to 2.4.5 for now. Really hoping to figure this out since I'm otherwise very happy with 2.5!

You must have been busy to miss the post-release pfSense 2.5/wireguard back and forth. Long story - short version is that there are critical bugs in the pfSense wireguard version and it will be removed in 2.5.1.

https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/

Frick commented 3 years ago

I really was. That is awful news, but thank you for bringing it to my attention. I'll spend my next opportunity downgrading to 2.4.5 and also looking for something else to get my Wireguard fix, whether just a Pi behind pfSense or replacing pfSense all together. :disappointed:

A-vesalius commented 3 years ago

I really was. That is awful news, but thank you for bringing it to my attention. I'll spend my next opportunity downgrading to 2.4.5 and also looking for something else to get my Wireguard fix, whether just a Pi behind pfSense or replacing pfSense all together. 😞

You can Try OPNsense. Similar setup to pfSense, but better GUI, IMO. Running it in a VM now. Works with this AT&T bypass script and has a safe wireguard implementation, not quite as fast as a kernel implementation, but still faster than openVPN and the same setup.

4pack commented 3 years ago

Can confirm, having this exact same issue. Cannot get a DHCP lease to save my life. This worked perfectly in 2.4.5.

Archerious commented 3 years ago

Same issue here.

septer012 commented 3 years ago

Apparently working on 2.5.1. https://www.reddit.com/r/PFSENSE/comments/mrnuno/pfsense_ce_251_and_pfatt

septer012 commented 3 years ago

I rolled the dice. It took a long time after upgrade to boot up, but its working and I got an IP address.

  21.02.2-RELEASE (amd64)