All the theoretical components—SAs, SPDs, and IKE—come together in a VPN deployment. Whether you are connecting two corporate data centers or allowing a thousand remote workers to access the intranet, the architecture remains the same: creating a secure 'virtual' cable across a public medium.
In a Site-to-Site VPN, the encryption is handled by a dedicated gateway (like a Cisco router or a StrongSwan server) at each end. The individual computers on the network have no idea they are on a VPN; they just send packets to the gateway, which encrypts them and sends them to the other side. This is a 'Permanent' tunnel.
💡 Site-to-Site VPNs are almost always deployed in **Tunnel Mode** to hide the internal private IP ranges (e.g., 10.0.0.0/8) of both sites.
# StrongSwan (ipsec.conf) Site-to-Site Example
conn office-to-office
authby=pubkey
left=1.2.3.4
leftsubnet=10.1.0.0/16
right=5.6.7.8
rightsubnet=10.2.0.0/16
ike=aes256-sha256-modp2048!
esp=aes256-sha256!The `leftsubnet` and `rightsubnet` directives are the 'SPD' in action. They tell the server exactly which traffic should be routed into the tunnel and which should be bypassed.
In Remote Access, the 'Gateway' is the corporate server, but the 'Client' is a software agent installed on the user's laptop. Unlike Site-to-Site, the client la chooses when to establish the tunnel. This often requires a more complex authentication flow (like EAP or Certificates) because the client's IP is dynamic and untrusted.
⚠️ Split Tunneling vs. Full Tunneling: In a 'Full Tunnel', all user traffic (even Google.com) goes through the VPN. In 'Split Tunneling', only corporate traffic goes to the VPN. Split tunneling is faster but allows the user's laptop to be a bridge for attackers to jump from the public internet into the corporate VPN.
| VPN Type | Endpoints | Mode | Primary Goal |
|---|---|---|---|
| Site-to-Site | Gateway $ ightarrow$ Gateway | Tunnel | Connecting Two Offices |
| Remote Access | Client $ ightarrow$ Gateway | Tunnel | Secure Remote Work |
| Host-to-Host | Host $ ightarrow$ Host | Transport | Internal Server Security |
StrongSwan and LibreSwan are the leading open-source implementations of IPsec for Linux. They handle the IKE negotiation and interface with the Linux kernel's XFRM (Transformation) framework to actually encrypt the packets. Configuring these requires precise attention to 'Proposal' matching—if the client wants AES-256 but the server only allows AES-128, the connection will fail.
Never allow 'Any' as a destination in your SPD. This can lead to 'routing leaks' where the VPN gateway accidentally forwards internal traffic to the public internet.
Verify exercises to earn ★ 180 XP and unlock next lab level.