Linux Host-to-Host IPSEC

Sometimes, you want to encrypt all IP traffic between two Linux hosts. An easy way to do this with Red Hat Linux is to use IPSEC. While there are many applications which are encrypted, such as secure shell or even transport layer security and secure sockets layer over usually-unencrypted applications, IPSEC works at a lower level. IPSEC therefore can work regardless of the application and encrypts all IP communication.



Example Hosts

Host 1: 172.18.64.100 (host1)
Host 2: 172.20.16.200 (host2)

Configuration on host1

The numbers for SPI, or Security Parameter Index, are arbitrary. They just need to correlate with each other (IN on host1 goes to OUT on host2). I just picked a set of seven-digit numbers for this example.

# /etc/sysconfig/network-scripts/ifcfg-ipsec0
DST=172.20.16.200
TYPE=IPSEC
ONBOOT=yes
SPI_ESP_IN=9180000
SPI_AH_IN=8008135
SPI_ESP_OUT=5550100
SPI_AH_OUT=8675309

Configuration on host2

DST=172.18.64.100
TYPE=IPSEC
ONBOOT=yes
SPI_ESP_IN=5550100
SPI_AH_IN=8675309
SPI_ESP_OUT=9180000
SPI_AH_OUT=8008135

The Difference

Before you activate the IPSEC tunnel (which you have configured to start on boot), you should understand the difference in traffic. Here is an example of a single ping:

16:07:34.401784 IP 172.18.64.100 > 172.20.16.200: ICMP echo request, id 11084, seq 1, length 64
16:07:34.401842 IP 172.20.16.200 > 172.18.64.100: ICMP echo reply, id 11084, seq 1, length 64

You can see that the traffic is identifiable as ICMP.

After "sudo /sbin/ifup ipsec0":

16:09:32.580025 IP 172.18.64.100 > 172.20.16.200: AH(spi=0x00845fed,seq=0x2d): ESP(spi=0x0054b014,seq=0x2d), length 88
16:09:32.580144 IP 172.20.16.200 > 172.18.64.100: AH(spi=0x007a31c7,seq=0x23): ESP(spi=0x000138d5,seq=0x23), length 88

With the IPSEC connection, all the traffic will be IP protocol 50 and 51 (Encapsulating Security Payload and Authentication Header). Here is a secure shell session:

17:00:35.333778 IP 172.18.64.100 > 172.20.16.200: AH(spi=0x00845fed,seq=0x2f): ESP(spi=0x0054b014,seq=0x2f), length 64
17:00:35.333881 IP 172.20.16.200 > 172.18.64.100: AH(spi=0x007a31c7,seq=0x25): ESP(spi=0x000138d5,seq=0x25), length 64
17:00:35.333937 IP 172.18.64.100 > 172.20.16.200: AH(spi=0x00845fed,seq=0x30): ESP(spi=0x0054b014,seq=0x30), length 56
17:00:35.340078 IP 172.20.16.200 > 172.18.64.100: AH(spi=0x007a31c7,seq=0x26): ESP(spi=0x000138d5,seq=0x26), length 72
17:00:35.340183 IP 172.18.64.100 > 172.20.16.200: AH(spi=0x00845fed,seq=0x31): ESP(spi=0x0054b014,seq=0x31), length 56
17:00:35.340299 IP 172.18.64.100 > 172.20.16.200: AH(spi=0x00845fed,seq=0x32): ESP(spi=0x0054b014,seq=0x32), length 72
17:00:35.340355 IP 172.20.16.200 > 172.18.64.100: AH(spi=0x007a31c7,seq=0x27): ESP(spi=0x000138d5,seq=0x27), length 56
17:00:35.340490 IP 172.18.64.100 > 172.20.16.200: AH(spi=0x00845fed,seq=0x33): ESP(spi=0x0054b014,seq=0x33), length 768

tcpdump cannot inspect inside IPSEC to see this is traffic destined for TCP port 22. The traffic is encrypted so if your communication is intercepted, it cannot be deciphered. Clear-text passwords passed for checking mail would not be exposed.

Next time, I'll explain a way to encrypt traffic between hosts you don't have administrative access to, using secure shell.