Site-to-Site VPN: Which Direction Actually Needs a Rule?

Both ends report an established tunnel, the far branch answers from the gateway, and the application still times out for users on one side. The usual advice says to add a firewall rule in both directions. Sometimes that is right, sometimes it duplicates a rule that already exists, and sometimes the second rule is what breaks the state. Which case applies depends on where the firewall sees the packet.

Stateful Return Traffic Changes the Count

A stateful firewall records the request and admits the reply without a second rule, so a design that needs only one rule is normal. A stateless access list has no such memory, and the reply must be permitted explicitly. Both are correct on their own platform, which is why the advice conflicts.

Read the forwarding documentation for the platform in front of you, and check whether the policy you are editing is stateful where it sees the packet. An explicit deny for established traffic, or a rule order that evaluates the reply before the state table, turns a working design into a puzzling one. The count of rules is an implementation detail, while the requirement is that both directions of a permitted conversation can complete.

Where the Firewall Sees Decrypted Packets

In a policy-based tunnel, the firewall may evaluate the encrypted packet before decryption and the decrypted packet afterwards, on different interfaces. A rule written for the wrong one is present, correct and never matched. That is how a rule set copied from a working deployment can fail on identical hardware.

Route-based IPsec and most modern implementations present a tunnel interface, so the decrypted packet arrives there and ordinary interface rules apply. Confirm which model the deployment uses before copying a rule set from a guide written for the other one. The tunnel interface is also the place to look when you need to know whether a packet was decrypted at all.

Asymmetric Routing Breaks the Assumption

A stateful firewall assumes it sees both halves of the conversation. If the reply returns through a different gateway, that device holds no state for the request and drops it according to its own policy. The symptom is a one-way failure that no rule on the sending side can repair. Trace the reply path before editing anything.

Check the reply route before adding a broad allow rule on both sides. Tolerating everything on every interface hides the routing mistake and widens access at the same time, which is the worst combination available.

Check Both Directions With Real Source Addresses

Test with the address the far side actually observes, since translation can make a source rule match nothing at all. Run the capture on both gateways at the same time.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

A request that appears on the far gateway with an unexpected source address explains a rule that never matches, and a reply arriving on the wrong interface explains a state mismatch. Then test one destination inside the approved scope and one outside it, so the boundary is demonstrated rather than assumed.

Record the source address after translation, the interface the decrypted packet used, and the rule that matched. Those three facts answer the next ticket without repeating the whole investigation.