2.7.0 PPPoE Continually Reconnecting
-
@stephenw10 I removed all VIPs and associated NAT rules and PPPoE connected and was stable.
So appears to be with handling of VIPs. -
Ok, that's great data. Updated the bug: https://redmine.pfsense.org/issues/14434
-
@stephenw10 Sorry, was out for the weekend.
Yes, both of my pfSense routers are the same. I have no VIPs setup. I have no VLAN tagging for WAN. For the PPP config it is set to the WAN with link type PPPoE.
I was never able to get any traffic to route to the WAN. My internal firewall rules are fairly permissive, and I did try setting all the LAN(s) to WAN to allow all traffic.
Never was able to get it to work. Did I miss something important?
-
Hmm, yeah that's a different bug then unrelated to the VIP issue. Was pfSense itself able to connect out? The gateway showed as up?
-
To be clear this happens when you have a VIP that's in the same subnet as the WAN when it comes up?
Haven't managed to replicate that here yet. -
@stephenw10 Yes, gateway via PPPoE was able to pull a valid IP. The gateway (WAN) showed as active and I could see how long the IP address was obtained. The gateway on the Dashboard was green up-arrow.
No, I was never able to route traffic from any of the LANs to the WAN.
To add:
-
I did the pfSense update via browser, did not remove packages (probably should have)
-
Also, did a full wipe and reinstall of pfSense via usb stick to 2.7.0, nothing worked even with a full config restore
-
Did a full wipe and reinstall of pfSense 2.6.0, did a full config reinstall, everything worked
-
-
@stephenw10 Well the VIPs are in a /29 public IPs block that gets routed through the WAN, the PPPoE IP is usually completely different /32, so they aren't really in the same subnet as the WAN - since the WAN covers everything that isnt in a local subnet. However, they are defined in pfsense as associated with the WAN interface, though rather than define the /29 block, I have defined each VIP as a individual /32 IP.
-
@threadhead If you can replicate it you should check you have a default route applied via the PPPoE gateway. Also make sure you have outbound NAT rules being created for it.
-
S stephenw10 forked this topic on
-
S stephenw10 referenced this topic on
-
This may be related to an issue I have on v23.05.1. The PPPoE handshake process now takes over 20 seconds. It used to take a maximum of 4 seconds, typically just 2 or 3 seconds.
My last connection - 22 seconds to complete the PPPoE:
Jul 15 17:07:29 Router-8 ppp[17990]: Multi-link PPP daemon for FreeBSD Jul 15 17:07:51 Router-8 ppp[17990]: [wan] [redacted IPs]
️ -
@RobbieTT said in 2.7.0 PPPoE Continually Reconnecting:
This may be related to an issue I have on v23.05.1. The PPPoE handshake process now takes over 20 seconds. It used to take a maximum of 4 seconds, typically just 2 or 3 seconds.
My last connection - 22 seconds to complete the PPPoE:
Jul 15 17:07:29 Router-8 ppp[17990]: Multi-link PPP daemon for FreeBSD Jul 15 17:07:51 Router-8 ppp[17990]: [wan] [redacted IPs]As of v23.09d 20230921-1219:
PPPoE handshake log now looks totally normal and completes in 3 seconds:
Sep 21 18:55:32 ppp 25088 Multi-link PPP daemon for FreeBSD Sep 21 18:55:35 ppp 25088 [wan] IPCP: LayerUp Sep 21 18:55:35 ppp 25088 [wan] [redacted IPs]The extended PPPoE handshake issue appears to be resolved.
️ -
Hmm, that's interesting. I don't think we did anything specifically for that so I'd have to guess either some fix was pulled in from upstream or something changed at the server end.
-
It was an unexpected surprise but perhaps tied to a fix for something completely different. I skipped the last couple of dev loads so not sure which one had the desired effect but the issue remains with 23.09.a.20230907.0600.
It's not / was not a server-end PPPoE issue or change; as soon as I switched-out pfSense to a different router (EdgeRouter-4) the PPPoE handshakes reverted to normal.
Anyway, accidental fixes can be good, even if they leave questions.
Probably.
️ -
Hmm, interesting.
-
I came across this issue yesterday when I upgraded the backup of an HA pair to 2.7.0. My setup uses carp to handle the switchover from primary to backup, linking the pppoe interface to the carp VIP. When I tested failover, the backup enabled the pppoe interface and brought up the link but did not assign IPv4 local and remote addresses to the interface which meant that IPv4 was not routed and no IPv4 default route was installed. Sadly, I forgot to preserve the logs before downgrading back to 2.6.0.
Any ideas on workarounds for this?
-
That's not the same issue. The issue discussed in this thread is for VIPs on the PPPoE interface. It sounds like what you have is a PPPoE interface on a VIP.
You should start a new thread for that but I will say that what you're doing is an unsupported configuration. We have seen a few reports of it though.
Steve
-
@stephenw10 Thanks for the response - is there a recommended way of managing pppoe failover? I think I discovered my current approach from this thread: https://forum.netgate.com/topic/135904/configure-an-pppoe-on-an-carp-if/18.
-
Not really. HA requires static IPs for a supported setup.
-
This PPPoE + VIP issue is still present in 2.7.2/23.09.1. Until this issue is resolved, I'm stuck on 22.05 with no security patches. It's really unfortunate this isn't a higher priority issue.
-
Do you have a system log showing this happening? I though we had one here to reference but I'm not finding it now.
-
@stephenw10 I've attached a redacted version of my system.log file showing this.
"207.[REDACTED]" is the initial IP address my firewall receives before it applies one of my static IPs, which is "168.[REDACTED]."
Let me know if you need anything else!
system.log_redacted.txt
