@stephenw10 im not 100% sure?? not sure what you all mean sorry so all LAN use 192.168.0.1 as the dns and gateways for VPN and WAN clients on the other Vlans they just use default so 192.168.10.1 for camera network thats the dns for that 192.168.20.1 dns for the IOT network and so on for the lancache.. server it is 192.168.0.32 where all the host over rides goto .. and the uplink is 103.86.96.100 dns i just used it as thats what i had.. from nordvpn now under the VPN PIA as dhcp options i use persist-key persist-tun remote-cert-tls server reneg-sec 0 auth-retry interact dhcp-option DNS 10.0.0.243 the 10.0.0.243 is the dns for PIA vpn.. now i seen some use semi colon on the end and some dont.. but neither made a difference.. and for my 2nd pia vpn i use 10.0.0.242 as the dns as i tried using the same 10.0.0.243 but found no difference as for bypassing the rules i dont think they do???? first line is pfblocker 2nd line is the routing bypass policy 3rd line is the vpn clients out the vpn gateway 4th line is the wan clients out the wan gateway i also watched another video where in the NAT rules for the VPN he didnt use the PIA interface.. but used the WAN interface NAT part.. i not sure if that makes a difference or not if u need more screen shots i can post them if u need to see more..

@jrey @stephenw10 So, in my case (just ran a test, but this seems somewhat consistent), syslogd dies within 1-3 minutes of the sink going down ("SENDTO: connection refused") though I can't tell exactly... because it doesn't log a message when it dies. Here's another question, however: I had been thinking of writing a script to automatically restart syslogd - but something strange happens if I issue sudo service syslogd restart: log messages are formatted differently. Before (restart with service command): <134>1 2025-09-03T16:24:08.900145-04:00 router0.kmpeterson.net filterlog 65829 - - 4,,,1000000103,igc3,match,block,in,4,0x0,,126,30636,0,none,6,tcp,52,131.100.72.48,73.142.180.157,80,59580,0,S,7528752,,8192,,mss;nop;wscale;nop;nop;sackOK After (restart with service command): <46>Sep 3 16:33:50 syslogd: restart Restarting using the pfSense UI (Status︎Services︎syslogd) reverts (?) back to what I expect (to parse - it breaks my monitoring given the VERSION field and time of day formatting). The logs UI shows the formatting as different as well. So, as usual, I'm wondering if I'm missing something... also I see log entries every 3 or 4 or 5 minutes implying that syslogd has restarted, along with a cron job every minute running /usr/sbin/newsyslog - any idea what is happening with these entries? (Happy to get a reference to look up - FreeBSD isn't my primary distro). Thanks again!

Yup, I'm running on a 3100 too which is probably many times slower than your CPU. Either way it looks like it's probably the multiple process spawning causing the issue. Let's see if they start to multiply again over time.

@keyser Fantastic, thank you! Yeah, I ended up getting to the JSON settings before I saw your reply, and I had DEBUG instead of just INFO and the logs were going crazy! I think, with as active as my network is, and as chatty as the DHCP devices are, I'm going to ignore the web GUI, and just tail the logs over SSH. That way I can grep and sed to my heart's content. I also set-up log rotation using the built-in method, so that's good. Every once in a while I have these bursts of pfSense learning.

@azalea You can read more about the specific notation you're asking about, the zone index, in this Wikipedia subsection of the "IPv6 address" article.

You can choose to boot the old kernel at the bootloader menu. But that's only the kernel, it will still fail to boot if the rest of the system is broken. In ZFS you can create a snapshot boot environment before upgrading you can roll back to. Plus does that automatically.

Yup, that's fixed in current versions.

Browser cache need clearing?

@marcg well that is good, then it should work for the OP.

@tman222 I've got T-Mobile Home Internet (THMI) set up as my backup to Starlink in a pfSense failover gateway group. It is kept alive by a ping to 8.8.8.8 and my gateway always has the ipv4 address of 192.168.12.1. The pfSense interface gets .12 address, right now, .12.145. For science, I turned on ipv6 dhcp to get the one and only ipv6 address from the TMHI gateway and it did get an ipv6 address it couldn't really do much with, kept alive by pinging the ipv6 of 8.8.8.8. Until it didn't work. One day the ipv6 address and interface was just dead and the ipv6 address wouldn't come back with some usual efforts. Since it was just an experiment, I shut the ipv6 off. Since TMHI won't give a prefix, it's really not much use that I can tell to have the router interface have an ipv6 address with nothing else downstream. So it just uses ipv4. Note, I have shut off all the wifi on the box and just use it through the ethernet port. I used a great IOS app called HINT Control to shut off the wifi on the TMHI gateway. I have my own wifi, so I don't need it polluting the em spectrum with more. Since we live in the sticks, both our Starlink and TMHI use CGNAT of a sort but I don't have any problems with double-NAT with either. It just works.

@stephenw10 thanks

@stephenw10 Thank you for providing these commands, and confirmation more logging is coming as well. The ISP is still investigating, I did setup an auto recovery mechanism which involved rebooting pfSense after 3 failed responses from the gateway in a 3 minute period, but now with the down up commands this will be a quicker and cleaner process, and since cycling the ppp is far less of an interruption than rebooting, I can do it without waiting 3 minutes as well. https://forum.netgate.com/post/1223518

I think you may be over reacting to users questions. There are plenty of things pfSense could be better at! Most commonly when we see reports of some service that worked fine behind some other router but not pfSense it's either a NAT issue or some ALG/Proxy that was present on the other device but not in pfSense. Try setting a static source port. The difficulty here is that it doesn't fail immediately. It looks as though the ecobee server marks the IP address bad in some way after some time and presumably after some conection event that pfSense fails to pass. But we have yet to see exactly what that is which makes it difficult to diagnose.

Mmm, I've never seen that here either.

OK so the file is not present which indicates it has completed boot. Do you see the 'bootup complete' line in the system logs?

ZFS is also a lot more resilient to filesystem issues than UFS. So if you see frequent power outages it's a much better choice. But, yes, it does write more to the drive. Though the default values in 25.07 reduce that significantly. You can mitigate it almost entirely by running RAM disks too.

Yup so check the routing and arp table on a client when it's unable to browse.