106 lines
No EOL
3.1 KiB
Markdown
106 lines
No EOL
3.1 KiB
Markdown
# 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:
|
|
|
|
```bash
|
|
ssh -i ~/.ssh/id_rsa debian@<appliance-public-ip>
|
|
```
|
|
|
|
Then run:
|
|
|
|
```bash
|
|
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)
|
|
|
|
```bash
|
|
ping 192.168.1.10
|
|
# ✅ Successful ping confirms VPN tunnel works
|
|
```
|
|
|
|
### 💻 From appliance02 (on-prem) to appliance01 (cloud)
|
|
|
|
```bash
|
|
ping 10.1.1.10
|
|
# ✅ Confirms bidirectional connectivity
|
|
```
|
|
|
|
### 💻 From machine01 (cloud internal) to appliance02 (on-prem)
|
|
|
|
```bash
|
|
ping 192.168.1.10
|
|
# ✅ Tests routing through VPN appliance (appliance01)
|
|
```
|
|
|
|
### 💻 From appliance02 (on-prem) to machine01 (cloud internal)
|
|
|
|
```bash
|
|
ping 10.1.1.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:
|
|
|
|
```bash
|
|
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. |