A StrongSwan to WatchGuard VPN connection that establishes but passes no traffic is typically caused by misconfigured IPsec policies, incorrect routing tables, or blocked NAT traversal. Verify that the leftsubnet and rightsubnet match your actual network ranges, ensure the WatchGuard firewall allows ESP (protocol 50) and UDP 4500/500, and confirm that Linux routing rules direct encrypted packets through the correct interface. This article details the diagnostic steps to restore connectivity.
Verifying IKE Phase 1 and Phase 2 Negotiation
The first step in troubleshooting is confirming that the Security Associations (SAs) are actually established. A connection state of INSTALLED indicates that both peers have agreed on encryption parameters, but it does not guarantee that data flows correctly. Use the ipsec status command on your Ubuntu server to inspect the current state of the tunnel.
sudo ipsec status
sudo ipsec statusallLook for the specific connection name defined in your strongswan.conf. If the status shows INSTALLED TUNNEL, the cryptographic handshake was successful. If it shows RUNNING but not installed, the negotiation failed during Phase 2. Common reasons include mismatched proposal algorithms (e.g., one side requires AES-GCM while the other only supports AES-CBC) or expired lifetime values. Ensure that the keyexchange=ikev2 directive is used consistently if you are using IKEv2, as WatchGuard appliances sometimes default to IKEv1 for legacy compatibility.
Checking Subnet Definitions and Policies
Most "no traffic" issues stem from incorrect subnet definitions in the connections section of your configuration. The leftsubnet represents the local network behind your Ubuntu machine, and rightsubnet represents the remote network behind the WatchGuard firewall. If these do not match the actual CIDR notation of your networks, the IPsec daemon will drop packets because they fall outside the policy scope.
Review your /etc/ipsec.conf file carefully. For example:
conn watchguard-vpn
type=tunnel
left=your_public_ip
leftsubnet=192.168.1.0/24
right=watchguard_public_ip
rightsubnet=10.0.0.0/24
...If you are connecting to a specific host rather than an entire subnet, ensure rightsubnethostonly=yes is set if applicable. Conversely, if you are trying to route all traffic, verify that rightsubnet=0.0.0.0/0 is configured correctly, though this is rarely recommended for corporate firewalls due to security policies. Mismatches here are the most frequent cause of silent packet drops after tunnel establishment.
Validating Routing Tables and Forwarding
Even with a perfect IPsec tunnel, traffic will not flow if the Linux kernel does not know how to route packets into the tunnel interface. Check your routing table using ip route show. You should see entries that direct traffic destined for the rightsubnet through the tun0 or ppp0 interface (depending on your configuration).
ip route show
ip rule showEnsure that the fwmark or routing marks used by StrongSwan are properly handled. StrongSwan often uses policy-based routing to distinguish between tunneled and non-tunneled traffic. If you have custom routing rules, verify that they do not conflict with the automatic routes created by the updown plugin. Additionally, check that IP forwarding is enabled on your Ubuntu server by verifying net.ipv4.ip_forward=1 in /etc/sysctl.conf.
Firewall and WatchGuard Configuration
The WatchGuard firewall must explicitly allow the IPsec protocol. Unlike standard ports, IPsec uses Protocol 50 (ESP) and often UDP ports 500 (ISAKMP) and 4500 (NAT-T). Ensure that your WatchGuard policy permits incoming ESP traffic from your Ubuntu server's public IP. If you are behind a NAT device, UDP 4500 is critical for NAT Traversal (NAT-T). If NAT-T is disabled on either end, the tunnel may fail or drop traffic when crossing intermediate routers.
On the Ubuntu side, verify that UFW or iptables rules are not blocking outgoing ESP packets. While StrongSwan manages its own rules, external firewall layers can interfere. Check iptables -L -n -v to ensure packets are being accepted. If you suspect MTU issues, consider implementing PMTU discovery as described in our guide on Implement PMTU Discovery on UDP Connection for VPN Tunnel, as large packets may be silently dropped if fragmentation is blocked.
Debugging with Logs
When visual checks fail, logs provide the definitive answer. Increase the log level in /etc/strongswan.conf to debug or trace for the specific connection. Restart the service and attempt to ping a host on the remote network. Monitor the logs in real-time using journalctl -u strongswan -f. Look for errors such as no proposal chosen, which indicates algorithm mismatches, or authentication failed, which points to credential issues. If the logs show successful exchanges but no traffic, the issue is almost certainly routing or firewall related.
Frequently Asked Questions
Why does my VPN work for ping but not for web browsing?
This usually indicates a DNS resolution issue or a missing route for the gateway. Ensure that the remote DNS servers are reachable through the tunnel, or configure your system to use them via DHCP options provided by the WatchGuard. Also, verify that the default route is not overriding specific subnet routes incorrectly.
How do I enable NAT Traversal if I am behind a router?
NAT Traversal (NAT-T) encapsulates ESP packets inside UDP port 4500. In your StrongSwan configuration, ensure forceencaps=yes is set in the connection definition. On the WatchGuard side, ensure that UDP 4500 is allowed in addition to standard IPsec protocols.
What causes "no proposal chosen" errors?
This error occurs when the encryption algorithms, hash functions, or DH groups proposed by StrongSwan do not match any option accepted by the WatchGuard firewall. Align the authby, ike, and esp proposals in your config to match the supported list on the WatchGuard appliance.
Can I use split tunneling with StrongSwan and WatchGuard?
Yes, but it requires careful configuration. You must define specific rightsubnet values for the traffic you want to tunnel, leaving other traffic to use the default route. Note that WatchGuard policies must permit this fragmented traffic flow appropriately.
How do I check if IP forwarding is enabled on Ubuntu?
Run sysctl net.ipv4.ip_forward. If it returns 0, forwarding is disabled. Enable it permanently by adding net.ipv4.ip_forward=1 to /etc/sysctl.conf and running sysctl -p.