Hmm, that php error looks like this: https://redmine.pfsense.org/issues/13562 But that should have been fixed. You might want to add your result there.

What's actually broken here? You are just seeing that error? Something is trying to connect to somewhere that has no route. So usually that's because the firewall lost it's default route (otherwise it would have a route). It could also be some local gateway that has stopped responding that it needs for a route. OVH is notorious for weird addressing/subnetting schemes so you might have something odd like a gateway outside the local subnet. Steve

@ozanbabatas My problem is solved. Now I can connect VPN to the modem through a remote server and access it. Thanks

If you do that I recommend unchecking Backup SSH keys when you backup the config so you don't end up with the same keys on all hosts. That also affects the auto-config-backup key which you would want to be unique. Steve

@RubeGMachine Even browsers are doing the same...thought you would gather that intuitively.

Which DynDNS provider are you using?

Have you applied the recommended system patches? Those are in 2.7 already, try that if you can.

If you have more than one gateway defined, like a VPN gateway or an internal LAN gateway, you should definitely set WAN_PPPoE as default rather than automatic. Otherwise it may default to one of the others and that's almost always invalid.

for reasons I cannot explain. This router just starting working again yesterday. I can now screen and use the commands I have tried. I have no explanation why.

@sgw did you check Monitoring in pFsense on XG7100? Check Quality and then check delay std. dev - did it changed(increase) when you go from 22.05 to 23 version? Main is much worst then on 22.05.

@natharas said in Cant see switch in DCHP or ARP table: I have cameras on the switch that are using a different VLAN and all are working. which has nothing to do with the switch getting its management IP which would be on vlan 1. Unless you changed it to be a different vlan? [image: 1689063571250-changedit.jpg]

@scottlindner said in need to reboot when modem reboots: Yes, those are both set to All network interfaces. Not a fan of that - especially for outgoing.. The local interface is really the only interface you need to use for outgoing, any traffic out the wan would be natted to your wan IP, or vpn IP, etc. The only time you would need to select another interface - if you were doing say forwarding to some lan side dns. You could make a case for only selecting the interface for listen as well - do you really need unbound to listen even on wan? You serving up dns off your wan interface? While its a good "default" setting because you have no idea what someones setup might need. The admin of the box should correct those settings to be best suited for their needs. All is rarely that. edit: these are my settings, it listens on the interface I might serve up dns on. And only uses localhost as its outbound interface. [image: 1689043774585-settings.jpg]

Just swapped pfSense over to 192.168.2.1 and that appears to have solved my issues. Good to know for next time!

@jaskerx how do you turn of DoH on Chrome???

@stephenw10 Your suggestion seemed very logical as it might explain the crash after the online update. I removed the line in the configuration file and I also tried changing the line to designate "video" rather than "serial". Both gave the same result. Before the changes, the boot up stopped with a blank screen with a blinking cursor. After the changes, the boot up stopped with an alphanumeric graphic of the pfSense logo and a flashing cursor. The boot did not complete. Since I am not seeing complaints from others, it looks like this is issue may be the result of a 10 year old bios in my Gigbox units. It appears that something is destroying the UEFI file when I do the configuration file restore. I'll stick with bios. It will be interesting to see what happens during the next pfSense update. Thanks for your suggestion and help.

Nice. I can only dream of those speeds.

Ok, without rebooting I went back to the Starlink interface, disabled IPv6 again, then re-enabled it again and the NTP IPv6 socket error has stopped. I can't reboot now to test if the error returns with a reboot but will try later. Seems flaky.

Well if it's not actually in bridge more I'd expect pfSense to pull a private IP on it's WAN as long as it's set to DHCP. You probably would have to power cycle to modem to be sure it isn't locked to the MAC address of whatever client you had connected there initially. Or spoof that MAC address in pfSense.

It's an upstream compatibility issue. If it gets corrected and we are able to compile it we will add back the package. The effort required to allow it is non-trivial though. Several of our developers have looked at it and concluded the task is likely beyond anything we can commit to at this point for an EoS architecture ourselves. So I really can't say when or if it might be done. Steve

I have resolve it by reseting NTopNg pkg