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

    PPPOE periodic recycle makes gateway down, but actually up.

    Scheduled Pinned Locked Moved General pfSense Questions
    10 Posts 3 Posters 1.0k 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.
    • M
      Makkok
      last edited by

      Hello Guys,

      I've an interesting observation regarding gateway monitoring.
      My setup looks, ISP modem with pppoe auth enabled, connected to the pfsense box with an internal static IP and this IP configured as a DMZ address on the ISP modem; every incoming packet from the internet side appearing on that internal interface which is fine for me for monitoring (NIDS) purposes. Works fine until the weekly periodic pppoe recycling /public ip changes/ occurs, then the gateway marked as down, but its online. After a short investigation I figured out this behavior is due to dpinger, because dpinger pings the monitor IP with the same id as it was before and the ISP modem drops these packets. My question; is there any solution to force gateway monitoring action to tell dpinger renew the ping process when a gateway goes offline?
      Thanks!

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @Makkok
        last edited by

        @makkok
        You should better consider to monitor a public IP in the internet. Monitoring the modem gives no proper information about your internet connectivity and hence makes no sense anyway.

        You can state an alternative IP to monitor in System > Routing > Gateways in the gateway settings.

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

          Yup, that.

          Either leave dpinger monitoring the default gateway IP, which in your case will be the modem so not all that useful. Or set a monitoring IP that can be reached from anywhere like 8.8.8.8 or 1.1.1.1. That will give you much better data for actual connectivity anyway.

          Steve

          1 Reply Last reply Reply Quote 1
          • M
            Makkok @viragomann
            last edited by

            @viragomann

            Thanks for the suggestion I've monitored the ISP-s external gateway IP address, btw I've changed now the monitor ip to 1.1.1.1. Let's see what will happen at the next pppoe cycle. 😊

            1 Reply Last reply Reply Quote 0
            • M
              Makkok
              last edited by

              Today a PPPOE recycling was done but the behavior remains the same. No response from the external monitoring IP (1.1.1.1) with dpinger but if I ping manually the monitoring address everything is ok.
              So the question is how can I force dpinger to create a new ping session every time when the gateway marked as down.

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

                That should happen automatically. What do the logs show when it reconnects?

                Check the state table for the outbound ping state. I expect to see a new state created when the WAN comes back up with a different gateway. An old state would still have route-to applied via the old gateway.

                Steve

                M 1 Reply Last reply Reply Quote 0
                • M
                  Makkok @stephenw10
                  last edited by

                  @stephenw10

                  No interesting in logs just one notification from dpinger about the loss.

                  de4a157f-b6ef-4c2d-9d3c-23da76b8e2f6-kép.png

                  I think the problem is the WAN interface remains up when the ISP modem changes its public IP, dpinger process doesn't restart itself because the WAN interface itself is fine, no changes were made on them, the change was made only on the ISP modem side during the pppoe cycling.

                  So the thing is how can I force dpinger to restart when a gateway marked as down?
                  Or another perspective how can I automatic restart the interface belongs to this gateway when the gateway marked as down causing restart dpinger?

                  A simple snippet from my setup;

                  9622911b-dbc0-4d56-8e3f-607253d3976f-kép.png

                  In veryvery simple:
                  PPPOE recycling -> gateway marked as down -> restart the interface belongs to this gateway (this is my solution currently by hand, don't like it Iamlazy) -> dpinger will restart due to interface restart indeed -> pinging monitor address working again with new ID -> gateway marked as up -> Iamhappy.

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

                    Ah, OK. So you're not actually doing the PPPoE on pfSense?
                    In that case dpinger shouldn't need to restart. The upstream router should be taking care of that. Sounds like it isn't clearing the old states when it should do.

                    You might consider passing though the PPPoE to pfSense instead if you can.

                    Steve

                    M 1 Reply Last reply Reply Quote 0
                    • M
                      Makkok @stephenw10
                      last edited by

                      @stephenw10

                      Thank you for the suggestions, finally I've figured out the root cause. The ISP modem does not handle DMZ properly, that means not clears old states when pppoe recycling occurs... What a mess...😠 So simply disable DMZ and make pfsense box as a "regular" internal host and do manual forwardings on the ISP modem all of the traffic to this IP (my pfsense box). Works fine when pppoe recycles.👍

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

                        Urgh. Nice catch though. 👍

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