Host to host VPN: Difference between revisions

From Libreswan
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 28: Line 28:
</pre>
</pre>


{{ ambox | type = alert | text = The process of generating a RSA new key can take minutes, especially on virtual machines low on entropy }}
{{ ambox | type = alert | text = On embedded hardware with low entropy, the process of generating a RSA new key can take minutes }}


You should now have a file called /etc/ipsec.secrets on both sides, which contain the public component of the RSA key. The secret part is stored in /etc/ipsec.d/*.db files, also called the "NSS database". You can protect this database with a passphrase if you want, but it will prevent the machine from bringing up the tunnel on boot, as a human would need to enter the passphrase. Note that on older openswan versions compiled without HAVE_NSS, the /etc/ipsec.secret file actually contains the secret part of the rsa keypair as well.
You should now have a file called /etc/ipsec.secrets on both sides, which contain the public component of the RSA key. The secret part is stored in /etc/ipsec.d/*.db files, also called the "NSS database". You can protect this database with a passphrase if you want, but it will prevent the machine from bringing up the tunnel on boot, as a human would need to enter the passphrase. Note that on older openswan versions compiled without HAVE_NSS, the /etc/ipsec.secret file actually contains the secret part of the rsa keypair as well.

Revision as of 19:56, 25 January 2019

This example sets up an IPsec connection between two hosts called "east" and "west". (these names are also used for our daily tests, and you can find lots of configuration examples in our test suite)

192.0.2.254/24 eth0 WEST eth1 192.1.2.23 --[internet]-- 192.1.2.45 eth1 EAST eth0 192.0.1.254/24

Libreswan uses the terms "left" and "right" to describe endpoints. We will use left for west and east for right. We will be using raw RSA keys, and not pre shared keys (PSK) because it is safer (and easier!)

Generate a raw RSA host key on each end and show the key for use in our configuration file. Note that the raw key blobs span several lines. We reduced them here for readability. Ensure they appear on a single line in your ipsec.conf.

[root@west ~]# ipsec newhostkey --output /etc/ipsec.secrets
Generated RSA key pair using the NSS database
[root@west ~]# ipsec showhostkey --left
	# rsakey AQOrlo+hO
	leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
[root@west ~]# 

Repeat for east using right:

[root@east ~]# ipsec newhostkey --output /etc/ipsec.secrets
Generated RSA key pair using the NSS database
[root@east ~]# ipsec showhostkey --right
	# rsakey AQO3fwC6n
	rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==

You should now have a file called /etc/ipsec.secrets on both sides, which contain the public component of the RSA key. The secret part is stored in /etc/ipsec.d/*.db files, also called the "NSS database". You can protect this database with a passphrase if you want, but it will prevent the machine from bringing up the tunnel on boot, as a human would need to enter the passphrase. Note that on older openswan versions compiled without HAVE_NSS, the /etc/ipsec.secret file actually contains the secret part of the rsa keypair as well.

Now we are ready to make a simple /etc/ipsec.conf file for our host to host tunnel. The leftrsasigkey/rightrsasigkey from above, are added to the configuration below.

# /etc/ipsec.conf
# The version 2 is only required for compatibility with openswan
version 2

config setup
    protostack=netkey

conn mytunnel
    leftid=@west
    left=192.1.2.23
    leftrsasigkey=0sAQOrlo+hOafUZDlCQmXFrje/oZm [...] W2n417C/4urYHQkCvuIQ==
    rightid=@east
    right=192.1.2.45
    rightrsasigkey=0sAQO3fwC6nSSGgt64DWiYZzuHbc4 [...] D/v8t5YTQ==
    authby=rsasig
    # use auto=start when done testing the tunnel
    auto=add

You can use the identical configuration file on both east and west. They will auto-detect if they are "left" or "right".

First, ensure ipsec is started:

ipsec setup start

Then ensure the connection loaded:

ipsec auto --add mytunnel

And then try and bring up the tunnel:

ipsec auto --up mytunnel

If all went well, you should see something like:

# ipsec auto --up  mytunnel
104 "mytunnel" #1: STATE_MAIN_I1: initiate
003 "mytunnel" #1: received Vendor ID payload [Dead Peer Detection]
003 "mytunnel" #1: received Vendor ID payload [FRAGMENTATION]
106 "mytunnel" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "mytunnel" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "mytunnel" #1: received Vendor ID payload [CAN-IKEv2]
004 "mytunnel" #1: STATE_MAIN_I4: ISAKMP SA established {auth=RSA_SIG cipher=aes_128 prf=sha group=MODP2048}
117 "mytunnel" #2: STATE_QUICK_I1: initiate
004 "mytunnel" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xESPESP<0xESPESP xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=passive}

If you want the tunnel to start when the machine starts, change "auto=add" to "auto=start". Also ensure that your system starts the ipsec service on boot. This can be done using the "service" or "systemctl" command, depending on the init system used for the server.