Troubleshooting StrongSwan Connection to Cisco ASA 5550 but No Traffic

When a StrongSwan tunnel to a Cisco ASA 5550 establishes but passes no traffic, the issue usually stems from misconfigured ACLs, incorrect NAT exemptions, or routing loops. Verify that the ASA permits ESP and IKE traffic, ensure traffic selectors match on both ends, and check for overlapping subnets that prevent proper packet forwarding through the encrypted interface.

Verify IKE and ESP Traffic Permissions

The first step in troubleshooting is ensuring that the Cisco ASA allows the necessary protocols for the VPN handshake and data transmission. The ASA must permit UDP port 500 for IKE Phase 1 and UDP port 4500 for IKE Phase 2 with NAT traversal. Additionally, IP protocol 50 (ESP) must be allowed if NAT-T is not used. Check the access lists applied to the outside interface of the ASA. If the ACL does not explicitly permit these protocols, the connection will fail silently or hang during negotiation. Use the show access-list command to verify entries. Ensure that the source and destination IPs in the ACL match the local and remote gateway addresses defined in your StrongSwan configuration. If you are using NAT Traversal, confirm that UDP 4500 is permitted. Many fireplaces drop ESP packets if they are not encapsulated in UDP due to stateful inspection limitations or intermediate firewall restrictions.

Check Access Control Lists on the ASA

Even if the tunnel is up, traffic will not flow unless the ASA’s access control lists (ACLs) permit the encrypted payload. The ASA requires an ACL to define which traffic is "interesting" for the crypto map. This ACL specifies the local and remote networks that should be encrypted. On the StrongSwan side, verify that the leftsubnet and righsubnet settings in ipsec.conf exactly match the ACL defined on the ASA. A common mistake is defining a subnet mask that is too broad or too narrow. For example, if the ASA expects traffic from 192.168.1.0/24 to 10.0.0.0/24, the StrongSwan config must reflect this precisely. Use the show crypto map command on the ASA to see which ACL is bound to the crypto map set. Compare this ACL with the leftsubnet and righsubnet values. Mismatches here are the most frequent cause of "tunnel up, no traffic" scenarios. For more details on similar connectivity issues, see our guide on Troubleshooting Strongswan to WatchGuard Connection with No Traffic.

Ensure Proper NAT Exemption

Cisco ASAs often apply Network Address Translation (NAT) rules that can interfere with VPN traffic. If the ASA translates the source IP of the VPN traffic before it enters the tunnel, the decryption will fail because the packet headers no longer match the expected plaintext structure. You must configure NAT exemption (also known as "no nat") for traffic between the local and remote VPN subnets. In older ASA versions (pre-8.3), this was done using identity NAT or static NAT statements. In newer versions, use the nat command with the source and destination keywords to exempt specific flows. Verify that there are no dynamic NAT or PAT rules that might catch the VPN traffic. Use show nat to inspect the active NAT policies. Ensure that the rule exempting VPN traffic has a higher priority than any general outbound NAT rules.

Validate Routing Tables

After encryption, packets must be routed correctly out of the tunnel interface. On the Linux host running StrongSwan, ensure that the routing table directs traffic destined for the remote network through the virtual tunnel interface (usually stn0 or tun0). Use the ip route command to check the routing table. You should see a route for the remote subnet pointing to the tunnel device. If the route is missing, StrongSwan may not have installed it automatically. Check the StrongSwan logs for errors during peer setup. On the ASA side, verify that the ASA knows how to reach the local subnet via the tunnel interface. If the ASA uses policy-based routing, ensure the route-map correctly identifies the traffic. Static routes or dynamic routing protocols like OSPF must also be configured if the network topology requires them. If you suspect path MTU issues causing silent drops, consider implementing PMTU discovery as described in Implement PMTU Discovery on UDP Connection for VPN Tunnel.

Debugging Commands and Logs

When standard checks do not reveal the issue, enable debugging on both ends. On the ASA, use debug crypto ipsec and debug crypto isakmp to see detailed exchange messages. Filter the output to reduce noise by specifying the peer IP address. On the Linux host, increase the logging level in strongswan.conf to all or raw. Monitor the journal logs using journalctl -u strongswan or check the syslog for IPSec-related messages. Look for error codes such as NO_PROPOSAL_CHOSEN or AUTH_FAILED. Capture packets using tcpdump on the Linux host for the tunnel interface and on the ASA outside interface. Analyze the captures to see if packets are being sent, received, or dropped. If you see ESP packets arriving at the ASA but not being decrypted, the issue is likely cryptographic mismatch. If you see IKE exchanges completing but no ESP packets, the issue is likely routing or ACL related.

Frequently Asked Questions

Why does my tunnel stay up but ping fails?

This typically indicates that the IKE negotiation succeeded, but the data plane is blocked. Check your ACLs on the ASA and the subnet definitions in StrongSwan to ensure they match perfectly. Also, verify that NAT exemption is correctly configured so that packets are not translated before encryption.

How do I check if NAT-T is enabled on Cisco ASA?

NAT-T is enabled by default on modern ASA versions when UDP 4500 is permitted. You can verify this by checking if the ASA accepts IKE payloads on port 4500. If you disable NAT-T, ensure that IP protocol 50 (ESP) is allowed through all intermediate firewalls.

What causes NO_PROPOSAL_CHOSEN errors?

This error occurs when the encryption algorithms, hash functions, or DH groups do not match between StrongSwan and the ASA. Review the ike and esp proposals in your ipsec.conf file and compare them with the crypto map settings on the ASA. Align the configurations to include at least one common suite.

Can split tunneling affect this setup?

Yes, if split tunneling is configured incorrectly, only specific traffic may be routed through the tunnel while other traffic bypasses it. Ensure that the leftsubnet in StrongSwan defines the correct range of IPs to encrypt. Unwanted traffic leaking out unencrypted can indicate a misconfigured subnet definition.

How do I reset the IKE SA on the ASA?

Use the clear crypto sa command to remove existing security associations. This forces the next connection attempt to restart the IKE negotiation process. Be cautious when running this command in production environments, as it will temporarily disrupt active VPN sessions.