Language and Page Formatting Options
2.7.3. Host-To-Host VPN Using Libreswan
To configure Libreswan to create a host-to-host
IPsecVPN, between two hosts referred to as “left” and “right”, and enter the following commands as
rooton both of the hosts (“left” and “right”) to create new raw RSA key pairs:
ipsec newhostkey --configdir /etc/ipsec.d \
--output /etc/ipsec.d/myvpn.secretsGenerated RSA key pair using the NSS database
This generates an RSA key pair for the host. The process of generating RSA keys can take many minutes, especially on virtual machines with low entropy.
To view the public key, issue the following command as
rooton either of the hosts. For example, to view the public key on the “left” host, run:
ipsec showhostkey --leftipsec showhostkey loading secrets from "/etc/ipsec.secrets" ipsec showhostkey loading secrets from "/etc/ipsec.d/myvpn.secrets" ipsec showhostkey loaded private key for keyid: PPK_RSA:AQOjAKLlL # rsakey AQOjAKLlL leftrsasigkey=0sAQOjAKLlL4a7YBv [...]
You have to add this key to the configuration file as explained in the following paragraphs.
The secret part is stored in
/etc/ipsec.d/*.dbfiles, also called the “NSS database”.
To make a configuration file for this host-to-host tunnel, the lines
rightrsasigkey=from above, are added to a custom configuration file placed in the
Using an editor running as
root, create a file with a corresponding name in the following format:
Edit the file as follows:
conn myvpn email@example.com left=126.96.36.199 leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ== firstname.lastname@example.org right=188.8.131.52 rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ== authby=rsasig # load and initiate automatically auto=start
You can use the identical configuration file on both left and right hosts. They auto-detect if they are “left” or “right”. If one of the hosts is a mobile host, which implies the
IPaddress is not known in advance, then on the mobile host use
IPaddress. This picks up the dynamic
IPaddress automatically. On the static host that accepts connections from incoming mobile hosts, specify the mobile host using
leftrsasigkeyvalue is obtained from the “left” host and the
rightrsasigkeyvalue is obtained from the “right” host.
ipsecto ensure it reads the new configuration:
~]# service ipsec --full-restart
To check the tunnel is succesfully established, and additionally see how much traffic has gone through the tunnel, enter the following command as
ipsec whack --trafficstatus006 #2: "myvpn", type=ESP, add_time=1234567890, inBytes=336, outBytes=336, id='@east'
Alternatively, if not using the
auto=startoption in the
/etc/ipsec.d/*.conffile or if a tunnel is not succesfully established, use the following command as
rootto load the
ipsec auto --add myvpn
To bring up the tunnel, issue the following command as
root, on the left or the right side:
ipsec auto --up myvpn
184.108.40.206. Verify Host-To-Host VPN Using Libreswan
IKEnegotiation takes place on
IPsecpackets show up as
Encapsulated Security Payload(ESP) packets. When the VPN connection needs to pass through a NAT router, the
ESPpackets are encapsulated in
UDPpackets on port 4500.
To verify that packets are being sent via the VPN tunnel, issue a command as
rootin the following format:
tcpdump -n -i interface esp or udp port 500 or udp port 450000:32:32.632165 IP 220.127.116.11 > 18.104.22.168: ESP(spi=0x63ad7e17,seq=0x1a), length 132 00:32:32.632592 IP 22.214.171.124 > 126.96.36.199: ESP(spi=0x4841b647,seq=0x1a), length 132 00:32:32.632592 IP 192.0.2.254 > 188.8.131.52: ICMP echo reply, id 2489, seq 7, length 64 00:32:33.632221 IP 184.108.40.206 > 220.127.116.11: ESP(spi=0x63ad7e17,seq=0x1b), length 132 00:32:33.632731 IP 18.104.22.168 > 22.214.171.124: ESP(spi=0x4841b647,seq=0x1b), length 132 00:32:33.632731 IP 192.0.2.254 > 126.96.36.199: ICMP echo reply, id 2489, seq 8, length 64 00:32:34.632183 IP 188.8.131.52 > 184.108.40.206: ESP(spi=0x63ad7e17,seq=0x1c), length 132 00:32:34.632607 IP 220.127.116.11 > 18.104.22.168: ESP(spi=0x4841b647,seq=0x1c), length 132 00:32:34.632607 IP 192.0.2.254 > 22.214.171.124: ICMP echo reply, id 2489, seq 9, length 64 00:32:35.632233 IP 126.96.36.199 > 188.8.131.52: ESP(spi=0x63ad7e17,seq=0x1d), length 132 00:32:35.632685 IP 184.108.40.206 > 220.127.116.11: ESP(spi=0x4841b647,seq=0x1d), length 132 00:32:35.632685 IP 192.0.2.254 > 18.104.22.168: ICMP echo reply, id 2489, seq 10, length 64
Where interface is the interface known to carry the traffic. To end the capture with tcpdump, press Ctrl+C.
The tcpdump commands interacts a little unexpectedly with
IPsec. It only sees the outgoing encrypted packet, not the outgoing plaintext packet. It does see the encrypted incoming packet, as well as the decrypted incoming packet. If possible, run tcpdump on a router between the two machines and not on one of the endpoints itself.