Week 5 Day 2 — NETW-0014

0:00–0:10
Recap

0:10–1:50
Lab 5B

1:50–2:00
Debrief

0:00 – 0:10Recap · 10 min

Critical check before starting: from S1, ping S3's external IP. From S3, ping S1's external IP. Both must succeed. Anyone without this — address it now. The VPN cannot establish without L3 connectivity between endpoints.
Ask: "What does ipsec.secrets contain, and what does ipsec.conf contain?" — secrets contains the authentication credential (PSK or private key reference). conf contains the connection profile (endpoints, subnets, cipher suites, timers).

0:10 – 1:50Lab 5B · 100 min

Lab 5B — Install StrongSwan, configure PSK VPN, verify SA and encrypted traffic

Part 1 — Install StrongSwan on S1 and S3 (10 min)

On both S1 and S3: sudo apt install strongswan. Verify the service is installed: sudo ipsec version. The key packages installed alongside: libstrongswan, strongswan-charon (the IKE daemon), strongswan-starter.

Part 2 — Configure ipsec.secrets (15 min)

On S1, edit /etc/ipsec.secrets. Add one line (replace IPs with actual external IPs):
[S1-External-IP] [S3-External-IP] : PSK "Room225!"
On S3, add the reverse:
[S3-External-IP] [S1-External-IP] : PSK "Room225!"
The format: left-peer right-peer : PSK "key". The PSK must be identical on both sides — a mismatch is a silent authentication failure.

Part 3 — Configure ipsec.conf (25 min)

On S1, edit /etc/ipsec.conf. Add a connection definition after the config setup section:
conn S1_to_S3
authby=secret
left=[S1-External-IP]
leftsubnet=192.168.50.0/24
right=[S3-External-IP]
rightsubnet=192.168.51.0/24
ike=aes256-sha2_256-modp1024!
esp=aes256-sha2_256!
keyingtries=0
ikelifetime=1h
lifetime=8h
dpddelay=30
dpdtimeout=120
dpdaction=restart
auto=start
On S3, write the mirror configuration — left and right are swapped:
conn S3_to_S1
authby=secret
left=[S3-External-IP]
leftsubnet=192.168.51.0/24
right=[S1-External-IP]
rightsubnet=192.168.50.0/24
... (same IKE/ESP/timing settings)

Part 4 — NAT exclusion rule (15 min)

The existing MASQUERADE rule on S1 must be replaced with one that excludes traffic destined for S3's subnet. Remove the existing rule and add the modified version:
sudo iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -t nat -A POSTROUTING -s 192.168.50.0/24 ! -d 192.168.51.0/24 -o eth0 -j MASQUERADE
This says: masquerade traffic from LAN1, EXCEPT when the destination is S3's LAN. VPN-bound traffic keeps its original source IP.
Apply the same logic on S3 for its own MASQUERADE rule (exclude traffic destined for S1's LAN). Save with iptables-persistent.
Verify internet access from S2 still works after the rule change: ping 8.8.8.8 from S2 — should succeed (internet traffic is still masqueraded; only S3's LAN is excluded).

Part 5 — Start ipsec and verify (25 min)

On both S1 and S3, restart ipsec:
sudo ipsec restart
Wait 30 seconds, then check the SA:
sudo ipsec status
A successful tunnel shows: Security Associations (1 up, 0 connecting) followed by the SA details including the cipher suite and subnet selectors.
If no SAs appear — check /var/log/syslog for IKE negotiation errors. Common issues: PSK mismatch (check both sides are identical), firewall blocking UDP 500, IP mismatch in ipsec.conf vs actual interface IP.
Test connectivity: from S2, ping S3's LAN IP:
ping 192.168.51.2 (or whatever S3's LAN address is)
This should now succeed. Traffic flows: S2 → S1 → encrypted through tunnel → S3 → S3's LAN.
Verify encryption with tcpdump on S1's external interface while pinging:
sudo tcpdump -i eth0 -n esp
You should see ESP packets between S1 and S3's external IPs. The payload is opaque (encrypted) — only the outer IP headers are visible.

Lab 5B complete when: ipsec status shows 1 SA up. Ping from S2 reaches S3's LAN IP. tcpdump on eth0 shows ESP packets during the ping. Internet access from S2 still works (NAT exclusion working correctly).

1:50 – 2:00Debrief · 10 min

Walk through ipsec status output together. Identify: connection name, IKE version, cipher suite, uptime, bytes transferred, subnet selectors. Ask: "What would ipsec status show if the tunnel dropped and was re-negotiating?" — "0 up, 1 connecting."
Ask: "What's the security problem with this PSK?" — both sides share the same secret. If S3 is compromised, the attacker knows the PSK and can impersonate S1. PKI certificates solve this: each side has its own private key that never leaves the machine. Preview Wednesday.

Learning outcomes — by end of Day 2, students can…

Configure a StrongSwan PSK tunnelWrite ipsec.secrets and ipsec.conf on both endpoints with correct left/right configuration

Apply the NAT exclusion ruleWrite an iptables rule that masquerades internet traffic but not VPN-bound traffic

Verify a VPN SA with ipsec statusInterpret the status output and identify a healthy vs failed SA

Confirm encrypted traffic with tcpdumpCapture ESP packets on the external interface and explain what the encrypted payload means

Common issues and fixes

Issue	Likely cause	Fix
ipsec status shows 0 SAs after restart	PSK mismatch, wrong IPs in ipsec.conf, or firewall blocking UDP 500	Check syslog: sudo grep charon /var/log/syslog \| tail -30. Common messages: "no proposal chosen" (cipher mismatch), "authentication failed" (PSK wrong), "peer not responding" (firewall/connectivity)
S2 cannot ping S3's LAN even with SA up	NAT exclusion rule not applied, or applied on wrong interface	Check: sudo iptables -t nat -L POSTROUTING -n. The rule must show ! -d 192.168.51.0/24. Also verify S3 has the matching exclusion for its MASQUERADE rule
S2 loses internet access after NAT exclusion rule	Exclusion rule syntax error — may be excluding all traffic	Check: from S2, ping 8.8.8.8. If failing, verify the ! -d syntax is correct. The ! must precede -d, not -s

← Day 1 Lab 5B Handout Day 3 →