From 6ec4c157c79f35a2ee0ea5a99adb4e3af372df5b Mon Sep 17 00:00:00 2001 From: Bert Hubert Date: Thu, 7 Nov 2002 23:18:37 +0000 Subject: [PATCH] more about tunnels --- lartc.db | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 56 insertions(+), 2 deletions(-) diff --git a/lartc.db b/lartc.db index b44ab4f..e26b3b1 100644 --- a/lartc.db +++ b/lartc.db @@ -1655,6 +1655,13 @@ web interface. Search for "ipv6 tunnel broker" on your favourite search engine. up and running and explaining the basic principles. + + + Many iptables configurations drop IPSEC packets! To pass IPSEC, use: 'iptables -A xxx -p 50' and 'iptables -A xxx -p 51' + + + + IPSEC offers a secure version of the Internet Protocol. Security in this context means two different things: encryption and authentication. A naive vision of security offers only encryption but it can easily be shown that is insufficient - you may be communicating encyphered, but no guarantee is offered that the remote party is the one you expect it to be. @@ -1700,7 +1707,7 @@ spdadd 10.0.0.216 10.0.0.11 any -P out ipsec If entered on host 10.0.0.216, this means that all traffic going out to 10.0.0.11 must be encrypted and be wrapped in an AH authenticating header. Note that this does not descibe which SA is to be used, - that is left as an excercise for the kernel to determine. + that is left as an exercise for the kernel to determine. Outgoing packets are however labelled with the SAs SPI ids the kernel used for encryption and authentication @@ -1843,7 +1850,54 @@ spdadd 10.0.0.216 10.0.0.11 any -P in ipsec This is called 'tunnel mode'. - FIXME: write more + 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! + + -- 2.11.4.GIT