@keyser Daaaaang! Would 'up' that twice if I could, lol. Please say you hadn't yet seen this setting, OP!

@conover said in dpinger does not fallback automatically when interface is availabe again: Some time ago (must be with the release 24.11, currently running 25.07.1) dpinger stops to recover automatically an interface when the monitored IP is available again. When dpinger stops receiving replies to the ping requests, it will : Stop itself. And just before doing so, it will take the interface down. This interface is typically a WAN type interface. Just for the fun : restart reading my reply again - with one new info in your head : what happens if the dpinger ping destination stops replies to ping ? For example : half the planet is using 8.8.8.8 as a ping destination. What will happen when 8.8.8.8 stops answering to ping ? Right : half the planet will get disconnected from the internet. And only because 8.8.8.8 stopped answering to ping. Seems pretty broken, right ? The thing is : there is no good way to determine if a connection is 'working'. A real thing is : you should chose your ping destination. By default this is the upstream gateway, which could be your own ISP box, sitting right next to pfSense. Not a good choice then. Another "ISP" gateway, more upstream, might not even reply to ping .... (as : why should they ?) So, yeah, if dpinger pings an IP, and if that IP stops replying, then that interface will be 'useless' (take down), - the interface then will be taken UP again, dpinger start .... and will fail again, etc. If your ISP is 'good enough' you could consider stopping the dpinger 'action' : [image: 1758119958373-060998db-379c-4b84-a0c7-27628b5ce241-image.png] or even stop the using dpinger all together - you will lose the stats of course, and the link will be considered as "always up". @conover said in dpinger does not fallback automatically when interface is availabe again: After manually restarting the dpinger service the (as failed/offline marked) interface is immediately available again. This is normally done automatically. dpinger will send an interface 'DOWN' even. Moments later, the electrical link chip that deals with the physical connection of the RJ45 cable will sync up with the NIC on the other side of the cable, and the link will auto create an interface "UP" event. You can see this with your own eyes : the led, the state indicator, next to the RJ45 plug will light up, on both sides of the connenction. This will start the DHCP client, PPPOE driver, or static setup or whatever you use for your connection. dpinger will also get launched.

@pwood999 Hi pwood999 and Gertjan This happens with various service providers and I have changed ping targets. It also happens on various installs in different cities. I have installs in 5 different locations on 9 servers. I also know about the tweaks and the other things you mentioned Gertjan and used them heavily with marginal DSL connections. It happens very infrequently so it is difficult to know how to handle something that works 99% of the time. By the way, 8 of my WAN connections are statics. This is something to think about. I was about to make the 9th static as well, but maybe I will wait. Statics are especially useful with HA. The current DHCP unit is the only one that is not HA. I will be watching 2.8.1. Thanks so much for your suggestions. Roy

Still running into this. No solution yet? :(

@daltonch Did you ever find a solution for this? I had the exact same thing happen to me - I remove ATT from my failover group and then disabled it, which fixed it but I'm totally with you, I would think pfSense would be able to handle this... Thanks, B.

foranalyze2.anonymized.txt

@tman222 Yeah I don’t know that is possible. With IPv4 NAT the PCs have one IP. With IPv6 they’d need one from each interface. So maybe https://docs.netgate.com/pfsense/en/latest/network/ipv6/nat.html but then the device would need to not use it since it wouldn’t work normally. And generally it’s the preferred protocol.

Found why: my son swapped the 2 cables :(

Hi, sorry for reactivating an old topic. I would like to know if the status is still the same on this issue. It seems absurd to me that we would need to make things so much more complex to simply tell the firewall "if the gateway from the first VTI IPSec is down, use the second VTI IPSec". I am not sure if the implementation is too much of a hassle, but this feature would be greatly appreciated.

@DaHai8 It seems like an odd piece of hardware or at least how they've had it set up. Usually we set up a mesh as well and then roaming isn't a problem. We have I think one home user with an extender and IIRC that's the one where it sets up a different SSID then connects to the main SSID also, to relay the packets. But then one needs to switch between then. FWIW eero can be set up in "bridge mode" to function only as access points. It also can enable a guest network in bridge mode, if desired.

Its both fixed in 2.8.1 beta and 25.07-1 plus release (as expected)

Finally got the new fiber circuit installed. Everything works normally as expected now. It was some voodoo in the Comcast Coax Cable Modem that was blocking return traffic.

Traceroute from the outside world: vpsuser@test:~$ sudo traceroute -I a.b.c.164 traceroute to a.b.c.164 (a.b.c.164), 30 hops max, 60 byte packets 1 daniel.domesticagriculture.org.uk (103.144.176.193) 0.518 ms 0.470 ms 0.457 ms 2 wist.lyle.org (103.144.176.143) 0.479 ms * * 3 100.64.101.167 (100.64.101.167) 10.793 ms 10.781 ms * 4 * * * 5 * * * 6 * * * 7 * * * ... 100.64.101.167 is my router's WG client IP

@daltonch It is called policy based routing. https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html