Ok so all clients are using pfSense for DNS. Both VPN and non-VPN clients. So that means to avoid a 'DNS leak' reported on vpn clients that Unbound must send all queries over the VPN. Either by resolving using the VPN interfaces only or by forwarding to the PIA DNS servers only. That does mean that if the VPN is down no clients will be able to resolve. Both vpn and non-vpn clients. I'm not sure why you have added the DNS servers to the VPN client config. Those should be passed to you by the server. But Unbound won't use them there either way. It can only forward to servers configured in general setup. A better setup here would be to put vpn clients on a separate interface. That way you can easily pass them different DNS servers to use etc.

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.

Yup, that's fixed in current versions.

@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 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.

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.

@ChrisJenk said in Netgate 6100 / 25.07 - any recipes / guidelines for optimising high speed LAN and WAN connections?: Speedtest program on the router itself No, I ran it on a Windows computer connected at 2.5Gb. I got full line speed up and down. I have since changed my internet to 1Gb so I only get 1.2Gb up and down now. A while back a friend and I were building and testing a VPN tunnel between us, a 7100 and a 6100, we found a noticeable speed difference if we used iperf on pfSense vs a computer on each end. We only get in the 700Mb/s range and still iperf on pfSense really added a load and skewed the results at least 10%.

If it's a paid subscription and you had to replace the hardware you should open a TAC ticket. We are not completely inflexible. Yes, it's tied to the hardware but if you are forced to change that we have options.

^^ yes - this. - and the syslogd fix in the works should resolve this.

@chudak said in Why do we need to pay for pfS + ????: How do you connect monitor to it? See for example https://docs.netgate.com/pfsense/en/latest/solutions/netgate-4200/#how-to-guides In general Netgate makes sure new releases work on old Netgate hardware until it can’t.

@stephenw10 thanks for the feedback!

Mmm, you'll probably have to wait for it to fail and check what states are still there. I'd expect it to just re-connect if the states timed out and start to fail.

Sounds like they are getting redirected locally if they see a cert error. Check what cert they are being offered. The details there may indicate what is intercepting the traffic.

@akhuyna It's like I already said that. :)

@SteveITS Since the Netgate 2100 is at the Methodist local church and I support the firewall, this was a real user issue. They access the site monthly to do retirement account contributions for the church employees. Fortunately the login mechanism (once you can see it) requires two-factor authentication. Glad for that.