- FreeS/WAN is an Open Source Linux implementation for IPSec protocol, standardized by the IPSec Charter of the IETF. According to Linux Advanced Routing and Traffic Control Howto, a native IPSec implementation for linux (v 2.6) is currently under development. However, I think freeswan is a pretty neat and powerfull IPSec prototype if used appropriately.
- The FreeSwan implementation consists of two major components:
- KLIPS: This component offers cryptographic services (encryption/decryption/authentication/compression) to IP packets and is built as a kernel module.
- Pluto (IKE daemon): This component is used for negotiatiating keys (and other parameters) that are used by KLIPS, and is built as a userland application. Once the pluto daemon is started, the user can interact with it using ipsec whack commands.
- The online documentation serves as an excellent guide for installation/use, and this recipe just complements it. Also it serves as a log for me to remember how I used IPSec.
- First thing to do is check if your linux distribution already has freeswan. Try executing
ipsec setup start. If you get an error like ipsec: Command not found. (assuming ipsec is
in your path) then you will have
to install it using any ONE of the following two methods.
- If you are using the RedHat distribution (with the kernel that comes with it), use the following command
to download the necessary RPM's.
#> mkdir ipsec; cd ipsec #> wget ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/`uname -r | tr -d 'a-wy-z'`/\* #> rpm --import freeswan-rpmsign.asc #> rpm --checksig freeswan*.rpm freeswan-module-2.01_2.4.20_8-0.i386.rpm: sha1 (md5) pgp md5 OK freeswan-userland-2.01_2.4.20_8-0.i386.rpm: sha1 (md5) pgp md5 OK
You can then install the RPM's using the following commands:#> rpm -ivh freeswan-module-2.01_2.4.20_8-0.i386.rpm #> rpm -ivh freeswan-userland-2.01_2.4.20_8-0.i386.rpm
- If you are using a stock linux kernel, downloaded from kernel.org,
then it is possible that you might not get a suitable RPM
(Interested in compiling a stock linux kernel for RedHat systems?
Click here).
In this case
download the latest freeswan source tarball (V 2.01, at the time of this writing) using the instruction:
#> wget ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-\*
I decided to untar it in /usr/src. Use the following commands [manual]:
Make sure that there is a link /usr/src/linux pointing to your current kernel and that the kernel is properly configured.#> mv ./freeswan-2.01.tar.gz /usr/src #> cd /usr/src #> tar -xvzf freeswan-2.01.tar.gz #> cd freeswan-2.01 #> make oldmod #> make minstall
- If you are using the RedHat distribution (with the kernel that comes with it), use the following command
to download the necessary RPM's.
- For using Ipsec we had to change out network setup from that used in other experiments. I will have to update all documents with the new setup, as I intend (for now) to perform experiments using this setup.
- Let us assume that we are using the following setup
with mia and spiff as the routers (or gateways) and
zidler and hulk as nodes on an internal Lan.
First we are just going to setup
a host-to-host ipsec tunnel (encrypting traffic flow only between mia and spiff),
using automatic and manual methods.
Later we will extend the same concept to Network-to-Network ipsec tunnels
(encrypting traffic flow only between 192.168.0.0/24 and 192.168.3.0/24 networks).
- Freeswan offers following methods to setup IPSec tunnels between nodes.
- Automatic: This method provides a set of commands (executed in a proper sequence) to set up IPSec Tunnels
[man ipsec_auto].
Behind the scenes, these commands just execute a series of
ipsec whack commands, which give proper instructions to Pluto (the IKE daemon).
For example:
- ipsec auto --show --add connection_name: This command adds the connection specific parameters, specified in /etc/ipsec.conf, to the internal database of pluto. Without this information, Pluto will not negotiate any Security Association(SA).
- ipsec auto --show --up connection_name: This will instruct pluto to negotiate an SA, and establish a tunnel between the two peers.
- ipsec auto --show --down connection_name: This will instruct pluto to take down an established IPSec tunnel.
- ipsec auto --show --delete connection_name: This will instruct pluto to delete the connection specific parameters that were added using the add command.
- Manual: Used to manually set up IPSec tunnels. These are also a set of commands that need to be
executed in the proper sequence. Some of these commands are:
- ipsec manual --show --up connection_name: Used to manually start the connection (connection_name) as specified in /etc/ipsec.conf.
- ipsec manual --show --down connection_name: Used to manually stop the connection (connection_name) as specified in /etc/ipsec.conf.
- ipsec manual --show --unroute connection_name: The down command (given above) only takes down the connection, but does not physically remove the routes. If this is not done, packets sent to the other end are discarded. Hence the --unroute command needs to be given to remove such routes.
- Using Policy Groups: I have not tried this method yet, so can't comment about it.
- Automatic: This method provides a set of commands (executed in a proper sequence) to set up IPSec Tunnels
[man ipsec_auto].
Behind the scenes, these commands just execute a series of
ipsec whack commands, which give proper instructions to Pluto (the IKE daemon).
For example:
- I have been able to set up IPsec tunnels for the following cases:
- Host-to-host IPSec Tunnels using auto command set:
Below we discuss how to setup an automatic IPSec tunnel between two peers on the Internet.
The network configuration is
show below:
- Configuring
/etc/ipsec.secrets
(man ipsec.secrets):
The very first thing to do is properly configure /etc/ipsec.secrets
with appropriate keys (either RSA public/private keypair or Pre-Shared secret Key (PSK))
on every participating node.
These keys are used ONLY by Pluto to authenticate peer pluto-based IKE daemons. After authenticating each other, these daemons exchange certain information (for e.g shared keys) to form a Security Association (SA), which is used by KLIPS to encrypt traffic between the two peers.
RSA and PSK keys can be generated as:- RSA:
RSA public/private keys can be genrated using the following command:
[shashank@mia /etc]# /usr/local/sbin/ipsec newhostkey --output /etc/ipsec.secrets [shashank@mia /etc]# cat /etc/ipsec.secrets 1. : RSA { 2. # RSA 2192 bits mia.ece.uic.edu Fri Aug 8 16:54:03 2003 3. # for signatures only, UNSAFE FOR ENCRYPTION 4. #pubkey=0sAQN+0ObyTUPxn2r/m3URW7uVq/S+C3dJenU..... 5. Modulus: 0x7ed0e6f24d43f19f6aff9b75115bbb95ab..... 6. PublicExponent: 0x03 7. # everything after this point is secret 8. PrivateExponent: 0x1522d1286235fd9a91d5449382..... 9. Prime1: 0xf08b954672e0d5b1d89455e5f2ff72b02cb..... 10. Prime2: 0x86f6bc07f4c5f58ebd139b1fc51fc4fa65e..... 11. Exponent1: 0xa05d0e2ef7408e769062e3eea1ffa1ca..... 12. Exponent2: 0x59f9d2aff883f909d362676a836a8351..... 13. Coefficient: 0x230fe4391d79b13b5b631032020021..... 14. }NOTE the first line of the key. A name (or identity) can be assigned to this key before the ":". This enable's pluto to select a particular RSA key for a particular connection. If such a name is not provided, this key will acts as a default for all connections (Use man ipsec.secrets to find out more about how to specify the name for a key).
Additional RSA keys can be generated using the command ipsec rsasigkey 1024 and must be manually put in /etc/ipsec.secrets in the proper format. I have done this and named the RSA key as @mia on mia and @spiff on spiff as indicated below:[shashank@mia /etc]# /usr/local/sbin/ipsec rsasigkey 1024 >> /etc/ipsec.secrets [shashank@mia /etc]# pico /etc/ipsec.secrets [shashank@mia /etc]# cat ipsec.secrets : RSA { # RSA 2192 bits mia.ece.uic.edu Mon Aug 11 09:55:05 2003 # for signatures only, UNSAFE FOR ENCRYPTION #pubkey=0sAQNgZVw+MZpwjtjSDYobZJOuil3/h2FcG3h --SNIP-- } @mia: RSA { # RSA 1024 bits mia.ece.uic.edu Mon Aug 11 10:07:10 2003 # for signatures only, UNSAFE FOR ENCRYPTION #pubkey=0sAQO8jbw1RZ82kOXxij5kKclmvfMhNqcRFmp --SNIP-- }NOTE: You will have to manually enter @mia: RSA and the opening and closing braces, as ipsec rsasigkey does not do that. - PSK:
A Pre-Share secret can be configured to be
shared between two pluto daemons by manually entering it in
/etc/ipsec.secrets (on both mia and spiff). Below is an example:
[shashank@mia /etc]# ipsec ranbits 192 0xe8e627e9_a9880d77_88e6ef39_916e5dac_f0493cd6_ddbd2aa4 [shashank@mia /etc]# pico ipsec.secrets (to paste the above key) [shashank@mia /etc]# cat ipsec.secrets : PSK "e8e627e9_a9880d77_88e6ef39_916e5dac_f0493cd6_ddbd2aa4" : RSA { # RSA 2192 bits mia.ece.uic.edu Fri Aug 8 16:54:03 2003 --SNIP-- - A patch also enables freeswan to support X509 certificates. Since i have not used this patch, I will not use this. (Interested to set up your own Certification Authority? Click here)
- RSA:
RSA public/private keys can be genrated using the following command:
- Configuring
/etc/ipsec.conf
(man ipsec.conf):
We will now configure /etc/ipsec.conf for creating a HOST-TO-HOST VPN using automatic method.
In this configuration, a secure
channel is made between mia and spiff. Thus only those packets that are sent from mia to spiff (and vice-versa)
are encrypted . Make full use of
man ipsec.conf to find out
about all
the options. We will only use those that are important to us.
Shown below is the common /etc/ipsec.conf file that is shared between mia and spiff.
#> cat /etc/ipsec.conf 1 version 2.0 # conforms to second version of ipsec.conf specification 2 3 config setup 4 interfaces="ipsec0=eth0" 5 klipsdebug=none 6 plutodebug=none 7 uniqueids=yes 8 #manualstart="mia-spiff-h2h-manual" 9 10 conn %default 11 keyingtries=0 12 authby=rsasig 13 14 conn block 15 auto=ignore 16 17 conn private 18 auto=ignore 19 20 conn private-or-clear 21 auto=ignore 22 23 conn clear-or-private 24 auto=ignore 25 26 conn clear 27 auto=ignore 28 29 conn packetdefault 30 auto=ignore 31 32 conn mia-spiff-h2h 33 left=131.193.50.165 34 # leftsubnet=131.193.50.165/32 35 leftnexthop=131.193.50.1 36 leftid=@mia 37 leftrsasigkey=0sAQOAS9+zP7L5pHZG8JgdBP... 38 right=131.193.50.187 39 # rightsubnet=131.193.50.187/32 40 rightnexthop=131.193.50.1 41 rightid=@spiff 42 rightrsasigkey=0sAQNaO9TGUfxQOjTQJc9Lzq... 43 auto=ignore 44 rekey=no 45 failureshunt=passthrough 46 pfs=no 47 compress=no 48 # auth=esp #(esp|ah) 49 authby=rsasig #(rsasig|secret) 50 type=tunnel #(tunnel|transport|passthrough|drop|reject)Explanation for most options can be obtained by using man ipsec.conf and but some not-so-apparent options are explained below:- version (Line #1): This is always the first line of any ipsec.conf file. Here we have indicated the version to be "2.0".
- Lines #3 to #8: This is the common configuration section for all ipsec connections.
- Lines #10 to #12: This section defines the default settings for all ipsec connections.
- Lines #14 to #30: These are used to disable all
default policy groups from being set up. (Take this advice with a pinch of salt)
- Lines #32 to #47: Specifies the connection settings for mia-spiff-h2h connection. Some of the options used are explained below:
- leftsubnet &
rightsubnet:
These options control what packets the tunnel will carry.
In our example, i have used the IP addresses
131.193.50.165/32 and 131.193.50.187/32, which means
that only packets between 131.193.50.165 (i.e. mia) and 131.193.50.187
(i.e. spiff) will be encrypted.
To create a Net-to-Net tunnel (discussed later), you will only have to change
these to appropriate values.
Note: For host-to-host Ipsec tunnels, these options are not required. Hence they are shown here as commented. - leftid & rightid: These options determine which RSA keys from /etc/ipsec.secrets are actually used. Only the keys with the specific ID will be selected.
- leftrsasigkey & rightrsasigkey:
These are the public keys for mia and spiff. They can be obtained using the command:
shashank@mia #> ipsec showhostkey --left --id @mia # RSA 1024 bits mia.ece.uic.edu Wed Aug 13 10:24:08 2003 leftrsasigkey=0sAQOAS9+zP7L5pHZG8.... --SNIP-- shashank@spiff #> ipsec showhostkey --right --id @spiff # RSA 1024 bits spiff.ece.uic.edu Wed Aug 13 10:26:47 2003 rightrsasigkey=0sAQNaO9TGUfxQOjTQJc9Lzq...
- auto (add|route|start|manual|ignore*):
If set to "add", ipsec will automatically add the connection parameters to the internal database of pluto.
Hence you will not have to give the command ipsec auto --add mia-spiff-h2h.
I always set it to ignore, which does not add anything to the pluto database. - failureshunt (passthrough|drop|reject|none*): This is another important option, that controls what happens when a tunnel is brought down. By default it is set to none. Always set it to passthrough.
- auth (esp|ah): If set to esp, specifies that ipsec should use ESP for the tunnel. If set to ah, specifies that both ESP + AH must be used (I think). However, at the time of this writing the second mode does not seem to be working.
- authby (secret|rsasig): This is used specify if authentication must be done using RSA keys (preferred) or using a secret key (PSK).
- type (tunnel|transport|passthrough|drop|reject): This is used
to sepcify the type of processing the IP packets must be subjected to.
For example, the below figure (Ref: Building Linux VPN's, Chap5, Page 138) shows the difference between
tunnel and transport mode.
Note: the tunnel mode can be used for creating Host-to-Host, Host-to-Network, Network-to-Network Ipsec tunnels, but the transport mode can be used to create only Host-to-Host Ipsec tunnels.
- Lines #32 to #47: Specifies the connection settings for mia-spiff-h2h connection. Some of the options used are explained below:
- Establishing IPsec tunnel:
To establish a tunnel, use the following sequence of commands on mia and spiff:
Note: The --show option is only used for debugging. Also commands indicated by (***) are optional.-------------------------------------------------------------------------------------------- mia spiff -------------------------------------------------------------------------------------------- ipsec setup start ipsec setup start ipsec setup verify (***) ipsec setup verify (***) ipsec auto --show --add mia-spiff-h2h ipsec auto --show --add mia-spiff-h2h ipsec auto --show --up mia-spiff-h2h 104 "mia-spiff-h2h" #4: STATE_MAIN_I1: initiate 106 "mia-spiff-h2h" #4: STATE_MAIN_I2: sent MI2, expecting MR2 108 "mia-spiff-h2h" #4: STATE_MAIN_I3: sent MI3, expecting MR3 004 "mia-spiff-h2h" #4: STATE_MAIN_I4: ISAKMP SA established 112 "mia-spiff-h2h" #5: STATE_QUICK_I1: initiate 004 "mia-spiff-h2h" #5: STATE_QUICK_I2: sent QI2, IPsec SA established --------------------------------------------------------------------------------------------- - Now check if the packets are encyrpted using tcpdump and ping as before.
[shashank@mia /etc]# tcpdump -i eth0 host spiff tcpdump: listening on eth0 17:26:39.803815 spiff > mia: ESP(spi=0x4389906e,seq=0x11e) 17:26:39.803953 mia > spiff: ESP(spi=0x7a1f85e0,seq=0x120)You can see ESP(spi=0x4389906e,seq=0x11e) which means that the packets are indeed encrypted using ESP. - Check the kernel routing tables now using netstat -rn . These are shown below.
[shashank@mia /etc]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 131.193.50.187 131.193.50.1 255.255.255.255 UGH 40 0 0 ipsec0 131.193.50.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 131.193.50.0 0.0.0.0 255.255.255.0 U 40 0 0 ipsec0 *** 192.168.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 131.193.50.1 0.0.0.0 UG 40 0 0 eth0 --------------------------------------------------------------------------------- shashank@spiff:~# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 131.193.50.165 131.193.50.1 255.255.255.255 UGH 0 0 0 ipsec0 192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 131.193.50.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 131.193.50.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0 *** 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 131.193.50.1 0.0.0.0 UG 0 0 0 eth0One can see that if a packet is sent from spiff to mia, the Ipstack will use the interface ipsec0. For all other packets eth0 is used. I am a bit confused about why the lines with "***" are there in the kernel routing table. - You can also peek at the encryption algorithms/authentication algorithms employed using the following two commands:
mia# ipsec look mia.ece.uic.edu Fri Aug 22 11:42:47 CDT 2003 131.193.50.165/32 -> 131.193.50.187/32 => [email protected] [email protected] (210) ipsec0->eth0 mtu=16260(1443)->1500 [email protected] ESP_3DES_HMAC_MD5: dir=out src=131.193.50.165 iv_bits=64bits iv=0xda32b05b84e9bc71 ooowin=64 seq=105 alen=128 aklen=128 eklen=192 life(c,s,h)=bytes(14816,0,0)addtime(147,0,0)usetime(83,0,0)packets(105,0,0) idle=73 refcount=4 ref=12 [email protected] ESP_3DES_HMAC_MD5: dir=in src=131.193.50.187 iv_bits=64bits iv=0xcd481addfa20735c ooowin=64 seq=69 bit=0xffffffffffffffff alen=128 aklen=128 eklen=192 life(c,s,h)=bytes(10351,0,0)addtime(147,0,0)usetime(83,0,0)packets(69,0,0) idle=73 refcount=73 ref=7 [email protected] IPIP: dir=in src=131.193.50.187 policy=131.193.50.187/32->131.193.50.165/32 flags=0x8<> life(c,s,h)=bytes(10351,0,0)addtime(147,0,0)usetime(83,0,0)packets(69,0,0) idle=73 refcount=4 ref=8 [email protected] IPIP: dir=out src=131.193.50.165 life(c,s,h)=bytes(11454,0,0)addtime(147,0,0)usetime(83,0,0)packets(105,0,0) idle=73 refcount=4 ref=13 Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 131.193.50.1 0.0.0.0 UG 40 0 0 eth0 131.193.50.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 131.193.50.0 0.0.0.0 255.255.255.0 U 40 0 0 ipsec0 131.193.50.187 131.193.50.1 255.255.255.255 UGH 40 0 0 ipsec0ANDmia# ipsec auto --status 000 interface ipsec0/eth0 131.193.50.165 000 000 debug none 000 000 "mia-spiff-h2h": 131.193.50.165[@mia]---131.193.50.1...131.193.50.1---131.193.50.187[@spiff] 000 "mia-spiff-h2h": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0 000 "mia-spiff-h2h": policy: RSASIG+ENCRYPT+TUNNEL+DONTREKEY+UP+failurePASS; interface: eth0; erouted 000 "mia-spiff-h2h": newest ISAKMP SA: #1; newest IPsec SA: #2; eroute owner: #2 000 000 #2: "mia-spiff-h2h" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 28555s; newest IPSEC; eroute owner 000 #2: "mia-spiff-h2h" [email protected] [email protected] [email protected] [email protected] 000 #1: "mia-spiff-h2h" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_EXPIRE in 3355s; newest ISAKMP 000Note: In the above output you can make out that RSA public key was used (RSASIG+ENCRYPT+TUNNEL+DONTREKEY+UP+failurePASS). However if you are using a secret key this output would be (PSK+ENCRYPT+TUNNEL+DONTREKEY+UP+failurePASS). - Stopping
IPsec tunnel:
The tunnel can be stopped using the following sequence of commands.
Note: The --show option is only used for debugging. Also commands indicated by (***)
are optional.
-------------------------------------------------------------------------------------------- mia spiff -------------------------------------------------------------------------------------------- ipsec auto --show --down mia-spiff-h2h ipsec auto --show --down mia-spiff-h2h ipsec auto --show --delete mia-spiff-h2h (***) ipsec auto --show --delete mia-spiff-h2h (***) ipsec setup stop ipsec setup stop --------------------------------------------------------------------------------------------- - Make sure that the tunnel is down by using ping and tcpdump.
- Configuring
/etc/ipsec.secrets
(man ipsec.secrets):
The very first thing to do is properly configure /etc/ipsec.secrets
with appropriate keys (either RSA public/private keypair or Pre-Shared secret Key (PSK))
on every participating node.
- Host-to-Host IPSec Tunnels using manual command set:
Below we discuss how to manually setup a IPSec tunnel between two peers
on the Internet. The network configuration is show below:
- Configuring /etc/ipsec.secrets: There is no need to configure the ipsec.secret, as manual connection does not use this file.
- Configuring /etc/ipsec.conf:
Let us add a new connection specification named mia-spiff-h2h-manual to our /etc/ipsec.conf file
as indicated below:
1 - 50 --SNIP-- 51 conn mia-spiff-h2h-manual 52 left=131.193.50.165 53 # leftsubnet=131.193.50.165/32 54 leftnexthop=131.193.50.1 55 right=131.193.50.187 56 # rightsubnet=131.193.50.187/32 57 rightnexthop=131.193.50.1 58 spi=0x300 59 esp=3des-md5-96 60 espenckey=0x7ae54bc2_c5f885ae_e21f6d4b_e118b1b2_4a877dee_c3ee713d 61 espauthkey=0x1cc467d1_8931fea2_d2c6d607_b09b482d 62 # esp=3des 63 # espenckey=0x7ae54bc2_c5f885ae_e21f6d4b_e118b1b2_4a877dee_c3ee713d 64 ###(manual) authentication algorithm and parameters to it 65 # ah=hmac-md5-96 66 # ahkey=0x1cc467d1_8931fea2_d2c6d607_b09b482d 67 # (auto) authentication control 68 # auth=ah 69Most of the options were explained earlier in Automatic Host-to-host IPSec Tunnels.
You will have to generate keys with appropriate key-lengths for the espenckey (keyLength: 192 bits) and espauthkey (KeyLength: 128 Bits) using ipsec ranbits keyLength command.
Note that the options commented out, allow the use of ESP + AH. However it does not seem to be working at this time. - Establishing IPsec tunnel: Use the following sequence of instructions:
Note: The --show option is only used for debugging. Also commands indicated by (***) are optional.------------------------------------------------------------------------- mia spiff ------------------------------------------------------------------------- ipsec setup start ipsec setup start ipsec setup verify (***) ipsec setup verify (***) ipsec manual --show --up mia-spiff-h2h-manual ipsec manual --show --up mia-spiff-h2h-manual ---------------------------------------------------------------------------If you uncomment the manualstart="mia-spiff-h2h-manual" option you don't have to execute the --up commands. - Test that the tunnel has been established using the same method given in Automatic Host-to-host IPSec Tunnels.
- Stopping IPsec tunnel:
The tunnel can be stopped using the following sequence of instructions:
------------------------------------------------------------------------- mia spiff ------------------------------------------------------------------------- ipsec setup stop ipsec setup stop ---------------------------------------------------------------------------You can even use the ipsec manual --down and --unroute commands. But once --down is executed, the connection to the peer is broken and your terminal will hang up. You will have to establish a seperate connection to the peer from somewhere else to execute the --unroute command.
- Network-to-Network IPSec Tunnels using auto command set:
Below we discuss how to setup an automatic IPSec tunnel between two private networks on the Internet.
Note that ipsec is applies only between the two routers (mia and spiff).
The network configuration is shown below:
- Configuring /etc/ipsec.secrets: Follow the same instructions as given in Host-to-host IPSec Tunnels using auto command set to setup the /etc/ipsec.secrets file.
- Configuring /etc/ipsec.conf:
Let us add a new connection specification named mia-spiff-n2n to our /etc/ipsec.conf file
as indicated below:
Lines (1 to 50) and (51 to 69) --SNIP-- 70 conn mia-spiff-n2n 71 left=131.193.50.165 72 leftsubnet=192.168.0.0/24 73 leftnexthop=131.193.50.1 74 leftid=@mia 75 leftrsasigkey=0sAQOAS9+zP7L5pHZG8JgdBPf97IP4T... 76 right=131.193.50.187 77 rightsubnet=192.168.3.0/24 78 rightnexthop=131.193.50.1 79 rightid=@spiff 80 rightrsasigkey=0sAQNaO9TGUfxQOjTQJc9LzqWzrZkF... 81 auto=ignore 82 rekey=no 83 failureshunt=passthrough 84 pfs=no 85 compress=no 86 auth=esp 87 authby=rsasig 88Everything is the same as Automatic Host-to-host IPSec Tunnels, except leftsubnet and rightsubnet, which are replaced by leftsubnet=192.168.0.0/24 and rightsubnet=192.168.2.0/24. - Make sure that you have disabled IP masquerading on mia as well as spiff. Below is a simple script
(/etc/disableNAT.sh)
that will clear all your rules using iptables.
Update it appropriately to make your firewall more robust.
#!/bin/sh echo -e "Disabling\n" IPTABLES=/sbin/iptables EXTIF="eth0" INTIF="eth1" echo "1" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/ip_dynaddr $IPTABLES -P INPUT ACCEPT $IPTABLES -F INPUT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -F OUTPUT $IPTABLES -P FORWARD ACCEPT $IPTABLES -F FORWARD $IPTABLES -t nat -F echo -e "done.\n" - Establishing IPsec tunnel: To establish a tunnel, follow the same sequece of instructions as given in HOST-TO-HOST Tunnel Establishment. Also use the same tests to determine if the packets are getting encrypted or not.
- Test the tunnel from a host that lies in the range of the subnet assigned to
leftsubnet and rightsubnet parameters.
In our case, we used pinged from hulk (192.168.0.2) to zidler (192.168.0.202). Also make sure that you have
appropriate routes on hulk and zidler. Execute the following commands on
hulk and zidler
shashank@hulk# route add -net 192.168.0.0/24 gw 192.168.3.1 ------------------------------------------------------------ shashank@zidler# route add -net 192.168.3.0/24 gw 192.168.0.1 - Stopping IPsec tunnel: The tunnel can be stopped using the same sequece of instructions as given in HOST-TO-HOST Tunnel DE-Establishment.
- Configuring /etc/ipsec.secrets: There is no need to configure the ipsec.secret, as manual connection does not use this file.
- Configuring /etc/ipsec.conf:
Let us add a new connection specification named mia-spiff-n2n-manual to our /etc/ipsec.conf file
as indicated below:
Lines 1 - 88 --SNIP-- 89 conn mia-spiff-n2n-manual 90 left=131.193.50.165 91 leftsubnet=192.168.0.0/24 92 leftnexthop=131.193.50.1 93 right=131.193.50.187 94 rightsubnet=192.168.3.0/24 95 rightnexthop=131.193.50.1 96 spi=0x500 97 esp=3des-md5-96 98 espenckey=0x7ae54bc2_c5f885ae_e21f6d4b_e118b1b2_4a877dee_c3ee713d 99 espauthkey=0x1cc467d1_8931fea2_d2c6d607_b09b482d 100 # esp=3des 101 # espenckey=0x7ae54bc2_c5f885ae_e21f6d4b_e118b1b2_4a877dee_c3ee713d 102 ###(manual) authentication algorithm and parameters to it 103 # ah=hmac-md5-96 104 # ahkey=0x1cc467d1_8931fea2_d2c6d607_b09b482d 105 # (auto) authentication control 106 # auth=ahMost of the options were explained earlier in Automatic Host-to-host IPSec Tunnels.
You will have to generate keys with appropriate key-lengths for the espenckey (keyLength: 192 bits) and espauthkey (KeyLength: 128 Bits) using ipsec ranbits keyLength command.
Note that the options commented out, allow the use of ESP + AH. However it does not seem to be working at this time. - Make sure that you have disabled IP masquerading on mia as well as spiff. Below is a simple script
(/etc/disableNAT.sh)
that will clear all your rules using iptables.
Update it appropriately to make your firewall more robust.
#!/bin/sh echo -e "Disabling\n" IPTABLES=/sbin/iptables EXTIF="eth0" INTIF="eth1" echo "1" > /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/ip_dynaddr $IPTABLES -P INPUT ACCEPT $IPTABLES -F INPUT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -F OUTPUT $IPTABLES -P FORWARD ACCEPT $IPTABLES -F FORWARD $IPTABLES -t nat -F echo -e "done.\n" - Establishing IPsec tunnel: Use the following sequence of instructions:
Note: The --show option is only used for debugging. Also commands indicated by (***) are optional.------------------------------------------------------------------------- mia spiff ------------------------------------------------------------------------- ipsec setup start ipsec setup start ipsec setup verify (***) ipsec setup verify (***) ipsec manual --show --up mia-spiff-n2n-manual ipsec manual --show --up mia-spiff--n2n-manual ---------------------------------------------------------------------------If you add manualstart="mia-spiff-n2n-manual" option to the config section of /etc/ipsec.conf, you don't have to execute the --up commands. - Test the tunnel from a host that lies in the range of the subnet assigned to
leftsubnet and rightsubnet parameters.
In our case, we used pinged from hulk (192.168.0.2) to zidler (192.168.0.202). Also make sure that you have
appropriate routes on hulk and zidler. Execute the following commands on
hulk and zidler
shashank@hulk# route add -net 192.168.0.0/24 gw 192.168.3.1 ------------------------------------------------------------ shashank@zidler# route add -net 192.168.3.0/24 gw 192.168.0.1
- Stopping IPsec tunnel:
The tunnel can be stopped using the following sequence of instructions:
------------------------------------------------------------------------- mia spiff ------------------------------------------------------------------------- ipsec setup stop ipsec setup stop ---------------------------------------------------------------------------
You can even use the ipsec manual --down and --unroute commands. But once --down is executed, the connection to the peer is broken and your terminal will hang up. You will have to establish a seperate connection to the peer from somewhere else to execute the --unroute command.