Which Packet Does a Dual-WAN VPN Policy Need to Match?

Requests to "route the VPN over the second uplink" describe at least two different jobs, and the policy that fixes one will not touch the other. In the first job, the encrypted transport between two endpoints moves to another WAN address. In the second, a connected user's decrypted application flow exits toward a different next hop. Both are legitimate, both use routing, and each needs a match on a packet that exists at the point where the decision is made. Work through the checks below in order, since the first one determines which packet later rules must name.

Name the Two Conversations

Picture a remote worker attached to an office gateway, opening HTTPS to an internal application server. Two independent conversations are on the wire, and they have different addresses at each end. The outer conversation runs between the two VPN endpoints: gateway address to peer address, in whatever protocol and port the deployment negotiated. The inner conversation runs from the address the client was assigned to the application server's address on port 443.

The application's destination port is not the VPN's transport port, and no amount of policy on TCP 443 will move the tunnel. Equally, a rule that redirects the peer's transport address says nothing about where that user's HTTP request goes after decryption. Write both conversations down with their real addresses before touching a rule, because most confusion in this area comes from naming one and configuring the other.

Find Where Your Policy Can Actually See the Packet

The match has to be evaluated in the chain and namespace where the packet is still in the form you described. A rule attached to LAN ingress sees the inner packet, unencrypted, before it is routed toward the tunnel. A rule applied to locally originated traffic sees packets the gateway itself generates, and it does not automatically cover traffic the gateway merely forwards. Encapsulated output is a third case again, usually handled on the interface that carries the tunnel rather than on the LAN side.

This is why the same configuration snippet behaves differently on two platforms: attachment points differ, and a vendor's policy hook may sit before or after the encryption step. Read the packet path for the specific product rather than assuming the order from another vendor's diagram.

Confirm the Transport You Negotiated

For UDP-encapsulated IPsec, RFC 3948 puts ESP inside UDP and uses a non-ESP marker to keep IKE distinguishable on the shared port. Plain ESP is an IP protocol, not a TCP or UDP port, so a firewall rule written against a port number will not match it at all. This distinction decides whether your WAN policy needs a UDP rule, a protocol rule, or both.

Negotiated values beat remembered ones. Read the association's current ports and addresses from the device instead of adding TCP 4500 or an old vendor port "just in case", which captures unrelated traffic and hides the real classification problem.

Check the Return Path Before Committing

Outbound success proves half of a design. A packet returning toward the remote-client pool is no longer visible under the client's address once encapsulation replaces it: the outer destination is the peer's transport address. If the second uplink reaches that peer through a different carrier, its translation and filtering may disagree with the first one, and the association may need to be rebuilt rather than migrated.

Network address translation state is the usual casualty of a WAN switch. Record the chosen uplink, the expected outer source address, the translation in use and the peer's reachability back to it, then keep the transport reachable without sending it into the tunnel it carries.

Verify Both Layers With Two Captures

One capture at the WAN interface and one inside the tunnel settle the question faster than any configuration diff. Run them from the gateway while an approved client performs a single request, and keep both files.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

The first capture should show the outer conversation leaving the interface you intended, with the expected source address. The second should show the inner conversation once, not duplicated, with the client address as its source and the application server as its destination. The route lookup confirms which table the router would use for that source-destination pair, which is where a policy mistake usually shows up. If either capture fails to appear, the decision point is somewhere other than the one the rule was attached to, and the fix belongs there rather than in a broader match.