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

    Connection drops every day in evening at around 19:40

    Scheduled Pinned Locked Moved General pfSense Questions
    5 Posts 3 Posters 1.6k 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.
    • G
      golmaal
      last edited by

      This is going on since several days and I am not able to get a handle on it.

      Here are the log entries:

      Jul 8 19:43:39	check_reload_status: Restarting OpenVPN tunnels/interfaces
      Jul 8 19:43:39	check_reload_status: Restarting ipsec tunnels
      Jul 8 19:43:39	check_reload_status: updating dyndns WANGW
      Jul 8 19:43:18	php: rc.filter_configure_sync: Could not find IPv6 gateway for interface(wan).
      Jul 8 19:43:16	check_reload_status: Reloading filter
      Jul 8 19:43:16	check_reload_status: Restarting OpenVPN tunnels/interfaces
      Jul 8 19:43:16	check_reload_status: Restarting ipsec tunnels
      Jul 8 19:43:16	check_reload_status: updating dyndns WANGW
      Jul 8 19:42:27	php: rc.filter_configure_sync: Could not find IPv6 gateway for interface(wan).
      Jul 8 19:42:25	check_reload_status: Reloading filter
      Jul 8 19:42:25	check_reload_status: Restarting OpenVPN tunnels/interfaces
      Jul 8 19:42:25	check_reload_status: Restarting ipsec tunnels
      Jul 8 19:42:25	check_reload_status: updating dyndns WANGW
      

      Things were fine before the first event at 19:42:25. I don't use DynDNS/ IPSec / OpenVPN. Nothing configured there.

      These are log entries from a day before:

      Jul 7 19:43:23	php: rc.filter_configure_sync: Could not find IPv6 gateway for interface(wan).
      Jul 7 19:43:21	check_reload_status: Reloading filter
      Jul 7 19:43:21	check_reload_status: Restarting OpenVPN tunnels/interfaces
      Jul 7 19:43:21	check_reload_status: Restarting ipsec tunnels
      Jul 7 19:43:21	check_reload_status: updating dyndns WANGW
      Jul 7 19:42:31	php: rc.filter_configure_sync: Could not find IPv6 gateway for interface(wan).
      Jul 7 19:42:29	check_reload_status: Reloading filter
      Jul 7 19:42:29	check_reload_status: Restarting OpenVPN tunnels/interfaces
      Jul 7 19:42:29	check_reload_status: Restarting ipsec tunnels
      Jul 7 19:42:29	check_reload_status: updating dyndns WANGW
      

      Here it all starts at 19:42:29. I checked the logs numerous times and cannot find any significant event that may lead to this event at 19:42:29.

      I thought I might find some clue and thus checked CRON entries. Note that I haven't manually created any of these entries. The CRON entries are directly created by some configuration settings. (Screenshot attached)

      IPv6 configuration type on LAN and WAN (one each) is set to "None".

      Eagerly looking for some help or some inputs.

      Update:

      I found that the events of 19:42:29 and 19:42:25 begins exactly after 10 seconds of the gateway error:

      Jul 8 19:44:21	apinger: alarm canceled: WANGW(x.x.x.x) *** down ***
      Jul 8 19:43:29	apinger: ALARM: WANGW(x.x.x.x) *** down ***
      Jul 8 19:43:06	apinger: alarm canceled: WANGW(x.x.x.x) *** down ***
      Jul 8 19:42:15	apinger: ALARM: WANGW(x.x.x.x) *** down ***
      

      But it seems that the gateway monitoring is not correct in judging my connection as "down". I could verify that the connection was up even when the gateway monitoring told otherwise.

      cron.jpg_thumb
      cron.jpg

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

        You can see the graph showing pfSense's opinion of the gateway uptime at Status: RRD Graphs: Quality.

        It might be that pfSense's gateway monitor (apinger) is too sensitive for your gateway. You can adjust it for a longer timeout and/or latency here: System: Routing: Gateways: Click on the (e) to edit, Click on Advanced

        https://doc.pfsense.org/index.php/Multi-WAN_2.0#Monitor_IP

        Err

        –
        Erreu Gedmon

        Firewalls are hard...
        but the book makes it easier: https://portal.pfsense.org/book/

        1 Reply Last reply Reply Quote 0
        • G
          golmaal
          last edited by

          Still couldn't figure it out. But there was another thread with similar issue - disabled the gateway monitoring service entirely. It works - not perfect - but works. That said, the problem seems to be at the ISP end but can't convince them that this happens exactly at 19:42:nn everyday.

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

            @golmaal:

            […] but can't convince them that this happens exactly at 19:42:nn everyday.

            This is a shot in the dark, but does anything happen locally at that time of day? I helped someone once whose sprinklers came on at the same time every day soaking his DSL wiring on the wall of his house… He'd have a crappy connection for a few hours until things dried out. On another occasion the cleaning crew was using an outlet in the network closet for their vacuum cleaner causing strong enough surges to makes things reset.

            Err

            –
            Erreu Gedmon

            Firewalls are hard...
            but the book makes it easier: https://portal.pfsense.org/book/

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

              Yep, the dyndns log entry is just a symptom of the WAN going down. Note that the apinger logs don't show the line going bad slowly with excessive ping times or packet loss gradually building up. They show the WAN going down directly. What sort of WAN connection do you have? Does the time, 19.42, equate to anything you might have done? What time was it you last reset your modem?

              Steve

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