Still needing a fix
-
Hello
I have just upgraded to 2.3.3, but an issue I had before still haunts me. At random times I am getting the following:
Mar 9 07:47:27 check_reload_status updating dyndns GW_WAN
Mar 9 07:47:27 check_reload_status Restarting ipsec tunnels
Mar 9 07:47:27 check_reload_status Restarting OpenVPN tunnels/interfaces
Mar 9 07:47:27 check_reload_status Reloading filterThe dyndns is unconfigured, with the Check IP Services set to the default. OpenVPN is also not configured. Any ideas as to what I need to do to stop this problem?
-
What is the problem? That you're seeing this in the logs? That is normal, those functions are called periodically regardless of whether you are using those features. Unless your system is not working as expected, just ignore them.
-
The problem is once this happens, my connection is lost. I have to get on the server and take the NIC down, then bring it back up.
-
Going to need more info than that then. Provide full(er) logs and more config details - what kind of WAN config do you have - DHCP? static IP? etc
-
Do you mean the System Log? I can do a cut and past of the last several hours, or just before the stopping. The WAN is a static IP address. There is no DHCP or OpenVPN operating on the system, it is just a firewall for a mail server.
-
What hardware is the pfSense running on?
What kind of NICs?
What is that WAN port connected to? A switch? A modem?
What monitor IP are you using for your gateway? Next hop or something further?
Send system.log at least 2-3 minutes leading up to the disconnect.
-
The pfSense firewall is running on a VM, which is running on Hyper-V. Here is the log from the last incident:
Mar 10 12:30:00 php-cgi rc.update_urltables: /etc/rc.update_urltables: Starting up.
Mar 10 12:30:00 php-cgi rc.update_urltables: /etc/rc.update_urltables: Sleeping for 21 seconds.
Mar 10 12:30:21 php-cgi rc.update_urltables: /etc/rc.update_urltables: Starting URL table alias updates
Mar 10 12:30:21 php-cgi rc.update_urltables: /etc/rc.update_urltables: pfB_Africa_v4 does not need updating.
Mar 10 12:30:21 php-cgi rc.update_urltables: /etc/rc.update_urltables: pfB_Asia_v4 does not need updating.
Mar 10 12:30:21 php-cgi rc.update_urltables: /etc/rc.update_urltables: pfB_Europe_v4 does not need updating.
Mar 10 12:30:21 php-cgi rc.update_urltables: /etc/rc.update_urltables: pfB_SAmerica_v4 does not need updating.
Mar 10 12:30:21 php-cgi rc.update_urltables: /etc/rc.update_urltables: pfB_Top_v4 does not need updating.
Mar 10 14:23:03 php-fpm 94270 /index.php: Successful login for user 'admin' from: 216.177.32.100
Mar 10 14:27:18 php-fpm 80636 /index.php: User logged out for user 'admin' from: 216.177.32.100
Mar 10 14:40:49 check_reload_status updating dyndns GW_WAN
Mar 10 14:40:49 check_reload_status Restarting ipsec tunnels
Mar 10 14:40:49 check_reload_status Restarting OpenVPN tunnels/interfaces
Mar 10 14:40:49 check_reload_status Reloading filter
Mar 10 14:43:37 php-fpm 28094 /index.php: Successful login for user 'admin' from: 216.177.32.100 -
Let me add, the last two octets of the IP are 49.31, the gateway which is upstream is 49.1. The upstream is the router out to the cloud.
-
Another piece of info, from the gateway log. This is what is in the log for the most recent incident, they are all the same:
Mar 13 14:24:03 dpinger GW_WAN 216.177.49.1: Alarm latency 1595us stddev 1087us loss 22%
Mar 13 14:29:22 dpinger GW_WAN 216.177.49.1: sendto error: 50
Mar 13 14:29:22 dpinger GW_WAN 216.177.49.1: sendto error: 50
Mar 13 14:29:23 dpinger GW_WAN 216.177.49.1: sendto error: 50
Mar 13 14:29:23 dpinger GW_WAN 216.177.49.1: sendto error: 50
Mar 13 14:30:22 dpinger GW_WAN 216.177.49.1: Clear latency 2014us stddev 2139us loss 6%