7.3. IPSEC tunnels
So far, we've only seen IPSEC in so called 'transport' mode where both endpoints understand IPSEC directly. As this is often not the case, it may be necessary to have only routers understand IPSEC, and have them do the work for the hosts behind them. This is called 'tunnel mode'.
Setting this up is a breeze. To tunnel all traffic to 130.161.0.0/16 from 10.0.0.216 via 10.0.0.11, we issue the following on 10.0.0.216:
#!/sbin/setkey -f
flush;
spdflush;
add 10.0.0.216 10.0.0.11 esp 34501
-m tunnel
-E 3des-cbc "123456789012123456789012";
spdadd 10.0.0.0/24 130.161.0.0/16 any -P out ipsec
esp/tunnel/10.0.0.216-10.0.0.11/require;
Note the '-m tunnel', it is vitally important! This first configures an ESP encryption SA between our tunnel endpoints,
10.0.0.216 and 10.0.0.11.
Next the actual tunnel is configured. It instructs the kernel to encrypt all traffic it has to route from 10.0.0.0/24 to 130.161.0.0. Furthermore, this traffic then has to be shipped to 10.0.0.11.
10.0.0.11 also needs some configuration:
#!/sbin/setkey -f
flush;
spdflush;
add 10.0.0.216 10.0.0.11 esp 34501
-m tunnel
-E 3des-cbc "123456789012123456789012";
spdadd 10.0.0.0/24 130.161.0.0/16 any -P in ipsec
esp/tunnel/10.0.0.216-10.0.0.11/require;
Note that this is exactly identical, except for the change from '-P out' to '-P in'. As with earlier examples,
we've now only configured traffic going one way. Completing the other half of the tunnel is left as an
exercise for the reader.
Another name for this setup is 'proxy ESP', which is somewhat clearer.
 | The IPSEC tunnel needs to have IP Forwarding enabled in the kernel! |