@tman222 Thank you very much. I bumped it to 56 and now it is back to normal. [image: 1759407183081-b5cad2db-25e8-4f21-a1be-ca5d29cfd73f-image.png] Thank you.

@w0w said in pfSense+ MultiWAN False reporting of Monitor IP down: @KB8DOA Has this configuration ever worked properly at all? And what was done that made it stop working? It works sometimes, then all the sudden stops working. I have just tried increasing the "weight" to 4, per @tman222 suggestion. I hope this resolves it...

Thank you @viragomann for the reply. I'll test this fully on school break. My quick test on setting this to our VLANs (replace "Internal" with VLANs) resulted in no internet. But I'll check also with the other posts on port forwarding. Thank you again for your help with this and the "Skip rules when gateway is down"

@meray to recap: on A you got routes to BNet and VNet using wgB as gatway on B you got a route to VSub using wgB as gateway on B you got a route to ANet using wgA as gateway wgA, wgB and wgC have route/access to VNet wgB and wgC have also route/access to VSub (a subset of VNet) for wgA, peer B you set AllowedIPs to BNet, wgB and VNet (but not wgC?) Questions: are the Wireguard endpoints assigned as interfaces in pfSense? are you doing NAT on Wireguard traffic? is C -> B -> A working and only A -> B -> C not? wgA has direct connection to VNet, why set the gateway to wgB? is there a route to wgC on A? what firewall rules have you set up for Wireguard?

@SteveITS Yes, same ISP hardware. That is probably a worsening factor. Had it been two separate connection types or ISPs, I don't think it would mind identical DUID (but not entirely sure there) I tried the NPt and two "fake" interfaces that just monitored the prefix; but that did not work as again the other WAN is never going to be assigned anything by the ISP (again, not sure but it's my theory). I have too considered it to be a limitation way down deep, as OPNsense has the exact same problem. The static IPv6 stuff in the manual I did read, and it would work as no DUID is being used to negotiate a static IPv6. I don't believe many people have static IPv6 addresses though. But that makes me think Netgate knows of this issue already, and either it will never work, or just not a priority feature. Thanks for your input and thoughts, I really appreciate it. At least people who run into the same behavior will hopefully find this thread, and not spend 40-60 hours troubleshooting with different router software and what not, as I have :)

@feisal simple policy route https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html

@SteveITS .253 is Cisco Router, physical interface.

@keyser said in Order of routing: There is a MUCH simpler solution - simply bypass (exclude) that IP from the IPsec policy based route. Wow. Didn't know this as well. Thx.

@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

@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 :(