VPN Tunnel Up but No Traffic: How to Fix IPsec Routing Issues

The tunnel shows established. IKE negotiation completed successfully. Phase 2 is up on both sides.

But ping fails, and nothing is getting through. This is one of the most common and frustrating VPN troubleshooting scenarios, and it almost always comes down to something outside the tunnel itself.

I’ve dealt with this pattern hundreds of times across StrongSwan, Cisco, Fortinet, Meraki, and various WireGuard setups. The tunnel being up means the cryptographic handshake worked. Traffic not passing means routing, firewall rules, NAT, or traffic selectors are broken somewhere. The tunnel establishment and the traffic flow are completely separate problems.

Check Traffic Selectors First

On IPsec tunnels, traffic selectors define what source and destination networks are allowed through the tunnel. If your traffic doesn’t match those selectors, it won’t enter the tunnel at all. It’ll either get dropped or route out your default gateway instead.

On StrongSwan, check what’s actually negotiated:

swanctl --list-sas

Look at the local-ts and remote-ts values. If you’re trying to send traffic from 192.168.1.0/24 to 10.0.0.0/24, but your traffic selectors only cover 192.168.1.0/25, half your subnet won’t use the tunnel.

A mismatch I see constantly: one side configured with 0.0.0.0/0 expecting to tunnel everything, the other side configured with specific subnets. The tunnel establishes using the narrower selector because IKEv2 allows negotiation. Your peer accepted 10.0.0.0/24 instead of 0.0.0.0/0, but you don’t realise it until traffic to 172.16.0.0/16 fails.

On Cisco ASA, check with:

show crypto ipsec sa

The “protected networks” or “access-list” values tell you exactly what traffic the tunnel will encrypt. If your interesting traffic doesn’t match, it’s not going through.

The Routing Table Isn’t Doing What You Think

A tunnel being established doesn’t automatically install routes. This depends entirely on your VPN implementation and configuration.

StrongSwan with policy-based IPsec installs kernel policies, not routes. Traffic matches the policy and gets encrypted, but ip route won’t show anything. Route-based VPNs using xfrm interfaces or VTI do install routes, and those need to actually exist.

Check both:

ip route show table all | grep -E "(10.0.0|192.168)"
ip xfrm policy

If you’re using xfrm interfaces with StrongSwan, verify the interface exists and has a route pointing to it:

ip link show xfrm0
ip route show dev xfrm0

Missing routes on route-based VPNs are the most common cause of tunnel up, traffic failing. The tunnel establishes, the xfrm interface comes up, but nobody added a route to direct traffic into it.

For WireGuard, the AllowedIPs field serves as both the traffic selector and the routing instruction. If you want to reach 10.0.0.0/24 through the tunnel, it must be in AllowedIPs:

[Peer]
PublicKey = …
Endpoint = 203.0.113.1:51820
AllowedIPs = 10.0.0.0/24

WireGuard automatically handles the routing when you bring the interface up with wg-quick or a properly configured networkd setup. If you’re managing the interface manually, you need to add routes yourself.

Firewall Rules Blocking Post-Decryption Traffic

Traffic enters the tunnel encrypted, gets decrypted at your endpoint, then has to pass through your firewall rules as normal traffic. Many people forget this second step.

On Linux with iptables, traffic coming out of an IPsec tunnel often hits the FORWARD chain if it’s destined for another host. If your default FORWARD policy is DROP, you need explicit rules:

iptables -A FORWARD -i xfrm0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o xfrm0 -j ACCEPT

For policy-based IPsec without a dedicated interface, the traffic appears to arrive on the physical interface but matches an xfrm policy. This can confuse firewall rules that filter by interface.

On pfSense and OPNsense, there’s a dedicated IPsec interface you need to add rules to. The tunnel can be established with zero rules on that interface, but traffic will be silently dropped. Add an allow rule on the IPsec interface for the expected traffic.

Fortinet has a similar gotcha. The tunnel comes up but traffic fails because there’s no firewall policy referencing the tunnel interface. You need a policy from internal to the tunnel interface and another from the tunnel interface to internal.

Asymmetric Routing and Return Path Failures

Your traffic might be entering the tunnel fine, but the response is taking a different path. This kills connectivity.

Common scenario: Host A sends traffic to Host B through the VPN. Host B receives it, but Host B’s default gateway isn’t the VPN endpoint, so the response goes out the regular internet path. The response either gets dropped by stateful firewalls or arrives from an unexpected source IP and gets rejected.

Check routing on both sides. If you’re sending traffic to 10.0.0.50 through the tunnel, 10.0.0.50 needs a route back to your source network via the tunnel endpoint.

On StrongSwan, if you’ve got install_routes = no set because you’re managing routes manually, make sure you actually did it. I’ve seen configs with that option set and then no static routes to compensate.

MTU and Fragmentation Issues

IPsec adds overhead. A 1500 byte packet becomes too large after adding ESP headers. If Path MTU Discovery isn’t working, you’ll see the tunnel up, small packets like pings succeeding, but TCP connections hanging or partially working.

ICMP ping with small packets succeeds:

ping -c 4 -s 64 10.0.0.1 # works

Ping with larger packets fails:

ping -c 4 -s 1400 10.0.0.1 # times out

The fix is lowering the MTU on the tunnel interface:

ip link set xfrm0 mtu 1400

For WireGuard, the default MTU is usually fine, but if you’re running over another tunnel or unusual network, you may need to set it explicitly:

[Interface]
MTU = 1380

On Cisco devices, crypto ipsec df-bit clear lets the router fragment packets that have Don’t Fragment set, working around broken PMTUD.

NAT Interference

NAT applied to traffic before it enters the tunnel breaks things. If your firewall is NATing traffic to the tunnel peer’s network to your WAN IP, the traffic no longer matches the tunnel’s traffic selectors.

The fix is a NAT exemption rule. On Linux with iptables:

iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -d 10.0.0.0/24 -j ACCEPT

This rule must come before any masquerade or SNAT rules. On pfSense, you need a manual outbound NAT rule with “do not NAT” for traffic between the local and remote tunnel networks.

Troubleshooting

When facing tunnel up but no traffic, work through this sequence:

Verify traffic selectors match on both sides

Confirm routes exist and point to the correct interface

Check firewall rules allow forwarded traffic

Verify NAT isn’t being applied to tunnel traffic

Test with different packet sizes to rule out MTU issues

Packet capture on both endpoints to see where traffic stops

For IPsec on Linux:

tcpdump -i any esp or udp port 500 or udp port 4500

For the decrypted traffic:

tcpdump -i xfrm0 icmp

If you see traffic entering the tunnel on one side but not exiting on the other, the problem is mid-tunnel, likely traffic selectors. If traffic exits the tunnel but responses never come back, it’s a return routing issue.

When the Tunnel Isn’t Actually Up

Sometimes what looks like an established tunnel isn’t. StrongSwan’s ipsec status showing ESTABLISHED means IKE Phase 1 is up. It doesn’t mean Phase 2 child SAs exist. Without child SAs, there’s no tunnel for traffic.

Check specifically for child SAs:

swanctl --list-sas | grep -A5 "child"

If you see no child SAs, the tunnel isn’t actually ready for traffic, even though the IKE session is established. This happens when traffic selectors can’t be agreed upon or when there’s no traffic to trigger a route-based child SA creation.

Most tunnel up, traffic failing issues are routing or firewall problems, not tunnel problems. The tunnel is doing its job. Everything around it needs to be configured to actually use it.

For a simpler home VPN that avoids manual routing and traffic selector issues like this, compare Tailscale vs WireGuard.