StrongSwan VPN Verification Guide

This document helps verify the successful setup of a site-to-site IPsec VPN tunnel using StrongSwan. The environment is provisioned with Terraform and initialized with cloud-init. The VPN configuration uses IKEv2 with a pre-shared key (PSK) and automatically starts during system boot.

Network Overview

The VPN connects a cloud network with an on-premises network, enabling secure, encrypted traffic between them.

Host	IP Address	Subnet	Role
appliance01	10.1.1.10	10.1.1.0/24	Cloud VPN Appliance
machine01cloud01	10.1.1.11	10.1.1.0/24	Cloud Internal Machine
machine01cloud02	10.2.1.11	10.2.1.0/24	Cloud Internal Machine
appliance02	192.168.1.10	192.168.1.0/24	On-Prem VPN Appliance

Architecture

This diagram illustrates the VPN tunnel between appliance01 (cloud) and appliance02 (on-prem), supporting encrypted traffic between the routed subnets.

1. Verify StrongSwan Service

To confirm the IPsec service is running and properly configured, SSH into each VPN appliance using the appropriate public IP address:

ssh -i ~/.ssh/id_rsa debian@<appliance-public-ip>

Then run:

sudo ipsec statusall

Sample expected output:

Status of IKE charon daemon (strongSwan 5.x.x, Linux x.x.x):
  uptime: ...
  worker threads: ...
Connections:
     net-net:  10.1.1.10...192.168.1.10  IKEv2, dpddelay=30s
     net-net:    local:  [10.1.1.10] uses pre-shared key authentication
     net-net:    remote: [192.168.1.10] uses pre-shared key authentication
     net-net:    child:  10.1.0.0/16 === 192.168.1.0/24 TUNNEL
Security Associations (SAs):
     net-net[1]: ESTABLISHED ...

What to check:

The connection is listed as ESTABLISHED
Subnets listed under the child SA should match your intended VPN traffic (e.g., 10.1.0.0/16 === 192.168.1.0/24)

2. Verify VPN Network Connectivity

Ping between hosts to validate that routing is working through the VPN tunnel:

💻 From appliance01 (cloud) to appliance02 (on-prem)

ping 192.168.1.10
# ✅ Successful ping confirms VPN tunnel works

💻 From appliance02 (on-prem) to appliance01 (cloud)

ping 10.1.1.10
# ✅ Confirms bidirectional connectivity

💻 From machine01 (cloud internal) to appliance02 (on-prem)

ping 192.168.1.10
# ✅ Tests routing through VPN appliance (appliance01)

💻 From appliance02 (on-prem) to machine01 (cloud internal)

ping 10.1.1.11
# ✅ Tests project-project routing via SNA transfer network

💻 From appliance02 (on-prem) to machine02 (cloud internal)

ping 10.1.2.11
# ✅ Tests project-project routing via SNA transfer network

❌ From machine01 (cloud) to appliance02 (VPN-disconnected)

If you remove the static route that directs 192.168.1.0/24 through appliance01:

ping 192.168.1.10
# ❌ Should fail, indicating that VPN appliance is required for routing

All success cases confirm correct tunnel and routing setup. Failures (when expected) validate routing dependency on the VPN stack.

3.3 KiB Raw Blame History