Skip to main content

Test a Site-to-Site VPN Created with SleakOps

Verify that a SleakOps site-to-site VPN is working correctly by running Nmap connectivity tests from a Kubernetes pod inside the cluster.

Prerequisites​

  • A site-to-site VPN already created and configured in SleakOps
  • Lens or kubectl access to the target cluster

Step 1 — Create a Test Pod​

Using Lens or kubectl, create the following pod in the relevant namespace:

apiVersion: v1
kind: Pod
metadata:
  name: vpn-test
  namespace: <your-namespace>
spec:
  containers:
  - name: tools
    image: nicolaka/netshoot:latest
    command: ["sleep", "3600"]

Apply it:

kubectl apply -f vpn-test-pod.yaml

Step 2 — Access the Pod Shell​

Open a shell inside the pod via Lens (right-click → Shell) or:

kubectl exec -it vpn-test -n <your-namespace> -- bash

Step 3 — Run Nmap Tests​

You need:

  • NAT_IP: IP of the NAT instance (e.g., 10.100.0.10)
  • REMOTE_IP: IP of the remote server on the other side of the VPN (e.g., 192.168.0.100)
  • PORT: Port to test (e.g., 443)
NAT_IP="10.100.0.10"
REMOTE_IP="192.168.0.100"
PORT="443"
nmap -p $PORT $REMOTE_IP

Expected result:

PORT    STATE SERVICE
443/tcp open  https

If the state is filtered or closed, check the VPN tunnel status and the firewall on the remote side.

Step 4 — Clean Up​

Once connectivity is confirmed, delete the test pod:

kubectl delete pod vpn-test -n <your-namespace>

Packet Flow Reference​

The following diagram shows how packets travel through the VPN:

Client request → Route to NAT via Peering → NAT Instance (IP forwarding)
→ MASQUERADE → VPN Gateway → IPSec tunnel → Customer Gateway
→ Decrypt → Firewall check → Remote server

Key failure points to check at each step:

  1. No route to remote subnet — Check VPC route tables
  2. IP forwarding disabled on NAT instance — Enable via sysctl net.ipv4.ip_forward=1
  3. VPN tunnel DOWN — Check VPN connection status in AWS Console
  4. Remote firewall blocking — Verify security group / firewall rules on the remote side