Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Struggling after 2.5 upgrade #51

Open
Frick opened this issue Mar 9, 2021 · 10 comments
Open

Struggling after 2.5 upgrade #51

Frick opened this issue Mar 9, 2021 · 10 comments

Comments

@Frick
Copy link

Frick commented Mar 9, 2021

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. 😬 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:

  • em0 is ONT
  • em1 is LAN
  • em2 is unused
  • em3 is RG

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
Copy link

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
Copy link

@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
Copy link
Author

Frick commented Mar 28, 2021

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
Copy link

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
Copy link
Author

Frick commented Mar 28, 2021

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. 😞

@A-vesalius
Copy link

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
Copy link

4pack commented Apr 2, 2021

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

@Archerious
Copy link

Same issue here.

@septer012
Copy link

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

@septer012
Copy link

septer012 commented Apr 24, 2021 •
edited
Loading

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@Frick @darkwhispering @4pack @septer012 @Archerious @A-vesalius