IPsec VPN Tunnel Up but No Traffic: Read-Only Diagnosis

Direct answer: "Tunnel up" in a monitoring view can mean only that the IKE security association (SA) is established. Data crosses only if a child SA (CHILD_SA) exists for the exact source and destination networks, packets reach the gateway, they still match the IPsec policy after any NAT, the far gateway forwards them, and replies come back the same way. A child SA can fail on its own while the IKE SA stays up. On both gateways, read the installed child SAs, their traffic selectors and their counters, correlate the same SA and the same time window on each side, and use drop or error evidence before naming the failing layer. Do not widen selectors or turn off the firewall to test. This article covers Linux gateways running strongSwan with IKEv2.

Why it matters

A partial tunnel is harder to spot than a down tunnel. Monitoring that checks only the IKE state shows green. Some subnets work and others do not, or traffic works one way. Changes made under pressure (wider selectors, NAT rules removed, firewall rules opened) can leave the tunnel carrying more than it should, or send traffic unencrypted to the internet.

How it works

Two layers: IKE SA and child SA

IKEv2 (RFC 7296) first creates an IKE SA, then one or more child SAs that carry data. Each child SA is negotiated with traffic selectors (TSi and TSr): "TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA."

The two layers fail separately. RFC 7296: "If creating the Child SA during the IKE_AUTH exchange fails for some reason, the IKE SA is still created as usual." The notifications that do not prevent the IKE SA include NO_PROPOSAL_CHOSEN and TS_UNACCEPTABLE. So an ESP proposal mismatch or unacceptable selectors leave the IKE SA up with no child SA. An authentication failure, by contrast, means the IKE SA is not created.

Narrowing: the tunnel may carry less than you configured

The responder compares proposed selectors with its own policy. RFC 7296 sets out the outcomes: none acceptable returns TS_UNACCEPTABLE and no child SA; all acceptable needs no narrowing; otherwise it narrows to an acceptable subset, and where several subsets are acceptable but their union is not, "the responder arbitrarily chooses one of them". The RFC notes this happens "only when the initiator and responder are configured differently from one another." A child SA can be installed for 10.1.1.0/24 while you expected 10.1.0.0/16.

The policy database decides per packet

RFC 4301 defines the Security Policy Database (SPD): for each packet, DISCARD, BYPASS or PROTECT. strongSwan's route-based VPN page describes the Linux order: after regular route lookups, the kernel consults the SPD and, if the matching policy is associated with an IPsec SA, encrypts the packet. A packet must be routed toward the tunnel and match a PROTECT policy to be carried.

Two designs: policy-based and route-based (XFRM interfaces)

The NAT and firewall handling differs between the two, so identify which one the gateway uses before reading rules.

• Policy-based. strongSwan's forwarding page states that local firewall stacks generally treat packets with a matching IPsec policy the same as unprotected packets, so NAT rules also hit traffic that should be tunnelled. A source NAT or masquerade rule changes the source address and the packet no longer matches the negotiated policy. strongSwan documents an iptables exemption, placed before the NAT rules in the nat table's POSTROUTING chain, that matches packets with an IPsec policy.
• Route-based (XFRM interfaces). Policies only match traffic routed through the interface with the matching interface ID; traffic routed to an XFRM interface with no matching policies and SAs is dropped. strongSwan's route-based page warns: "Due to a limitation in the Netfilter IPsec policy match, output traffic forwarded over an XFRM interface does not match (inbound it matches, though)." Its advice is to "filter just on XFRM interface names instead of IPsec policy matches." The policy-based exemption is therefore the wrong tool for this design. The same page notes that inbound traffic fails policy checking on kernels before 5.1.

In route-based designs, wide selectors (0.0.0.0/0) are a documented pattern because routing to the interface sets the boundary; a wide selector is not a fault there by itself.

Forwarding and return routes

strongSwan's forwarding page shows the Linux forwarding settings and notes that hosts behind the gateway must route replies for the remote subnets back to the VPN gateway. If the VPN gateway is not the LAN's default gateway, ICMP redirects can send traffic to the default gateway, which "probably doesn't work and otherwise might get that traffic out unencrypted". It also names cloud source and destination address checks.

Packet size

RFC 4459 explains that encapsulation adds headers, that the tunnel can fragment or signal a lower MTU with ICMP Packet Too Big, and that in IPv4 path MTU discovery "is far from reliable", for example where firewalls drop all ICMP. It describes MSS clamping as a technique that works only for TCP. Small packets passing while larger transfers stall points to packet size.

Read-only checks

Passive reads first, on both gateways. None were run for this article.

1. SA state and counters: swanctl --list-sas. The documented output shows each IKE SA, each child SA as INSTALLED, its local and remote selectors, and in and out byte and packet counters. An IKE SA with no installed child SA points to the child SA negotiation: read the strongSwan log for NO_PROPOSAL_CHOSEN or TS_UNACCEPTABLE.
2. Kernel state: ip xfrm policy list prints policies. ip xfrm state list nokeys prints SAs without key material.
3. Selectors: installed local and remote selectors on each side must mirror each other and cover the hosts in question.
4. Design: whether the tunnel uses an XFRM interface (and its interface ID) or plain policies.
5. NAT and firewall rules: read them with your firewall backend's own list command. For a policy-based tunnel, look for an IPsec policy exemption before any SNAT or masquerade rule; for an XFRM interface, look for rules on the interface name.
6. Forwarding and routes: the gateway's forwarding settings; on a test host behind each gateway, the route to the remote subnet.

Agreed test traffic (active). Sending traffic is a test, not a read: agree it with both gateway owners and record the time window. Send known traffic between two named hosts, then read counters on both gateways for the same child SA (matching SPIs) in the same window. Treat the counters as localisation evidence, not proof:

• local out does not rise: the packet did not reach or match the policy on the sending side;
• local out rises and remote in does not: candidates include loss between gateways, a different or rekeyed SA on the far side, or drops for decryption, replay or policy; check the far side's logs and error counters before concluding;
• remote in rises with no reply: forwarding, the remote host's firewall or the far return route;
• remote out rises and local in does not: the reply is lost or not matched.

Packet-size tests (small and large packets with the don't-fragment flag) are also active tests.

Candidate causes (hypotheses to test)

Decision guidance

Every item is a change, agreed with the owner of the other gateway and recorded. None were executed for this article.

Proof after a change: the agreed traffic test in both directions for each subnet pair, then traffic continuing after a rekey.

What not to do

• Do not widen selectors in a policy-based design to make traffic flow; that can tunnel traffic you did not intend.
• Do not apply the policy-based NAT exemption to an XFRM-interface design and assume it works.
• Do not remove NAT rules wholesale or disable the gateway firewall to test.
• Do not print SA keys; use nokeys.
• Do not change one side without the other side's owner.

Limitations

• No command was run for this article. Lab validation is outstanding.
• Scope is Linux and strongSwan with IKEv2. Appliances and cloud VPN gateways use their own commands and logs; IKEv1 is not covered.
• The only firewall rule syntax in the sources is strongSwan's iptables example; nftables syntax is not covered. The Linux 2.4-era Netfilter NAT HOWTO was not used as current evidence.
• Exact MTU numbers depend on encapsulation and path and are not given.

Acceptance checklist

• [ ] Both gateways show an established IKE SA and installed child SAs for every intended subnet pair.
• [ ] Installed selectors on each side mirror the other and match the design.
• [ ] Tunnel traffic is exempt from NAT in the way that fits the design (policy exemption or interface rule).
• [ ] Return routes exist for every remote subnet.
• [ ] During an agreed test, counters for the same child SA rise on both gateways in each direction.
• [ ] Large transfers complete as well as small packets.
• [ ] Traffic continues after a rekey.

Sources

Displayed dates as shown when accessed on 30 October 2026.

• IETF, RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2). October 2014.
• IETF, RFC 4301: Security Architecture for the Internet Protocol. December 2005.
• IETF, RFC 4459: MTU and Fragmentation Issues with In-the-Network Tunneling. April 2006.
• strongSwan, Forwarding and Split-Tunneling. Not displayed in retrieved copy.
• strongSwan, Route-based VPN. Not displayed in retrieved copy.
• strongSwan, swanctl --list-sas. Not displayed in retrieved copy.
• Linux manual pages, ip-xfrm(8). HTML rendering 2026-09-09.

Related articles

• Windows firewall rules stopped working after a move: network profile switched to Public
• Static IP lost after a VM restore or NIC change: hidden adapters and interface renames

Learning notes

1. An established IKE SA does not mean data flows; a child SA can fail with NO_PROPOSAL_CHOSEN or TS_UNACCEPTABLE while the IKE SA stays up.
2. The responder can narrow selectors; read what was installed.
3. Policy-based and XFRM-interface designs need different NAT and firewall handling.
4. Counters localise a fault only when the same SA and time window are compared on both peers.
5. Small packets passing while large ones stall points to MTU or MSS.