Connection drops every day in evening at around 19:40
-
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.
-
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
-
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.
-
[…] 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.
-
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