# 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.1.2.11    | 10.1.2.0/24    | Cloud Internal Machine |
| appliance02      | 192.168.1.10 | 192.168.1.0/24 | On-Prem VPN Appliance  |

---

## Architecture

![Architecture Diagram](docs/network-architecture.png)

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 appliance02 (on-prem) to machine02 (cloud internal)

```bash
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:

```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.