In this lesson, you will learn how to bridge the gap between kernel-level packet encryption and your existing routing tables to establish secure site-to-site VPN tunnels.
Understanding Policy-Based Encryption
When you configure an IPSec tunnel in Linux, you aren't just creating a virtual interface; you are defining an IPSec Security Policy Database (SPD). The kernel examines outgoing packets against this database. If a packet matches a defined policy—typically based on source/destination subnets—the kernel intercepts that packet to perform encapsulation (ESP or AH) before it hits the routing table for physical egress.
Unlike routing, which dictates where a packet goes, IPSec policies dictate how a packet must be transformed. Integrating the two requires ensuring your routing table points traffic toward the remote subnet, while your IPSec policy handles the cryptographic "handshake."
Configuring the Policy
In modern Linux systems using strongswan or the XFRM framework, you define your policies within your configuration files (e.g., ipsec.conf or swanctl.conf). A standard site-to-site policy looks like this:
conn site-a-to-site-b
left=192.168.1.1 # Local gateway public IP
leftsubnet=10.0.1.0/24 # Local network protected by IPSec
right=192.168.2.1 # Remote gateway public IP
rightsubnet=10.0.2.0/24 # Remote network protected by IPSec
auto=start
The Role of the Routing Table
Once the IPSec policy is active, the kernel’s XFRM (Transform) layer becomes part of the networking stack. You must ensure your routing table has an entry for the remote subnet:
# Directing traffic for the remote subnet to the local gateway
ip route add 10.0.2.0/24 dev eth0
Even though this route points to your physical interface (eth0), the kernel sees that the traffic matches the XFRM policy for the 10.0.2.0/24 destination. It will automatically intercept the traffic, encrypt it, and send the resulting ESP packet to the remote peer defined in your policy. If you lack the route, the kernel won't know to push the packets toward the physical interface in the first place, and your IPSec tunnel will stay idle.
Key Takeaway: IPSec policies act as a transparent interceptor; you must configure your routing table to direct target traffic toward the tunnel gateway, while the XFRM policy handles the actual encryption and transformation process.