Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    2.7.0 PPPoE Continually Reconnecting

    Scheduled Pinned Locked Moved General pfSense Questions
    46 Posts 8 Posters 5.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      threadhead @stephenw10
      last edited by threadhead

      @stephenw10 As I moved back to 2.6.0 I did not save any of the logs. But my home is the same as the other. See attached.

      ipv4 routes

      And yes, the WAN_PPPOE is the default gateway.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        So the system that screenshot came from currently has connectivity for clients?

        That's what I expect the routing table to look like.

        T 1 Reply Last reply Reply Quote 0
        • I
          IanJanus @stephenw10
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            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

            I 1 Reply Last reply Reply Quote 0
            • I
              IanJanus @stephenw10
              last edited by

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

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                I'm also in the UK but I tend to be awake on US hours most of the time. 😉

                I 1 Reply Last reply Reply Quote 0
                • S
                  sanstey
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • I
                    IanJanus @stephenw10
                    last edited by

                    @stephenw10 I removed all VIPs and associated NAT rules and PPPoE connected and was stable.
                    So appears to be with handling of VIPs.

                    stephenw10S 1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      Ok, that's great data. Updated the bug: https://redmine.pfsense.org/issues/14434

                      1 Reply Last reply Reply Quote 0
                      • T
                        threadhead @stephenw10
                        last edited by threadhead

                        @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?

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          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?

                          T 1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator @IanJanus
                            last edited by

                            @IanJanus

                            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.

                            I 1 Reply Last reply Reply Quote 0
                            • T
                              threadhead @stephenw10
                              last edited by threadhead

                              @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

                              stephenw10S 1 Reply Last reply Reply Quote 0
                              • I
                                IanJanus @stephenw10
                                last edited by

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

                                1 Reply Last reply Reply Quote 0
                                • stephenw10S
                                  stephenw10 Netgate Administrator @threadhead
                                  last edited by

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

                                  T RobbieTTR 2 Replies Last reply Reply Quote 0
                                  • stephenw10S stephenw10 forked this topic on
                                  • stephenw10S stephenw10 referenced this topic on
                                  • RobbieTTR
                                    RobbieTT @stephenw10
                                    last edited by

                                    @stephenw10

                                    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]
                                    

                                    ☕️

                                    RobbieTTR 1 Reply Last reply Reply Quote 0
                                    • RobbieTTR
                                      RobbieTT @RobbieTT
                                      last edited by

                                      @RobbieTT said in 2.7.0 PPPoE Continually Reconnecting:

                                      @stephenw10

                                      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]
                                      

                                      @stephenw10

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

                                      ☕️

                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        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.

                                        RobbieTTR 1 Reply Last reply Reply Quote 1
                                        • RobbieTTR
                                          RobbieTT @stephenw10
                                          last edited by

                                          @stephenw10

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

                                          ☕️

                                          1 Reply Last reply Reply Quote 0
                                          • stephenw10S
                                            stephenw10 Netgate Administrator
                                            last edited by

                                            Hmm, interesting.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.