Yes, ~5% is typical usage: [22.01-RELEASE][admin@7100.stevew.lan]/root: top -aSH last pid: 66887; load averages: 0.16, 0.16, 0.08 up 0+00:03:03 12:54:54 579 threads: 5 running, 547 sleeping, 27 waiting CPU: 0.0% user, 0.0% nice, 1.8% system, 0.0% interrupt, 98.2% idle Mem: 99M Active, 62M Inact, 398M Wired, 7302M Free ARC: 175M Total, 30M MFU, 142M MRU, 32K Anon, 597K Header, 2248K Other 48M Compressed, 125M Uncompressed, 2.61:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0B 64K CPU0 0 2:53 99.77% [idle{idle: cpu0}] 11 root 155 ki31 0B 64K CPU2 2 2:54 99.73% [idle{idle: cpu2}] 11 root 155 ki31 0B 64K CPU3 3 3:00 98.26% [idle{idle: cpu3}] 11 root 155 ki31 0B 64K RUN 1 3:04 93.52% [idle{idle: cpu1}] 8 root -16 - 0B 16K e6000s 1 0:11 6.37% [e6000sw tick kproc] 65687 root 20 0 14M 4668K CPU1 1 0:00 0.16% top -aSH The process polls the switch IC for the port status once a second. It does so using the MDIO bus via ix2 but that process is slow in the ix driver so it ends up using significant CPU time. The same process in the 2100 or 3100 is faster via the mvneta driver so it appears to use less CPU time there. Steve

Mmm, this is not regression, it's always behaved like that, as noted here: https://forum.netgate.com/post/111569 As is says there: 'The last SAVED values will be used, not necessarily the values entered here.' After you test the values shown are not those you just tested with so saving afterwards can replace them with bad values. I agree though it could be clearer. Steve

That looks like you have a VPN from pfSense to the AWS VPC? AWS use APIPA addresses for the VPN tunnel subnet to route across so that may be expected. If you can make connections from AWS to the local DB server then it probably has a route back in order to reply. Unless the outbound NAT you added was on the internal pfSense interface. In that case the traffic from AWS appears to be local so it can reply but it can never open connections the other way. If you need to do that then you need to fix the routing issue rather than masking it with OBN. Almost certainly the DB server has a bad or missing default route. Steve

@jimp not just to @manicmoose , it happened to me today when reinstalling a 2.6 box in order to get the new ZFS layout. Steps to reproduce: a 2.6 box (VM on ESXi) with older ZFS layout, upgraded since 2.4 series install 2.6 over it, choose to recover the old config (note there are no keys in /etc/ssh after the installer finishes) after first and subsequent boots, the sshd keys are not regenerating, and clicking "Start" on the SSH service yields nothing. Only starting from CLI reveals the issue (missing keys). Regen via CLI (almost instant) cd /etc/ssh ssh-keygen -N '' -t rsa -f ssh_host_rsa_key ssh-keygen -N '' -t ed25519 -f ssh_host_ed25519_key adapted from here fixes it.

See: https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#exchange-online You can just use the json list directly in pfBlocker-ng to get a list of IPs for office365, including Exchange, and it will be auto updated. It doesn't include IPv6 yet. [image: 1649853872141-screenshot-from-2022-04-13-13-43-37.png] Steve

@pfnuevo said in 2009 MacMini - occasional crashes after logging in: I suspect the 70Mbps throughput is enough to max the 2 core CPU? Very unlikely, 70Mbps is nothing for anything remotely recent. What CPU is in that? USB Ethernet devices are notoriously unreliable in FreeBSD/pfSense. It should never disconnect like that. I would use VLANs on the nfe NIC instead if you can. As long as your WAN connection is <1G you likely won't see any speed reduction and it will be waaaaay more reliable. Steve

No worries, glad you're up and running.

I what still working? The ancient 32bit install from 2013? Or is this just spam.... Edit: Yup. Steve

So something is preventing traffic from localhost on that install specifically. Does it give that same error even after boot? Steve

@stephenw10 Thanks Stephen, I'll be okay from here... really appreciate the help!

@jonathanlee https://getlabsdone.com/how-to-setup-pfsense-pppoe-wan/ Great example of bridging the modem

@stephenw10 That served the purpose. Thanks Ted

@michmoor have a play with the following:- awk, sed and echo I run the following at midnight to get yesterdays entries from the snort logs:- grep ^`date -v-1d +"%D"` /var/log/snort/snort_pppoe*/alert | awk -F, '{a[$5]++;} END {for(i in a) print a[i]" "i}' | sed 's/"//g' | sort -r ; echo grep ^`date -v-1d +"%D"` /var/log/snort/snort_pppoe*/alert ; echo So I get a summary like this:- Command output: Snort WAN Alerts (grep ^`date -v-1d +"%D"` /var/log/snort/snort_pppoe*/alert | awk -F, '{a[$5]++;} END {for(i in a) print a[i]" "i}' | sed 's/"//g' | sort -r ; echo) 3 ET TOR Known Tor Relay/Router (Not Exit) Node TCP Traffic group 108 3 ET TOR Known Tor Exit Node TCP Traffic group 107 3 (spp_sip) Content length mismatch 1 ET DOS Possible NTP DDoS Inbound Frequent Un-Authed MON_LIST Requests IMPL 0x03 Command output: Snort WAN Alerts Details (grep ^`date -v-1d +"%D"` /var/log/snort/snort_pppoe*/alert ; echo) 04/10/22-07:46:07.832658 ,1,2522107,4759,"ET TOR Known Tor Relay/Router (Not Exit) Node TCP Traffic group 108",TCP,45.61.188.191,60048,xx.xx.xx.xx,1080,54321,Misc Attack,2,alert,Allow 04/10/22-07:46:07.832658 ,1,2520106,4759,"ET TOR Known Tor Exit Node TCP Traffic group 107",TCP,45.61.188.191,60048,xx.xx.xx.xx,1080,54321,Misc Attack,2,alert,Allow 04/10/22-16:23:11.254875 ,140,18,2,"(spp_sip) Content length mismatch",UDP,192.241.212.220,55707,xx.xx.xx.xx,5060,54321,Potentially Bad Traffic,2,alert,Allow 04/10/22-18:08:00.070426 ,1,2522107,4759,"ET TOR Known Tor Relay/Router (Not Exit) Node TCP Traffic group 108",TCP,45.61.188.191,47241,xx.xx.xx.xx,1080,54321,Misc Attack,2,alert,Allow 04/10/22-18:08:00.070426 ,1,2520106,4759,"ET TOR Known Tor Exit Node TCP Traffic group 107",TCP,45.61.188.191,47241,xx.xx.xx.xx,1080,54321,Misc Attack,2,alert,Allow 04/10/22-20:42:03.730836 ,140,18,2,"(spp_sip) Content length mismatch",UDP,128.199.3.204,58177,xx.xx.xx.xx,5060,40209,Potentially Bad Traffic,2,alert,Allow 04/10/22-21:11:10.595437 ,140,18,2,"(spp_sip) Content length mismatch",UDP,165.232.128.219,58181,xx.xx.xx.xx,5060,47623,Potentially Bad Traffic,2,alert,Allow 04/10/22-22:53:32.283173 ,1,2522107,4759,"ET TOR Known Tor Relay/Router (Not Exit) Node TCP Traffic group 108",TCP,45.61.188.191,50650,xx.xx.xx.xx,1080,54321,Misc Attack,2,alert,Allow 04/10/22-22:53:32.283173 ,1,2520106,4759,"ET TOR Known Tor Exit Node TCP Traffic group 107",TCP,45.61.188.191,50650,xx.xx.xx.xx,1080,54321,Misc Attack,2,alert,Allow 04/10/22-23:34:44.609324 ,1,2017919,2,"ET DOS Possible NTP DDoS Inbound Frequent Un-Authed MON_LIST Requests IMPL 0x03",UDP,14.1.112.177,38376,xx.xx.xx.xx,123,54321,Attempted Denial of Service,2,alert,Allow NB the snort logs date format differs.

What hardware are you running on? What does top -aSH show for per core usage when testing throughput?

Ah, yes that would do it. The static values override whatever is in the main config. So leaving it empty there would not override 'none' set in the main config. Steve

@danlad2030 Here https://docs.netgate.com/pfsense/en/latest/packages/cache-proxy/squidguard.html

@anonymnuss said in random lockout single connection: If I switch the LAN adress of the proxy, its also blocked Hmm, that sounds like something blocking at layer2. In pfSense that could only be the Captive Portal. Try running a packet capture in pfSense whilst you ping from the proxy. Do the pings make it that far? I assume you don't see the traffic blocked in the firewall log? Steve

Are you using the captive portal also? There is a known issue with running both: [https://redmine.pfsense.org/issues/12954](link url) Steve