Just disabled NTP and it crashed. Switched Time Sync on HyperV back on but still have the calcru errors bigtime. 8 14:07:48 kernel calcru: runtime went backwards from 45 usec to 22 usec for pid 16327 (sshlockout_pf) Apr 8 14:07:48 kernel calcru: runtime went backwards from 10462 usec to 5290 usec for pid 16327 (sshlockout_pf) Apr 8 14:07:48 kernel calcru: runtime went backwards from 1677 usec to 848 usec for pid 16207 (sshd) Apr 8 14:07:48 kernel calcru: runtime went backwards from 1677 usec to 848 usec for pid 16207 (sshd) Apr 8 14:07:48 kernel calcru: runtime went backwards from 4453 usec to 2251 usec for pid 9777 (xinetd) Apr 8 14:07:48 kernel calcru: runtime went backwards from 4453 usec to 2251 usec for pid 9777 (xinetd) Apr 8 14:07:48 kernel calcru: runtime went backwards from 368431 usec to 241009 usec for pid 9199 (openvpn) Apr 8 14:07:48 kernel calcru: runtime went backwards from 21535 usec to 10889 usec for pid 9199 (openvpn) Apr 8 14:07:48 kernel calcru: runtime went backwards from 368307 usec to 241009 usec for pid 9199 (openvpn) Apr 8 14:07:48 kernel calcru: runtime went backwards from 2489 usec to 1280 usec for pid 310 (devd) Apr 8 14:07:48 kernel calcru: runtime went backwards from 14292 usec to 7226 usec for pid 310 (devd) Apr 8 14:07:48 kernel calcru: runtime went backwards from 2489 usec to 1280 usec for pid 310 (devd) Apr 8 14:07:48 kernel calcru: runtime went backwards from 403 usec to 203 usec for pid 300 (check_reload_status) Apr 8 14:07:48 kernel calcru: runtime went backwards from 403 usec to 203 usec for pid 300 (check_reload_status) Apr 8 14:07:48 kernel calcru: runtime went backwards from 6158 usec to 3113 usec for pid 298 (check_reload_status) Apr 8 14:07:48 kernel calcru: runtime went backwards from 5410 usec to 3113 usec for pid 298 (check_reload_status) Apr 8 14:07:48 kernel calcru: runtime went backwards from 606818 usec to 486460 usec for pid 262 (php-fpm) Apr 8 14:07:48 kernel calcru: runtime went backwards from 8660 usec to 5958 usec for pid 258 (php-fpm) Apr 8 14:07:48 kernel calcru: runtime went backwards from 8576 usec to 5958 usec for pid 258 (php-fpm) Apr 8 14:07:48 kernel calcru: runtime went backwards from 20517 usec to 10788 usec for pid 50 (md0) Apr 8 14:07:48 kernel calcru: runtime went backwards from 20397 usec to 10788 usec for pid 50 (md0) Apr 8 14:07:48 kernel calcru: runtime went backwards from 5302 usec to 4128 usec for pid 18 (bufdaemon) Apr 8 14:07:48 kernel calcru: runtime went backwards from 4260 usec to 3955 usec for pid 18 (bufdaemon) Apr 8 14:07:48 kernel calcru: runtime went backwards from 40 usec to 20 usec for pid 7 (sctp_iterator) Apr 8 14:07:48 kernel calcru: runtime went backwards from 42 usec to 21 usec for pid 7 (sctp_iterator) Apr 8 14:07:48 kernel calcru: runtime went backwards from 11642 usec to 6050 usec for pid 5 (fdc0) Apr 8 14:07:48 kernel calcru: runtime went backwards from 12584 usec to 6532 usec for pid 5 (fdc0) Apr 8 14:07:48 kernel calcru: runtime went backwards from 88779 usec to 49657 usec for pid 4 (cam) Apr 8 14:07:48 kernel calcru: runtime went backwards from 219977 usec to 111232 usec for pid 4 (cam) Apr 8 14:07:48 kernel calcru: runtime went backwards from 85795 usec to 50814 usec for pid 4 (cam) Apr 8 14:07:48 kernel calcru: runtime went backwards from 26023 usec to 13159 usec for pid 14 (geom) Apr 8 14:07:48 kernel calcru: runtime went backwards from 3263 usec to 1650 usec for pid 14 (geom) Apr 8 14:07:48 kernel calcru: runtime went backwards from 534 usec to 270 usec for pid 14 (geom) Apr 8 14:07:48 kernel calcru: runtime went backwards from 22460 usec to 11357 usec for pid 14 (geom) Apr 8 14:07:48 kernel calcru: runtime went backwards from 28 usec to 14 usec for pid 13 (ng_queue) Apr 8 14:07:48 kernel calcru: runtime went backwards from 32 usec to 16 usec for pid 13 (ng_queue) Apr 8 14:07:48 kernel calcru: runtime went backwards from 281 usec to 142 usec for pid 12 (intr) Apr 8 14:07:48 kernel calcru: runtime went backwards from 13417 usec to 6784 usec for pid 12 (intr) Apr 8 14:07:48 kernel calcru: runtime went backwards from 183 usec to 92 usec for pid 12 (intr) Apr 8 14:07:48 kernel calcru: runtime went backwards from 145 usec to 73 usec for pid 12 (intr) Apr 8 14:07:48 kernel calcru: runtime went backwards from 10296 usec to 5238 usec for pid 1 (init) Apr 8 14:07:48 kernel calcru: runtime went backwards from 12323683 usec to 6231750 usec for pid 1 (init) Apr 8 14:07:48 kernel calcru: runtime went backwards from 8820 usec to 5238 usec for pid 1 (init) Apr 8 14:07:48 kernel calcru: runtime went backwards from 2122 usec to 1279 usec for pid 0 (kernel) Apr 8 14:07:48 kernel calcru: runtime went backwards from 129751 usec to 65609 usec for pid 0 (kernel) Apr 8 14:07:48 kernel calcru: runtime went backwards from 17 usec to 8 usec for pid 0 (kernel) Apr 8 14:07:48 kernel calcru: runtime went backwards from 1207 usec to 650 usec for pid 0 (kernel) Apr 8 14:07:48 kernel calcru: runtime went backwards from 12 usec to 6 usec for pid 0 (kernel)

Brilliant! That was the problem. Thank you so much for the quick fix!

I have @gsiemon's logs and will work on this over the weekend.  There are some other issues on the ALERTS tab as well that I have fixed already.  I will bundle everything up into a single update and post it within a few days. Bill

@emce: Nope, I'm not currently running an IDS.

Not down. It prefers IPv6 unless you changed that under System>Advanced, Misc, so if you have IPv6 you'll need to ping6 to test. If you have what looks like IPv6 connectivity but isn't functional, that'll break it like that.

We've hinted at it (and I think mentioned it outright at least once) but yes, NanoBSD will be on the way out. It was good at the time, but the limitations it imposes are really not needed these days. The added complexity of dealing with its wasted space, extra partitions, ro/rw switch timing, etc, are all things we'd be better off without. SSD prices are down, and quality is vastly increased, and worrying about writes is not something many people have to do these days. Plus a full install with /var and /tmp in RAM would not have that many more writes than NanoBSD (for the base system anyhow…)

dude does your wifi come into pfsense on different interface?  If not then you would have to create your rules to block only specific IPs that are the ones you want to block, or allow depending on how you right the rule.

Alright, well I don't know how much that zbox set you back, but you have to isolate the issue somehow.  I would suggest testing a new install on different hardware.  If your symptoms go away, which I believe they will, you know your issues are coming from the zbox and it'll have to be replaced. You also try USB NIC's, but I don't know how reliable that will be.

Most likely whatever startup script/action you're running is wiping all that out then. Those aren't in a place that would be removed by the firewall itself.

The two pages you're looking for are here: https://www.pfsense.org/our-services/gold-membership.html https://www.pfsense.org/get-support/software-support.html Gold membership doesn't include support - hence the second link.

virtio is best regardless Thanks for the info. I was wondering if it was a wise choice.

Hi, thanks for your replies. NIC status says 1000mbps. I did change the cables after seeing interface errors and it seems it is okay now. Still observing though.. thanks guys!

Thanks to tips Please keep reading and you answered my question :) :) :) ;) ;) ;)

@jimp: Looks like /usr/local/sbin/gmirror_status_check.php lacked execute permissions in the repository, so this should fix it: chmod a+x /usr/local/sbin/gmirror_status_check.php Yes!! This fixed it, Thanks JIMP

"LAN on 192.168.1.0" won't work with a /24 (or 255.255.255.0, it's the same) netmask. Valid IPs are from 192.168.1.1 to 192.168.1.254 and your LAN has to be in that range! The same for your WAN networks, of course. .0 is the network's address and .255 the broadcast address (in a /24 network). @Ste178uk: … I can not connect to the webpage on the WAN interfaces... ??? If you want to connect FROM your WAN interface you have to add a rule to allow this.

Rebooting the modem on change of device connected to it is not faith based computing..  You have to clear its cache of the mac of the device it connected too..  Since they give you no interface into the things, the only way to reset that is reboot it. The instructions laid out marvosa are correct order of how you would swap out a device. What I do to get around having to reboot the modem when I play with different distros for firewall/router - I always go back to pfsense, but like to see what the other guys are doing every now and then.  Or if want to play with different version of pfsense, or want to try some with clean install of pfsense is just make sure all the VMs always use the same mac that is connected to the modem.  This way I don't have to reboot the modem and always have my same public IP as well.

found out it was the shutdown wake on lan that was the issue, changed it to enable and while i was in there i enabled patter match, dont know if i need this but oh well shutdown WOL - enable wake on pattern match - enable job done