LAN icmp 172.16.103.2:10618 -> 208.123.73.69:10618 0:0 58 / 0 5 KiB / 0 B WAN2 icmp 192.168.1.100:57632 (172.16.103.2:10618) -> 208.123.73.69:57632 0:0 58 / 0 5 KiB / 0 BIt's like the policy routing is ignored for this kind of situation and the firewall is trying route the established traffic through the default gateway (and use the NAT for a connection to exit through another WAN).I've tried also with floating rules, without success.There's some command or log to check what decisions takes pfSense with search state or packet

It looks like your problem is whatever is upstream is refusing to accept the CARP VIP (and MAC address) moving from primary to secondary.

I can't understand why I only see this behavior when the gateway from LAN traffic to outside is different from the default gateway. If the gateway from LAN traffic to outside is the same from the default gateway, everything goes well.

Apparently I am in the same situation as Dayer. The network layout is the same.I am using 2.3.4 and I made a clean install as follows (apologize for the detailed list, but there might be an obvious mistake or missing part):- the two VMs running on the same ESXi 6.0U3 host (for testing purpose)- set up WAN1 and WAN2 in different subnet: - WAN1 public /26 (default GW) - WAN2 internal /24 (behind a cable modem)- set up WAN1 and WAN2 with following monitoring IP addresses: - WAN1: 8.8.8.8 - WAN2: 208.67.220.220- add two DNS servers to each WAN- Configure DNS resolver to forwarder mode- install Open-vm-tools package (no other packages have been installed)- Set up HA for syncing state and configs- Set up CARP IPs (WAN1-VIP, WAN2-VIP, LAN-VIP) with appropriate netmask- change Outbound NAT to Manual - remove auto-created SYNC interface related outbound NAT rules - change NAT address to WAN1-VIP on rules with interface WAN1 - change NAT address to WAN2-VIP on rules with interface WAN2- create WAN1first gateway group with WAN1GW Tier1, WAN2GW: Tier2- create WAN2first gateway group with WAN1GW Tier2, WAN2GW: Tier1- create FW rule with Policy routing for ssh traffic in LAN:

WAN2 disabled OKWAN2 GW:WAN1GW FreezesWAN2 GW:WAN2GW OKWAN2 GW:WAN1first FreezesWAN2 GW:WAN2first OKI had the same issue, that in case the policy routing rule points to a gateway (group) other than the default, then after the HA fail-over to the secondary node the opened session freezes.I can open a new ssh session via the new master, but moving the VIP back to the primary node this one freezes and the previously opened session starts responding again.I also saw in tcpdump, that when the ssh session freezes, the traffic leaves the firewall on wrong WAN interface (on the default one) with the other WAN interface's source IP address.

I've just spotted that 2.3.5 is out, so I've done a fresh install again and tried to simplify the setup as much as possible to reproduce this issue.I omitted a few irrelevant steps (DNS config, setting up GW groups, etc) from the procedure described in my previous post which resulted this:- the two VMs running on the same ESXi 6.0U3 host (for testing purpose)- set up WAN1 and WAN2 in different subnet: - WAN1 public /26 (default GW) - WAN2 internal /24 (behind a cable modem)- set up WAN1 and WAN2 with following monitoring IP addresses: - WAN1: 8.8.8.8 - WAN2: 208.67.220.220- Set up HA for syncing state and configs with relevant FW rules)- Set up CARP IPs (WAN1-VIP, WAN2-VIP, LAN-VIP) with appropriate netmask- change Outbound NAT Mode to Manual - remove auto-created SYNC interface related rules - change NAT address to WAN1-VIP on rules with interface WAN1 - change NAT address to WAN2-VIP on rules with interface WAN2 - the actual outbound NAT rules are (description removed)

WAN2 disabled OKWAN2 GW:WAN1GW FreezesWAN2 GW:WAN2GW OKI've tested with opening an ssh session to an external host.In case the FW rule directs the outgoing LAN ssh traffic via a gateway other than the default gateway, then after the HA fails over to the secondary node the open ssh session freezes.I can open a new ssh session via the new master (secondary node), but moving the VIP back to the primary node this newly opened ssh session freezes and the previously opened session starts responding again.I still see in tcpdump, that when the ssh session freezes, the traffic leaves the firewall on default GW's WAN interface with the other WAN interface's VIP address.

Actually I haven't found much related posts where HA, multi-WAN and policy based routing is involved.We might miss something obvious, but actually I haven't found much related posts/tutorials/howtos where HA, multi-WAN and policy based routing is involved.

Hi Derelict,Tanks for your reply, but I am afraid I do not understand your question.192.168.25.0/24 is my LAN subnet.I've opened the ssh session from this subnet to an external host.The quoted NAT rule supposed to do the outbound NAT on WAN2 arriving from my LAN.

Ok, let me try to describe it with the actual states after each test step.

I have a fresh CARP-HA setup with Dual-WAN connection.WAN1-CARP: 213.ss.tt.8WAN2-CARP: 192.168.0.10WANs are connected to different ISPs.Outbound NAT on both WAN interfaces: NAT with CARP IP instead of interface ip.External host with sshd: 212.xx.yy.193

11:27:42.464087 IP 192.168.0.10.42115 > 212.xx.yy.193.22: Flags [.], ack 1, win 342, options [nop,nop,TS val 2258792365 ecr 4076858258,nop,nop,sack 1 {4294967189:1}], length 0I see two problems here:1. routing is wrong: the ssh traffic should be treated according to the policy routing. 2. the outbound NAT is also wrong because the traffic leaves on WAN1 (for whatever reason) so WAN1's outbound NAT rule should be applied as you said: "It determines what NAT happens when traffic is already routed that way."If the routing were ok, that would solve the problem, but the wrong outbound NAT is also an issue and might help to determine where the wrong routing/ignoring policy routing originates.

My conclusions:It seems that the new master node does not route the failed over traffic according to the policy routing (defined in LAN FW rule), but according to the routing table.I can open a new ssh session vie the new master node and this will be routed according to the policy routing (defined in LAN FW rule), however it will freeze once this new master becomed backup again.

Are you 100% certain all of your interfaces match exactly on both nodes? Both nodes should match exactly in Status > Interfaces the interface name, the wan/lan/optX name, and the physical interface name.