Pfsense WAN timeout with logs

Networking & Firewalls
1

Long time lurker first time poster. I’m having issues with my pfsense instance and have been chasing my tail for the better part of the week to try and figure out what’s taking place. At what appears to be random times, I receive high WAN gateway alarm and end up dropping the WAN for 3-5 minutes at a time. This happes maybe 2-3 times a day–again at what seems like random times. I’m running this on a Dell R-210 with 16 megs of RAM. Pfsense is running under Proxmox. I’m running both pfBlockerNG and Snort. I’ve tried disabling Snort to determine if that was the case, but there was no change.

Additionally, I have called the ISP and they show no issues with the modem during these times. The modem appears to be online when the WAN Gateway goes down and believe that this is strictly on my end.

Any help or pointers on where to begin would be greatly appreciated.

Jul 21 10:48:45 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:48:45 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:48:45 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:48:45 xinetd 33707 readjusting service 6969-udp
Jul 21 10:48:45 xinetd 33707 Swapping defaults
Jul 21 10:48:45 xinetd 33707 Starting reconfiguration
Jul 21 10:48:42 php-fpm 90642 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:48:41 check_reload_status Reloading filter
Jul 21 10:48:41 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:48:41 check_reload_status Restarting ipsec tunnels
Jul 21 10:48:41 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:48:41 rc.gateway_alarm 76914 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:0 RTT:37.575ms RTTsd:56.352ms Loss:0%)
Jul 21 10:48:33 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:48:33 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:48:33 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:48:33 xinetd 33707 readjusting service 6969-udp
Jul 21 10:48:33 xinetd 33707 Swapping defaults
Jul 21 10:48:33 xinetd 33707 Starting reconfiguration
Jul 21 10:48:30 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:48:30 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:48:29 check_reload_status Reloading filter
Jul 21 10:48:29 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:48:29 check_reload_status Restarting ipsec tunnels
Jul 21 10:48:29 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:48:29 rc.gateway_alarm 95407 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:580.170ms RTTsd:1586.574ms Loss:5%)
Jul 21 10:47:42 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:47:42 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:47:42 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:47:42 xinetd 33707 readjusting service 6969-udp
Jul 21 10:47:42 xinetd 33707 Swapping defaults
Jul 21 10:47:42 xinetd 33707 Starting reconfiguration
Jul 21 10:47:39 php-fpm 49979 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:47:39 php-fpm 49979 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:47:38 check_reload_status Reloading filter
Jul 21 10:47:38 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:47:38 check_reload_status Restarting ipsec tunnels
Jul 21 10:47:38 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:47:38 rc.gateway_alarm 18423 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:19178.624ms RTTsd:25097.027ms Loss:81%)
Jul 21 10:46:59 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:46:59 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:46:59 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:46:59 xinetd 33707 readjusting service 6969-udp
Jul 21 10:46:59 xinetd 33707 Swapping defaults
Jul 21 10:46:59 xinetd 33707 Starting reconfiguration
Jul 21 10:46:50 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:46:50 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:46:49 check_reload_status Reloading filter
Jul 21 10:46:49 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:46:49 check_reload_status Restarting ipsec tunnels
Jul 21 10:46:49 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:46:49 rc.gateway_alarm 64096 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:42.956ms RTTsd:57.997ms Loss:31%)
Jul 21 10:46:48 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:46:48 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:46:48 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:46:48 xinetd 33707 readjusting service 6969-udp
Jul 21 10:46:48 xinetd 33707 Swapping defaults
Jul 21 10:46:48 xinetd 33707 Starting reconfiguration
Jul 21 10:46:44 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:46:44 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:46:43 check_reload_status Reloading filter
Jul 21 10:46:43 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:46:43 check_reload_status Restarting ipsec tunnels
Jul 21 10:46:43 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:46:43 rc.gateway_alarm 8970 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:126.636ms RTTsd:376.258ms Loss:21%)
Jul 21 10:46:37 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:46:37 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:46:37 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:46:37 xinetd 33707 readjusting service 6969-udp
Jul 21 10:46:37 xinetd 33707 Swapping defaults
Jul 21 10:46:37 xinetd 33707 Starting reconfiguration
Jul 21 10:46:34 php-fpm 30175 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:46:34 php-fpm 30175 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:46:33 check_reload_status Reloading filter
Jul 21 10:46:33 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:46:33 check_reload_status Restarting ipsec tunnels
Jul 21 10:46:33 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:46:33 rc.gateway_alarm 34229 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:951.560ms RTTsd:2260.355ms Loss:9%)
Jul 21 10:45:49 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:45:49 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:45:49 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:45:49 xinetd 33707 readjusting service 6969-udp
Jul 21 10:45:49 xinetd 33707 Swapping defaults
Jul 21 10:45:49 xinetd 33707 Starting reconfiguration
Jul 21 10:45:46 php-fpm 30175 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:45:46 php-fpm 30175 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:45:45 check_reload_status Reloading filter
Jul 21 10:45:45 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:45:45 check_reload_status Restarting ipsec tunnels
Jul 21 10:45:45 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:45:45 rc.gateway_alarm 83064 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:33608.184ms RTTsd:24218.224ms Loss:58%)
Jul 21 10:45:35 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:45:35 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:45:35 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:45:35 xinetd 33707 readjusting service 6969-udp
Jul 21 10:45:35 xinetd 33707 Swapping defaults
Jul 21 10:45:35 xinetd 33707 Starting reconfiguration
Jul 21 10:45:33 php-fpm 49979 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:45:33 php-fpm 49979 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:45:32 check_reload_status Reloading filter
Jul 21 10:45:32 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:45:32 check_reload_status Restarting ipsec tunnels
Jul 21 10:45:32 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:45:32 rc.gateway_alarm 97122 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:40.958ms RTTsd:34.588ms Loss:95%)
Jul 21 10:44:51 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:44:51 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:44:51 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:44:51 xinetd 33707 readjusting service 6969-udp
Jul 21 10:44:51 xinetd 33707 Swapping defaults
Jul 21 10:44:51 xinetd 33707 Starting reconfiguration
Jul 21 10:44:48 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:44:48 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:44:47 check_reload_status Reloading filter
Jul 21 10:44:47 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:44:47 check_reload_status Restarting ipsec tunnels
Jul 21 10:44:47 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:44:47 rc.gateway_alarm 54992 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:986.470ms RTTsd:1774.127ms Loss:21%)
Jul 21 10:44:27 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:44:27 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:44:27 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:44:27 xinetd 33707 readjusting service 6969-udp
Jul 21 10:44:27 xinetd 33707 Swapping defaults
Jul 21 10:44:27 xinetd 33707 Starting reconfiguration
Jul 21 10:44:24 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:44:24 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:44:23 check_reload_status Reloading filter
Jul 21 10:44:23 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:44:23 check_reload_status Restarting ipsec tunnels
Jul 21 10:44:23 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:44:23 rc.gateway_alarm 24737 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:755.813ms RTTsd:1598.180ms Loss:0%)
Jul 21 10:43:37 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:43:37 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:43:37 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:43:37 xinetd 33707 readjusting service 6969-udp
Jul 21 10:43:37 xinetd 33707 Swapping defaults
Jul 21 10:43:37 xinetd 33707 Starting reconfiguration
Jul 21 10:43:35 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:43:33 check_reload_status Reloading filter
Jul 21 10:43:33 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:43:33 check_reload_status Restarting ipsec tunnels
Jul 21 10:43:33 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:43:33 rc.gateway_alarm 87232 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:0 RTT:35.375ms RTTsd:33.533ms Loss:0%)
Jul 21 10:42:51 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:42:51 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:42:51 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:42:51 xinetd 33707 readjusting service 6969-udp
Jul 21 10:42:51 xinetd 33707 Swapping defaults
Jul 21 10:42:51 xinetd 33707 Starting reconfiguration
Jul 21 10:42:48 php-fpm 90642 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:42:48 php-fpm 90642 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:42:47 check_reload_status Reloading filter
Jul 21 10:42:47 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:42:47 check_reload_status Restarting ipsec tunnels
Jul 21 10:42:47 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:42:47 rc.gateway_alarm 62188 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:2361.341ms RTTsd:3788.540ms Loss:5%)
Jul 21 10:42:01 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:42:01 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:42:01 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:42:01 xinetd 33707 readjusting service 6969-udp
Jul 21 10:42:01 xinetd 33707 Swapping defaults
Jul 21 10:42:01 xinetd 33707 Starting reconfiguration
Jul 21 10:41:58 php-fpm 90642 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:41:58 php-fpm 90642 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:41:57 check_reload_status Reloading filter
Jul 21 10:41:57 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:41:57 check_reload_status Restarting ipsec tunnels
Jul 21 10:41:57 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:41:57 rc.gateway_alarm 45664 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:35840.232ms RTTsd:23977.831ms Loss:62%)
Jul 21 10:41:46 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:41:46 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:41:46 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:41:46 xinetd 33707 readjusting service 6969-udp
Jul 21 10:41:46 xinetd 33707 Swapping defaults
Jul 21 10:41:46 xinetd 33707 Starting reconfiguration
Jul 21 10:41:44 php-fpm 30175 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:41:44 php-fpm 30175 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:41:43 check_reload_status Reloading filter
Jul 21 10:41:43 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:41:43 check_reload_status Restarting ipsec tunnels
Jul 21 10:41:43 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:41:43 rc.gateway_alarm 58096 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:78.017ms RTTsd:76.528ms Loss:77%)
Jul 21 10:41:13 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:41:13 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:41:13 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:41:13 xinetd 33707 readjusting service 6969-udp
Jul 21 10:41:13 xinetd 33707 Swapping defaults
Jul 21 10:41:13 xinetd 33707 Starting reconfiguration
Jul 21 10:41:10 php-fpm 49979 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:41:10 php-fpm 49979 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:41:09 check_reload_status Reloading filter
Jul 21 10:41:09 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:41:09 check_reload_status Restarting ipsec tunnels
Jul 21 10:41:09 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:41:09 rc.gateway_alarm 57707 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:3771.822ms RTTsd:5561.231ms Loss:21%)
Jul 21 10:40:57 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:40:57 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:40:57 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:40:57 xinetd 33707 readjusting service 6969-udp
Jul 21 10:40:57 xinetd 33707 Swapping defaults
Jul 21 10:40:57 xinetd 33707 Starting reconfiguration
Jul 21 10:40:46 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:40:46 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:40:46 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:40:46 xinetd 33707 readjusting service 6969-udp
Jul 21 10:40:46 xinetd 33707 Swapping defaults
Jul 21 10:40:46 xinetd 33707 Starting reconfiguration
Jul 21 10:40:46 php-fpm 90642 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:40:46 php-fpm 90642 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:40:45 check_reload_status Reloading filter
Jul 21 10:40:45 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:40:45 check_reload_status Restarting ipsec tunnels
Jul 21 10:40:45 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:40:45 rc.gateway_alarm 17311 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:2852.461ms RTTsd:5109.176ms Loss:0%)
Jul 21 10:40:36 php-fpm 90642 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:40:36 php-fpm 90642 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:40:35 check_reload_status Reloading filter
Jul 21 10:40:35 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:40:35 check_reload_status Restarting ipsec tunnels
Jul 21 10:40:35 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:40:35 rc.gateway_alarm 54257 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:2837.537ms RTTsd:5117.189ms Loss:0%)
Jul 21 10:40:35 xinetd 33707 Reconfigured: new=0 old=3 dropped=0 (services)
Jul 21 10:40:35 xinetd 33707 readjusting service 19001-tcp
Jul 21 10:40:35 xinetd 33707 readjusting service 19000-tcp
Jul 21 10:40:35 xinetd 33707 readjusting service 6969-udp
Jul 21 10:40:35 xinetd 33707 Swapping defaults
Jul 21 10:40:35 xinetd 33707 Starting reconfiguration
Jul 21 10:40:32 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet6, use the first one configured. ‘’
Jul 21 10:40:32 php-fpm 78306 /rc.openvpn: Gateway, none ‘available’ for inet, use the first one configured. ‘WAN_DHCP’
Jul 21 10:40:31 check_reload_status Reloading filter
Jul 21 10:40:31 check_reload_status Restarting OpenVPN tunnels/interfaces
Jul 21 10:40:31 check_reload_status Restarting ipsec tunnels
Jul 21 10:40:31 check_reload_status updating dyndns WAN_DHCP
Jul 21 10:40:31 rc.gateway_alarm 14048 >>> Gateway alarm: WAN_DHCP (Addr:XX.XX.XXX.X Alarm:1 RTT:76.294ms RTTsd:289.958ms Loss:21%)
2

So, can you hook up straight to you modem and experience dropped packets? That will tell you real quick if it’s a modem/ISP issue or a proxmox/pfsense issue.

3

Are you suggesting to take pfsense out and plug a computer directly into the modem? If so, that would unfortunately take the home network down which is needed now with everyone teleworking and with it only taking place once every 2-3 times a day, it might go missed unless I was actively on the computer when it started dropping packets.

Is there something obvious that I’m missing?

4

traceroute to 8.8.8.8 and take a copy of the output.

Disable the connection monitoring (so it doesn’t force it down)

Run a ping from inside to pfSense LAN, WAN GW, ISP dns server and 8.8.8.8 see which if any drop.

If you do start dropping packets then run trace route to the first one that stops working to narrow down exactly which hop is playing up

5

Typically you start with layer 1 and move your way up. How long have you had this set up like this? Were there any updates or changes made after the issue started happening?

6

Thanks for the pointers!

I performed a traceroute as suggested. I have about 10 hops prior to reaching its destination. Total time is about 35ms which isn’t bad?

I poked around for awhile, but I wasn’t able to locate where I could disable the connecction monitoring? Is that in the advanced features?

I pinged from all my interfaces and I have zero packet losses.

7

I only started using pfSense since March where I moved from a GoogleWiFi mesh setup to what I descibed in the beginning of the post. It took awhile to get everything tuned with pfBlockerNG and Snort. Once I had those running, I probably had a good solid 3 weeks before I started getting any issues. I don’t know if has anything to do with it, but the only thing that I tried recently was setting up OpenVPN. I created a few certs and ended up running into issues so I deleted everything and returned it back before starting to dabble with that feature. The only thing I wasn’t ablet o remove was a user cert I created, but I can’t imagine that would have any contribution to the symptoms I’m experiencing?

8

There was another crash this afternoon around 6. It was a little different and it had over 250 log entries in the 5 minutes. Everything from kernal

Jul 22 18:51:49 avahi-daemon 27151 Loading service file /usr/local/etc/avahi/services/ssh.service.
Jul 22 18:51:49 avahi-daemon 27151 Loading service file /usr/local/etc/avahi/services/sftp-ssh.service.
Jul 22 18:51:49 avahi-daemon 27151 WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jul 22 18:51:49 avahi-daemon 27151 avahi-daemon 0.7 starting up.
Jul 22 18:51:49 avahi-daemon 27151 Successfully dropped root privileges.
Jul 22 18:51:49 kernel igb1.520: promiscuous mode enabled
Jul 22 18:51:49 kernel igb1.400: promiscuous mode enabled
Jul 22 18:51:49 kernel igb2: promiscuous mode enabled
Jul 22 18:51:49 kernel igb1: promiscuous mode enabled
Jul 22 18:51:49 kernel igb1.520: promiscuous mode disabled
Jul 22 18:51:49 kernel igb1: promiscuous mode disabled
Jul 22 18:51:49 kernel igb1.400: promiscuous mode disabled
Jul 22 18:51:49 kernel igb2: promiscuous mode disabled
Jul 22 18:51:49 avahi-daemon 27151 Found user ‘avahi’ (UID 558) and group ‘avahi’ (GID 558).
Jul 22 18:51:49 php-fpm 69852 /rc.start_packages: Starting service avahi
Jul 22 18:51:49 avahi-daemon 59284 avahi-daemon 0.7 exiting.

So, I’m not exactly sure what’s going on. Reviewing the Proxmox CPU usage, I see a small spike that coincides with the event, but it isn’t prolonged.

9

System > Routing > edit
6th item down “Gateway Monitoring” untick.

I had a similar issue where for some reason the gateway monitoring thought the interface was down because the connection monitoring was having issues.

That’s probably good news. Did you ping all of the things I suggested? If the interface did go down then I would have thought you would have some loss. If you didn’t get any losses to 8.8.8.8 then the internet connection didn’t go down.

10

Yes, I pinged everything you had suggsted in your initial post. No issues at all on all seven interfaces that I’m running. I take that as a good thing…

Great, found it! I didn’t dig down that path! I’ve checked that and will let you know if that helps.

Another packet loss once again occurred this morning. I only posted the Gateway logs below.

I’m not familiar on how the packet loss is measured–is this packet loss based on the ping to the DNS being used? I’m using Cloud9 9.9.9.9 and Cloudflares 1.1.1.2 and 1.0.0.2 for my servers and I was curious if using either of these could cause the issues I’m experiencing? Is the dpinger using these to measure packet loss, or what is it reaching out to in order to determine that theres packet loss?

Jul 23 05:56:33 dpinger WAN_DHCP XX.XX,XXX,X: Clear latency 87554us stddev 79098us loss 1%
Jul 23 05:55:58 dpinger WAN_DHCP XX.XX,XXX,X: Alarm latency 1534529us stddev 2612308us loss 4%
Jul 23 05:55:07 dpinger WAN_DHCP XX.XX,XXX,X Alarm latency 37011032us stddev 23465541us loss 57%
Jul 23 05:55:07 dpinger WAN_DHCP XX.XX,XXX,X: duplicate echo reply received
Jul 23 05:55:07 dpinger WAN_DHCP XX.XX,XXX,X: duplicate echo reply received
Jul 23 05:55:07 dpinger WAN_DHCP XX.XX,XXX,X: duplicate echo reply received
Jul 23 05:55:04 dpinger WAN_DHCP XX.XX,XXX,X: Alarm latency 44616us stddev 13869us loss 98%
Jul 23 05:54:29 dpinger WAN_DHCP XX.XX,XXX,X: Alarm latency 505470us stddev 1041054us loss 42%
Jul 23 05:54:17 dpinger WAN_DHCP XX.XX,XXX,X: Alarm latency 378939us stddev 923832us loss 22%

Thanks again for everyone’s input!

11

Ok, I’m a little bit confused at this point.

If the connection monitor is downing your WAN (only one wan connection?) but you are getting pings from 8.8.8.8 (are you directly connected to 8.8.8.8…)

My understanding of the the connection monitor is that it pings the dns server for the Interface and uses the latency / loss from that to decide if it’s up. That’s why it’s often better to use an IP right on the edge of your ISP as the connection monitor IP. Additionally if you have multiple WAN connections then using a different IP is a good idea.

I had an issue where BT (British Telecom) were rate limiting connections to 8.8.8.8 and that kept making pfSense thing there was a problem. Switching connection monitoring off resolved the issue. I forget what the final fix was (I handed it back down to local support after working out what the problem was) but I think they switched to using BT’s DNS servers for that interface.

12

Yes, I only have one WAN which is connected directly to my ISP modem. I may try changing my setup to use only a single DNS and to re-enable monitoring to see if there’s any difference with the DNS? I don’t know if having the three DNS options for a single WAN interface is causing any issues.

I’m unable to get to the computer to ping anything when I’m having an event that has taken down the WAN with it being so sporadic in nature. This might be something else to toy around with. Since I’ve stopped monitoring the WAN interface, I don’t think that I’ve experienced any interfaces going down.

I’ll report back on the DNS reduction to a single address while enabling monitoring. Thanks for the ideas!

Update: I just now noticed that there’s the option to monitor, perform no action for the WAN. I checked that option in order to receive logs on any latency issues.

13

I have been experiencing the same thing and unable to figure it out.

14

I also have the same issue. I told pfSense to take now actions on these alerts, but my internet connection still freezes a few times a day. I think I read somewhere on this forum that pfSense 2.6.0 can cause very high latency at times. Can anyone confirm this?

15

To be honest I have ran into this issue before and I am ashamed to admit that it was literally as silly as the physical ethernet cable from the modem to the pfsense router that was causing my issues. And it wasn’t just 1 time it was twice where we had a site at the company I work for had the same issues and at my house. Just random drops for no reason. Even worse it was within the same month I believe. It might be worth swapping the ethernet cable or checking the ethernet cable for electrical interference.