Troubleshooting StrongSwan IPsec VPN: Tunnel Established But Traffic Not Routing Properly


12 views

From the provided configuration, we have a site-to-site VPN between:

  • Local endpoint (XX.XX.XX.195) with subnet 192.168.100.0/24
  • Remote Cisco ASA (YY.YYY.YYY.155) with subnet 172.30.20.0/27

The tunnel establishes successfully but traffic fails to pass through. Let's examine the key components.

# Check tunnel status
ipsec status
# View security associations
ip xfrm state
# Examine policy rules
ip xfrm policy

The output shows proper ESP SAs established in tunnel mode. However, the zero byte counters indicate no traffic is flowing.

Key observations from the routing table:

# Current routing table
ip route show
# Specific table 220 (empty in this case)
ip route show table 220

Missing elements:

  • No route for 172.30.20.0/27 pointing to the tunnel
  • No policy-based routing entries

The iptables rules show potential gaps:

# Current NAT rules
iptables -t nat -L
# Filter rules
iptables -L

Notable findings:

  • Missing MASQUERADE rule for VPN traffic
  • Restrictive FORWARD chain policies

Step 1: Add proper routing

# Add route for remote subnet
ip route add 172.30.20.0/27 dev eth0

Step 2: Correct firewall rules

# Enable forwarding
iptables -P FORWARD ACCEPT
# Allow VPN traffic
iptables -A FORWARD -s 192.168.100.0/24 -d 172.30.20.0/27 -j ACCEPT
iptables -A FORWARD -s 172.30.20.0/27 -d 192.168.100.0/24 -j ACCEPT
# Add NAT if needed
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -d 172.30.20.0/27 -j MASQUERADE

Step 3: Verify packet flow

# On local server
tcpdump -i eth0 host YY.YYY.YYY.155
# On remote endpoint
tcpdump -i outside host XX.XX.XX.195

For more complex scenarios, consider:

# StrongSwan connection options
conn net-net
    ...
    # Enable dead peer detection
    dpdaction=restart
    dpddelay=30s
    dpdtimeout=150s
    # Force tunnel mode
    type=tunnel

Additionally, enable more verbose logging:

# In ipsec.conf
config setup
    charondebug="cfg 2, ike 2, net 2"
  1. Confirm tunnel status shows traffic counters increasing
  2. Verify packets appear in tcpdump outputs
  3. Check syslog for any dropped packets
  4. Test connectivity from both endpoints

The tunnel shows as established in ipsec status and XFRM policies appear correct, yet ICMP packets from 192.168.100.100 to 172.30.20.9 get dropped. This suggests either:

  • Encapsulated packets aren't reaching the ASA
  • Return traffic isn't being properly decrypted
  • Routing tables aren't synchronized between endpoints
# Verify phase 1 and 2 SAs
ipsec statusall

# Check XFRM state (should show bidirectional ESP SAs)
ip xfrm state

# Verify policy matching (critical for routing decisions)
ip xfrm policy

# Real-time packet capture on both tunnel endpoints
tcpdump -nni eth0 host YY.YYY.YYY.155 and proto esp
tcpdump -nni virbr1 net 172.30.20.0/27

With Cisco ASA endpoints, these specific issues often occur:

# Missing NAT-T configuration (critical for Cisco compatibility)
conn net-net
    ...
    forceencaps=yes    # Required when behind NAT
    nat-ikev1=yes      # Cisco ASA compatibility
    rekey=no           # ASA sometimes struggles with rekeying

The expected encapsulation should show:

  1. Original packet: 192.168.100.100 → 172.30.20.9 (ICMP)
  2. ESP encapsulation: XX.XX.XX.195 → YY.YYY.YYY.155 (UDP/4500)
  3. ASA should decrypt and route to 172.30.20.9

Current iptables rules need modification:

# Allow encapsulated ESP traffic
iptables -A INPUT -p esp -j ACCEPT

# Permit UDP/500 and UDP/4500 for IKE and NAT-T
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT

# Explicit MASQUERADE for VPN traffic
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -d 172.30.20.0/27 -j SNAT --to-source XX.XX.XX.195

After making changes, verify with:

# Check if packets leave the tunnel endpoint
tcpdump -nni eth0 "host YY.YYY.YYY.155 and (udp port 500 or udp port 4500 or proto esp)"

# Verify reverse path
tcpdump -nni virbr1 "icmp and host 172.30.20.9"

On the Cisco side, ensure these elements exist:

access-list outside_cryptomap extended permit ip 172.30.20.0 255.255.255.224 192.168.100.0 255.255.255.0
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto map outside_map 1 match address outside_cryptomap
crypto map outside_map 1 set pfs group2
crypto map outside_map 1 set peer XX.XX.XX.195
crypto map outside_map 1 set transform-set ESP-AES-256-SHA

The absence of routes in table 220 suggests missing policy-based routing:

# Add explicit route for VPN traffic
ip route add 172.30.20.0/27 dev eth0 table 220
ip rule add from 192.168.100.0/24 table 220