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

    Failover on PFsense 2.6

    Scheduled Pinned Locked Moved Routing and Multi WAN
    25 Posts 3 Posters 2.5k 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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      I assume you are seeing a state for pings to 8.8.8.8 somewhere though?

      Otherwise check the gateway logs for the dpinger entries on WAN. You should see the values it's being started with.

      Steve

      S 2 Replies Last reply Reply Quote 0
      • S
        stafast @stephenw10
        last edited by

        @stephenw10 nope nothing in the states for 8.8.8.8, just DNS queries for one of the devices that is manually set to that DNS using that interface. As for the gateway logs there are no dpinger entries past 3/7 which I believe is from before I upgraded PFSense.

        1 Reply Last reply Reply Quote 0
        • S
          stafast @stephenw10
          last edited by

          @stephenw10 I'll try restarting dpinger, see if that does anything.
          Restarted and got these for each interface:

          send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 8.8.8.8 bind_addr

          not sure if it fixed it or if that's just a normal thing when restarting, only time will tell really when it goes down next. I was wondering why when our internet went down for 45min over the previous weekend that it was completely down, turns out just never failed over to the other WAN.

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

            That's normal except it should show the interface address for bind_addr. Did you just omit that?

            Check the main system logs for that time, are there any errors shown that might indicate dpinger did not start?

            S 1 Reply Last reply Reply Quote 0
            • S
              stafast @stephenw10
              last edited by

              @stephenw10 Oh yeah, I just omitted that portion of it. I'll look into if there are errors from that point about dpinger. After I restarted dpinger I am seeing that the route uses for the 8.8.8.8 to that Interface are going up when refreshing so that's a good sign at least. I did some digging in the logs, turns out I upgraded it earlier than I thought(Feb 21st) so dpinger was working for a while up until the 7th of March. So I'll just have to dig around in the logs to see if I can find any sort of reason why it would have stopped functioning despite it showing as up and running. This is definitely something that we can't have happening on a normal basis if it's a reoccurring issue as before 2.6 we ran without reboot for over a year with no issues, so I'm hoping I can find something in the logs that will help figure out why.

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