Simplifying this question, as I think it must be simple. Netgate 6100. Connected to Juniper router on WAN2. Juniper router port is a trunk port for VLAN. VLAN port is assigned 10.1.71.4. Physical port is WAN2. Attempting to tracert from a LAN address to the VLAN address works: Tracing route to 10.1.71.4 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 10.1.71.4 Trace complete. But trying to get to another address in that subnet, through the VLAN port, does not: Tracing route to 10.1.71.1 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms LLL-GATEWAY.lll.lll.lll.org [10.0.0.196] 2 * * * Request timed out. The VLAN port itself can ping 10.1.71.1, so it is not a matter of firewalls at the far end. I have a rule on the VLAN port to allow any traffic from anywhere and of any type. So, do these routes look correct? I will include them all, just in case there is another issue. 10.0.0.196 link#10 UHS 10 16384 lo0 10.1.71.0/29 link#14 U 1 1500 ix2.71 10.1.71.4 link#10 UHS 6 16384 lo0 123.456.789.160/27 link#8 U 7 1500 ix3 123.456.789.162 link#10 UHS 8 16384 lo0 123.456.789.163 link#10 UHS 8 16384 lo0 123.456.789.172 link#10 UHS 8 16384 lo0 123.456.789.179 link#10 UHS 8 16384 lo0 123.456.789.185 link#10 UHS 8 16384 lo0 127.0.0.1 link#10 UH 5 16384 lo0 172.16.0.0/24 link#3 U 13 1500 igc2 172.16.0.1 link#10 UHS 14 16384 lo0 172.16.222.0 link#10 UHS 18 16384 lo0 172.16.222.0/31 link#13 U 17 1420 tun_wg0 172.19.71.0/24 link#4 U 15 1500 igc3 172.19.71.1 link#10 UHS 16 16384 lo0 192.168.2.0/24 172.16.0.2 UGS 3 1500 igc2 192.168.44.0/24 10.1.71.1 UGS 4 1500 ix2.71 192.168.68.0/22 link#2 U 11 1500 igc1 192.168.68.10 link#10 UHS 12 16384 lo0 192.168.125.0/24 172.16.222.1 UGS 19 1420 tun_wg0 Thanks!

@entrio Yeah you’re right, pfSense already keeps states by default. When you set “State type: Keep”, it already behaves like the “established, related” match in iptables, so you don’t have to configure that manually. If you want to stop new inbound connections from scans but still allow replies for your outbound traffic, you can do it with two floating rules. Make one at the top that passes traffic, check Quick, apply it to your WAN (or Any if you’ve got multiple), set the direction to In, and leave State type as Keep. That one keeps your existing connections working. Then right below it, add another floating rule that blocks everything else. Also mark it Quick and set State type to None. This setup lets return traffic from your sessions pass normally but drops any random inbound scans hitting your /24.

@manusch Awesome!

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?