Thanks for the suggestion. I'm not sure how often pfsense scans for the ip address for the WAN, but 8/10 times it will finally get a legit ip address, sometimes taking several minutes to register when I power down/up my modem.

There is a patch for 22.01/2.6 to fix the outbound NAT (masquerade) function of miniupnpd you may want to test: https://forum.netgate.com/topic/169837/upnp-fix-for-multiple-clients-consoles-playing-the-same-game It's in the recommended patches list in the System Patches package. Steve

Thanks for following up. That could save someone else a lot of time.

@panzerscope said in Editing loader.conf: @bmeeks Thanks guys. So it was indeed Snort. Removed it, and the logging went away. I have since installed Suricata and so far so good. Looks like high volume traffic through the WAN is not producing any queuing issues which is awesome. Thank you for the feedback. Hopefully this thread may help someone else in the future with a similar issue. I'm glad Suricata seems to be working better for you. I collaborated with the Suricata upstream team to add the multiple queue support for netmap back during the summer of 2021. Just be aware that using Inline IPS Mode (which requires netmap) will cause some issues with certain other pfSense/FreeBSD features. First and foremost, limiters and shapers are not currently compatible with netmap. Secondly, VLANs do not always work well. It depends on the exact configuration. When using Inline IPS Mode, you must run the Snort or Suricata instance on the physical parent VLAN interface.

@stephenw10 Thanks for the tip, I reinstalled the software

No, it's not restricted by license. Steve

Yes, the 2100 is arm64 and from 22.01 can run ZFS. The 3100 is 32bit and cannot.

@bingo600 Hello, You are correct, I do have capatable equipment. I'm Just trying to see what was the Minimum hardware for cpu, memory and hard drive space. But network cards are important as well. Joseph

The dashboard shows the total usage across all cores. So on the 2100 that's 2 cores. That could be both cores at 90% or one core at 100% and the other at 80%. Diag > System Activity should show you what's using it. 90% is very high unless it's passing a load of traffic. Running top -aSH at the CLI shows the same thing On a test box here I see: last pid: 72786; load averages: 0.17, 0.32, 0.26 up 0+02:28:52 15:38:17 623 threads: 3 running, 595 sleeping, 25 waiting CPU: 1.0% user, 0.0% nice, 1.8% system, 0.6% interrupt, 96.7% idle Mem: 82M Active, 683M Inact, 643M Wired, 1902M Free ARC: 428M Total, 123M MFU, 282M MRU, 552K Anon, 3223K Header, 19M Other 360M Compressed, 743M Uncompressed, 2.06:1 Ratio PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0B 32K CPU1 1 136:03 96.78% [idle{idle: cpu1}] 11 root 155 ki31 0B 32K RUN 0 137:38 96.08% [idle{idle: cpu0}] 21079 root 25 0 139M 44M accept 0 0:10 1.39% php-fpm: pool nginx (php-fpm){php-fpm} 12 root -60 - 0B 400K WAIT 0 1:13 0.82% [intr{swi4: clock (0)}] 72404 root 20 0 14M 4788K CPU0 0 0:00 0.72% top -aSH 0 root -92 - 0B 448K - 1 0:47 0.42% [kernel{dummynet}] 23993 root 20 0 28M 8084K kqread 1 0:01 0.22% nginx: worker process (nginx) 12 root -92 - 0B 400K WAIT 1 0:11 0.12% [intr{pcib0,0: ath0}] 78950 root 20 0 11M 2708K select 1 0:09 0.10% /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -l / 89921 root 20 0 405M 361M bpf 1 0:39 0.09% /usr/local/bin/snort -R _28847 -D -q --suppress-config-lo 12 root -92 - 0B 400K WAIT 0 0:05 0.07% [intr{gic0,s42: mvneta0}] 57454 root 20 0 15M 2624K nanslp 0 0:04 0.05% /usr/local/bin/dpinger -S -r 0 -i GIF_TUNNELV4 -B 10.2.4. 9 root -16 - 0B 16K pftm 1 0:09 0.05% [pf purge] Steve

Looks pretty standard. No errors shown. Was is not passing traffic when that was logged?

Yeah, if you have alternative sound hardware and it's recognised I think you can set that be the system sound device and should it work. I've never tried that myself though.

Thanks everyone for the replies. Certificate has been renewed

@keppler said in Network boot with IPXE: @stephenw10 Thanks for the feedback. TFTP is very slow. It always has been regardless of the server / hardware.

@bingo600 Thank you so much power cycling the modem worked! So now I have the Ip from my ISP mapped to the new MAC address of the netgate. Appreciate your help!!

@stephenw10 Of course, that's an excellent way, thank you. It doesn't look like DMZ is set up properly, there are some warnings in the firewall log, but they look odd and very consistent. Running ShieldsUP doesn't generate any output, and ShieldsUP result is also odd. Thank you for your suggestion, have contacted my ISP again.

Yes, you are correct; I currently have a pfSense+ subscription w. TAC-Lite and I would like to switch to a pfSense+ subscription w. Home/Lab Thank you both. I will open a ticket.

I opened a chat with you. You can send it there.

@stephenw10 @steveits No, It didn't lose power during the update, it just didn't come back online after the update. I am getting the firmware reinstalled as of this message. no other way of this error sadly other than a full wipe / fresh install