Stops routing all traffic for 15min intervals, starting at the top of the hour
-
version : 2.3-RELEASE
hardware : old pizza box running PentiumD 2.8GHz, plenty of RAM and disk spaceOn seemingly random hours, at the top of the hour, pfSense stops routing ALL traffic. It occurs at 2am and 2pm CDT with some regularity, but also has been observed on other hours of the day. I have a modem running in bridged mode in front of my single-wan/mult-lan pfsense box. When this issue occurs:
-
external monitoring can ping my gateway/modem, but cannot get a response from any ip/port that is managed by pfsense
-
all LAN clients on all LANs are unable to access the internet
-
all LAN clients are unable to reach the pfSense ( as their gateway )
-
in all instances, routing/connectivity was restored at 15 minutes after the hour in which it occurred
-
in all instances, I can see good-traffic being blocked during that 15 minutes
-
in the syslogs, at the top of the hour, I can see:
php -> [pfBlockerNG] Starting cron process. xinetd -> Starting reconfiguration ... xinetd -> Reconfigured: new=0 old=1 dropped=0 (services) php -> [pfBlockerNG] No changes to Firewall rules, skipping Filter ReloadI suspect that there's a cron collision between /etc/rc.filter_configure_sync and (one|both) of the pfblockerng scripts, and then at 15 minutes after the hour the /etc/rc.filter_configure_sync script corrects the issue. I really like pfSense, but need to get this resolved before I lose more customers from my SOHO. Can someone please confirm and/or point me in the right direction?
SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log #minute hour mday month wday who command # # # pfSense specific crontab entries # Created: May 6, 2016, 11:35 pm # 1,31 0-5 * * * root /usr/bin/nice -n20 adjkerntz -a 1 3 1 * * root /usr/bin/nice -n20 /etc/rc.update_bogons.sh */60 * * * * root /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 sshlockout 1 1 * * * root /usr/bin/nice -n20 /etc/rc.dyndns.update */60 * * * * root /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 virusprot 30 12 * * * root /usr/bin/nice -n20 /etc/rc.update_urltables 0,15,30,45 * * * * root /etc/rc.filter_configure_sync */60 * * * * root /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 webConfiguratorlockout 0 22 1,2,3,4,5,6,7 * 2 root /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php dc >> /var/log/pfblockerng/extras.log 2>&1 0 * * * * root /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php cron >> /var/log/pfblockerng/pfblockerng.log 2>&1 # # If possible do not add items to this file manually. # If done so, this file must be terminated with a blank line (e.g. new line) # -
-
php -> [pfBlockerNG] Starting cron process.
xinetd -> Starting reconfiguration
…
xinetd -> Reconfigured: new=0 old=1 dropped=0 (services)
php -> [pfBlockerNG] No changes to Firewall rules, skipping Filter ReloadFrom the system.log that you posted… pfBlockerNG loaded up and determined that there was nothing to do:
"No changes to Firewall rules, skipping Filter Reload"So it wouldn't have run rc.filter_configure_sync()
Take a look at the pfblockerng.log, and see if you can correlate the issue better… Try to increase the Cron setting of "once per hour" and see if that helps? Post a screenshot of the pfBlockerNG widget if you can...
-
Wow - thank you for the quick response.
I've increased the CRON Settings from "Every hour" to "Every 4 hours" and will continue to monitor. I've attached the pfBlockerNG widget screenshot, as well as attaching my pfblockerng.log ( if it helps ).
I've reviewed the pfblockerng.log (as well as the other log files under /var/log/pfblockerng/ ), but nothing really jumps out at my untrained eyes; the times in the logs are in CDT. My most recent outage [captured by monitoring] would have lined up with log entries from 05/06/16 23:00:00 CDT to 05/06/16 23:15:00 CDT. I may have played with some settings shortly after connectivity resumed.
I just saw that I could upgrade pfBlockerNP … so that's done now too.
[1/1] Upgrading pfSense-pkg-pfBlockerNG from 2.0.12 to 2.0.14…
