Unlock document.
This document is partially blurred.
Unlock all pages and 1 million more documents.
Get Access
IPSEC LAB
Part 1:IPSec connection with Manual Keying in the same subnet (Transport mode)
The goal of this part of the lab is to establish an IPSec connection between
1. Steps taken to configure the hosts:
Below is the setkey.conf file for M1. The setkey.conf file for M3 is identical, except for the
security policies section, which had “–P out” instead of “–P in” and “–P in” instead of “–P out”
add 192.168.100.2 192.168.101.2 esp 0x201 -E 3des-cbc ------> 6
add 192.168.101.2 192.168.100.2 esp 0x301 -E 3des-cbc ------> 9
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df ------> 10
-A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b; ------> 11
# Security policies ------> 12
spdadd 192.168.100.2 192.168.101.2 any -P out ipsec ------> 13
esp/transport//require; ------> 14
The setkey file has two blocks. The first part deals with configuring the IPSec security associations
while the second part is used for configuring the security policies.
We configured the Security Policies in the following way
Using the keyword spdadd we specified the two end hosts which would be taking part in
the IPSec connection and gave the SA and direction (OUT since the configuration file is on M1). Also
we specified that the SA should be set up using the transport mode and the ESP protocol. This is shown
in Lines 13 and 14. Lines 15 and 16 specify the other direction (IN).
2. IPSec provides the following services in this example:
⚫ Confidentiality, since we are using the ESP protocol which encrypts the IP payload unlike the
AH protocol. We set the encryption key in the setkey.conf file
3. No,the IP header is not encrypted. This is because we are using the Transport mode which runs
4. The protocol number for ESP is 0x32 in hex or 50 in decimal
6. The SPI for the SA from M1 to M3 is 0x00000201 while that for the SA from M3 to M1 is
0x00000301.
Part 2: IPSec connection with Manual Keying between hosts in different subnets (Tunnel Mode):
In this part we have established an IPSec SA in the tunnel mode between 10.24.100.15 and
10.24.100.37 gateways. NAT was overcome using the given instructions. After the initial setup we sent
packets between 192.168.10.2 and 192.168.12.2 which were behind the 10.24.100.15 and 10.24.100.37
1. Shown below is the setkey.conf file that we used on 10.24.100.37 (M2). The setkey.conf file for
M2 of our partner group is identical, except for the security policies section, which had “–P out”
instead of “–P in” and “–P in” instead of “–P out” indicating the change in direction for the
add 10.24.100.37 10.24.100.15 esp 0x04786b7e -m tunnel -E 3des-cbc ------>8
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df ------>9
# Security policies ------>10
spdadd 192.168.12.0/24 192.168.10.0/24 any -P out ipsec ------>11
esp/tunnel/10.24.100.37-10.24.100.15/require; ------>12
spdadd 192.168.10.0/24 192.168.12.0/24 any -P in ipsec ------>13
esp/tunnel/10.24.100.15-10.24.100.37/require; ------>14
Setkey.conf file on 10.24.100.37
The setkey file has two blocks in it and the first part deals with configuring the IPSec
Security Associations while the second part is used for configuring the Security Policies. We first
flushed the previous configuration settings (if any) and configured the Security Association Database
parameters as follows.
2. IPSec provides only confidentiality in this case. We are neither using AH nor using
3. Since we are using the tunneling mode the original IP header is encrypted and a new IP header
10.24.100.15 and 10.24.100.37 as the source and destinations respectively. The new IP header is
4. Yes, we are able to see ESP packets in both directions but only the incoming ICMP echo request
5. If in the tunnel mode ESP authentication was used , then there would be no difference in the
Part 3: IPSec connection with Manual Keying between hosts in different subnets (Transport Mode):
In this part we have established an IPSec SA in the transport mode between 192.168.10.2
and 192.168.13.2 which are behind the 10.24.100.15 and 10.24.100.37 gateways. NAT was overcome
192.168.10.2 and 192.168.13.2 was encrypted using the IPSec ESP protocol.
2. Shown below is the setkey.conf file that we used on 192.168.13.2 (M3). The setkey.conf file for
M1 of our partner group is identical, except for the security policies section, which had “–P out”
instead of “–P in” and “–P in” instead of “–P out” indicating the change in direction for the
add 192.168.10.2 192.168.13.2 esp 0x301 -E 3des-cbc ------>8
0xf6ddb555acfd9d77b03ea3843f26532558fe8eb5573965df; ------>9
#Security Policies ------>10
spdadd 192.168.10.2 192.168.13.2 any -P in ipsec ------>11
esp/transport//require; ------>12
Setkey.conf file on 192.168.13.2
The setkey file has two blocks in it and the first part deals with configuring the IPSec
security associations while the second part is used for configuring the Security Policies. We first
flushed the previous configuration settings( if any) and configured the Security Association Database
parameters as follows.
Lines 8 and 9 contain the required configuration settings for the SA in the other direction.
The encryption key for this SA is different from the one used for the previous SA.
We configured the Security Policies in the following way
Using the keyword spdadd we specified the two end hosts which would be taking part in
the IPSec connection and gave the SA a direction (IN since the configuration file is on M3). Also we
specified that the SA should be set up using the transport mode and the ESP protocol. This is shown in
Lines 11 and 12. Lines 13 and 14 specify the other direction (OUT).
2. IPSec provides only confidentiality in this case. We are neither using AH nor using
3. No,the IP header is not encrypted. This is because we are using the Transport mode which runs
4. No. Since the entire IP payload is encrypted, there is no way in which we can determine if the
higher layer protocol is TCP or UDP or IP.
5. Some of the difference between the transport mode and the tunnel mode are:
⚫ The original IP header is protected in the tunnel mode while it is not in the transport mode
6. The source and destination addresses of the IP Packets are the end hosts 192.168.10.2 and
192.168.13.2 . No, these are not the same as the source and destination of the tunnel mode in
7. “Use” level is used if an SA has already been established between the hosts. The packets are
hence IPSec protected if a session was existing else they will be sent in the clear. The “require”
lever requires an SA to be setup each time a new communication session begins, irrespective of
Part 4: Automatic Keying with IKE with pre-shared keys (Transport Mode)
In this part of the lab we used the method of pre-shared keys to set up the IPSec SA in the
Shown below is the network topology used by us.
1 a). The Configuration file for the IPSEC daemon Racoon : racoon.conf
path pre_shared_key "/etc/psk.txt"; ------>1
remote 192.168.10.2 { ------>2
encryption_algorithm 3des; ------>13
authentication_algorithm hmac_md5; ------>14
compression_algorithm deflate; ------>15
} ------>16
The configuration file contains details about various parameters that are used while setting up an IPSec
an RSA signature. Line 8 specifies the group to be used for Diffie-Hellman exponentiations.
Lines 11-16: This block is used during Phase 2 of IKE. Line 11 specifies that the block remains
anonymous. Instead of setting this for a specific host, the anonymous parameter is used to specify that
these settings should be used for all hosts that do not have a specific configuration [1]. This is sufficient
for simple connections. The peer is identified using the presharedsecret.
management in intuitive ways. The following is a typical setkey.conf file to enable this setup.
#!/usr/sbin/setkey -f
#Config for 192.168.13.2
# flush the SAD and SPD
flush;
(192.168.13.2) of one subnet, destined to M1 (192.168.10.2) of the other subnet have to follow the
1.c). Finally, the file from which the preshared key is derived: psk.txt
#This file contains the preshared key
192.168.10.2 presharedkey.
3. Description of IKE with preshared keys in the transport mode.
The IKE has two phases. Phase 1 is used for mutual authentication and to establish session
keys and at the end of this phase, two session keys are established, an integrity key and an encryption
key. It takes the first 4 packets to create these keys and they are used to encrypt the rest of phase 1 and
Phase 1: The ISAKMP SA establishment (Main Mode):
The screen shot above was taken while running racoon in the foreground or diagnostic
mode using the command racoon -F . It shows a successful, key exchange between the participating
Messages 1 and 2.
This message also sends the Crypto Proposal from the first machine to the second machine
to agree upon, for encryption and authentication purposes. In this case the the encryption algorithm will
be 3DES-CBC, Authentication is by using preshared keys and the hash algorithm for integrity check is
MD5. The proposal also contains the diffie-hellman key exchange modp group.
The second message is almost exactly the same as the first except that the source and
