My problem is, when tier1 WAN is down, when all interfaces which are set "Default" as gateway has no internet connection. If I set that value the one "Tier 2" internet connection works how its supposed to be.

@Gertjan sorry... but why want you switch from ipv6 to ipv4 gateway and vice versa in case any of them occur packet loss? Those are two totaly different protocols and it does not make sense at all to use ipv4 to ipv6 failover whatsoever.....

@Mission-Ghost Glad to see it's helping with other issues too. I have no clue why they do the things that they do, it makes no sense to me either, but for the low cost of their backup internet service, I'm happy to have the redundancy. They've been doing a lot of new construction in my area, and my main connection has been having more trouble than ever.

Another way to check outside connectivity: With the 5G modem connected to pfSense, if you go to Diagnostics / Ping and select WAN2 as source address, are you able to reach (ping) outside websites? If you are able to ping websites, but the Gateway is still showing as offline (when you are using an outside monitoring IP such as 8.8.4.4), you may need to adjust the Data Payload parameter for dpinger from the default 1 to a larger value in the WAN2 gateway's advanced settings under System / Routing / Gateways. https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html#advanced-gateway-settings Hope this helps.

Ah, good to know! Sure would be nice not to need it though....

@beanboy said in routing internal traffic to specific gateway: If I use 'self' for source I'm not familiar with squid. Maybe you can bind it to a certain IP. In any case you have to add an outbound NAT rule to the VPN gatway for the source IP. "firewall self" directs any traffic from pfSense itself to the stated gatway, so DNS as well. And this would also need an outbound NAT rule. It you're not able to bind squid to a certain IP, add an outbound NAT rule for the source 127.0.0.0/8.

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