Just managed to fix the issue. It was not related to the floating states thingy. They are all at default. Under VPN -> IPsec -> Advanced settings, change "IPsec Filter Mode" to "On Assigned Interfaces" This gives you a Firewall rules tab per (ipsec) interface, instead of the general "IPsec" firewall rules tab. Now create rules on those tabs to allow traffic.

At times t-mobile drops icmp with length less than 4. A temp fix is to edit /etc/inc/gwlb.inc and change the default from 1 byte to 4.

@SteveITS Thank you very much, this was the nudge I needed! I have non VPN hosts on various VLAN interfaces so I created this Floating firewall rule with an Invert match to alias: RFC1918 and it appears to have resolved the issue. Action: Pass Apply the action immediately on match: Check Interface: Any Direction: In Address Family: IPv4 Protocol: Any Gateway: ATT Defaults for the other settings Is this acceptable or should I have went about this differently? [image: 1760906785264-fc103cab-f97f-4140-a920-11e1d659cb57-image-resized.png]

@SteveITS I should have added that step. Disabling the action allows the service to keep monitoring without causing a catastrophic failure.

Also, there are 3 IPSEC tunnels on the WAN interface. [image: 1760391120631-tls_pfsense_ipsec_251013.png]

Surely with Dual-WAN you need to use a Gateway-Group ?

@helento1 said in Unstable ipv6: This would happen ip pfsense could disable ipv6 gw automatically. So : as said above : use (change) the advanced settings so that the slightest interval (big transit delay) and or smaller packet loss will trigger a IPv6 interface dpinger action (reset interface). Btw : this is a temporary solution of course. Get a more serious ISP - or stop using IP6 al together for the moment and wait until they have sorted things out. Most ISPs on planet earth did strange things with IPv6 when they start using it. This seems to be 'normal'. Get Starlink ?

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