2.7.0 PPPoE Continually Reconnecting
-
So the system that screenshot came from currently has connectivity for clients?
That's what I expect the routing table to look like.
-
@stephenw10 Firstly, I had checked that the WAN_PPPoE gateway was selected as default, so I know it isnt a gateway selection issue (first thing I usually check if there is an issue). With my workaround of using another PPPoE router between pfsense and my modem, I have had to set up another gateway since I am now having to use a Static IP on the ethernet interface to the router.
The Bug report you mentioned does seem relevant to me, in that I also have a routeable block of public IPs (/29) and a /32 PPPoE address (and VIPs configured in pfsense).
In pfsense, I have configured the VIPs as individual /32 IPs rather than a /29 block - I don't know if that makes any difference.
Since this issue has arisen by doing a straight upgrade from a working 2.6.0 and also upgrading another instance removing the packages first and finally a completely new install with nothing other than a single WAN and LAN interface - I am suspecting this is a bug and not associated with the upgrade process.
Also like in the bug report, I see the PPPoE interface come up, get and IP (PPPoE IP) and shutdown and continue repeating endlessly. Also I notice that as far as the Vigor 130 Modem is concerned, it seems happy and appears to be up all the time and does not appear to be dropping the connection. -
If you're able to do so I would try testing the PPPoE link without any VIPs on it. If it then comes up and it stable as expected we can add your data to that ticket. That does seem like a bug and one that may that may not be that difficult to fix.
Steve
-
@stephenw10 Okay, will try that tomorrow afternoon when its quiet, since it will take me a little while to reconfigure everything back to PPPoE and don't want to start late afternoon in case it all goes wrong! Am in UK here and so time difference doesn't help! I'll post the results when done.
-
I'm also in the UK but I tend to be awake on US hours most of the time.
-
I've had this same issue on Plus since 23.01 was released and have been trying to track it down with no luck. I have the exact same scenario; PPPoE on VLAN 201 with a /29 block of IPs, individually defined as /32 VIPs. I just tested removing all VIPs and sure enough, the WAN connection came right up and continued working as expected, including after installing the 23.05.1 update.
-
@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?
