When your StrongSwan IKEv2 VPN shows "connection established" but behaves like a ghost tunnel - no ping responses, no traffic flow - we're dealing with what I call "Silent Tunnel Syndrome". The logs show successful authentication but zero actual routing. Let's dissect this systematically.

May  8 09:50:02 seanco-server charon: 12[IKE] CHILD_SA windows-phone-vpn{2} established with SPIs c214680b_i a1cbebd2_o
May  8 09:50:02 seanco-server vpn: + 10.212.235.245 10.8.0.1/32 == 166.147.118.120 -- 192.168.1.110 == 0.0.0.0/0

Key observations from the logs:

• Successful EAP-MSCHAPv2 authentication
• Virtual IP 10.8.0.1 assigned to client
• Missing ESP/AH traffic indicators
• No routing table updates logged

The current /etc/ipsec.conf needs these adjustments:

# Enable proper NAT traversal
config setup
    charondebug="ike 4, knl 4, cfg 4, net 4"
    uniqueids=never
    strictcrlpolicy=no

conn windows-phone-vpn
    # Add these critical parameters
    fragmentation=yes
    forceencaps=yes
    rekey=no
    installpolicy=yes
    # Fix the problematic leftsubnet
    leftsubnet=192.168.1.0/24
    # Enable proper NAT-T
    nat-ikev1-method=none
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!

These rules make or break VPN routing:

# Basic NAT rules
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth1 -j MASQUERADE

# Allow ESP (IPSec) and IKEv2
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT
iptables -A INPUT -p esp -j ACCEPT

# Forwarding rules
iptables -A FORWARD --match policy --pol ipsec --dir in --proto esp -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD --match policy --pol ipsec --dir out --proto esp -d 10.8.0.0/24 -j ACCEPT

# Add to /etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0

Apply with sysctl -p

This diagnostic script helps identify where traffic stops:

#!/bin/bash
# Check tunnel interface
ip -s tunnel show

# Verify Security Associations
ip xfrm state
ip xfrm policy

# Route verification
ip route list table 220

# Check for ESP packets
tcpdump -n -i eth1 esp

# Verify NAT traversal
tcpdump -n -i eth1 udp port 4500

For Windows Phone clients, these registry tweaks often help:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters]
"ProhibitIpSec"=dword:00000000

When standard fixes fail, enable deep logging:

# In /etc/strongswan.d/charon-logging.conf
charon {
    syslog {
        daemon {
            default = 3
        }
    }
    filelog {
        /var/log/strongswan.log {
            time_format = %b %e %T
            default = 4
            append = no
            flush_line = yes
        }
    }
}

When examining the syslog output, we can observe that while the IKEv2 SA (Security Association) establishes successfully, there's a critical gap in traffic routing between the client (10.8.0.1) and server (192.168.1.110) networks.

The current setup shows:

Server LAN: 192.168.1.0/24
VPN Pool: 10.8.0.0/24
Client IP: 10.8.0.1
Server IP: 192.168.1.110 (NATed)

Three primary issues stand out in the ipsec.conf:

# Problematic configuration snippet:
leftsubnet = 0.0.0.0/0
rightsourceip = 10.8.0.0/24

Here's the corrected ipsec.conf configuration:

conn windows-phone-vpn
    auto = route
    compress = no
    dpdaction = clear
    pfs = no
    keyexchange = ikev2
    type = tunnel
    left = %any
    leftfirewall = yes
    leftauth = pubkey
    leftid = steakscorp.org
    leftcert = /etc/apache2/ssl/start-ssl.crt
    leftca = /etc/apache2/ssl/start-ssl-ca.pem
    leftsendcert = always
    leftsubnet = 192.168.1.0/24
    right = %any
    rightauth = eap-mschapv2
    eap_identity = %any
    rightca = /etc/ipsec.d/cacerts/vpnca.pem
    rightsendcert = ifasked
    rightsourceip = 10.8.0.0/24

Add these NAT and forwarding rules:

iptables -A FORWARD -s 10.8.0.0/24 -d 192.168.1.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth1 -j MASQUERADE
iptables -A INPUT -p udp --dport 500 -j ACCEPT
iptables -A INPUT -p udp --dport 4500 -j ACCEPT

Enable IP forwarding permanently:

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

After applying changes:

ipsec statusall
ip xfrm policy
ip route show table 220

For Windows Phone clients, ensure these registry settings:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002