Configuring IPsec

Pre-Shared Keys (PSKs)

Sometimes you will need to connect Openswan to a device that cannot deal with RSA keys. When a VPN connection to such a device needs to be made, Openswan can use the PSK method. Imagine East is such a device. First, we would add the PSK to ipsec.secrets:

193.110.157.131 205.150.200.209 : PSK "secret shared by two hosts"

Then we set our West-East connection to use the PSK:

conn west-east left=193.110.157.131 right=205.150.200.209 authby=secret auto=start

Note that to use many PSK connections, for example if you have a lot of PSK-only network devices out in the field, you could put the authby=secret line in the conn %default section, and remove it from all the separate conn definitions.

Proper Secrets

Of course, using secret or any other human-readable word or phrase as a PSK is extremely insecure. Instead, the PSK should be generated from purely random characters. Since most vendors allow no more than 48 characters in base64 format, the following command would create a key as long as possible yet still compatible with all IP devices:

# openssl rand -base64 48

If the openssl command is not available, for instance if you are using some tiny Linux distribution on an embedded device, you can use the following, slightly less secure method:

# dd if=/dev/random count=256 bs=1 | md5sum

Note that this is not the same as using a 32-bit random string, since the output of md5sum is limited to hexadecimal characters, but it is far better than using an English word or phrase. If the md5sum command is also not available on your machine, then you might want to generate the random key elsewhere, and copy and paste the key onto the device.

If you absolutely have to use PSK, please remember to regularly change the PSK for your VPN tunnels!

Dynamic IP Addresses

In our examples so far, we have assumed that the IP addresses of the IPsec endpoints are known and do not change. This is not always the case, though often the VPN server at the office will be static, and only the connecting clients will use various unknown IP addresses.

90

Chapter 4

Hostnames

First, you could use a fully qualified domain name (FQDN) instead of an IP address. This way, if one endpoint changes IP address, as long as the DNS is changed, changes on all the connecting peers will not be necessary. Even though DNS is not secure, and anyone can spoof DNS answers, it will suffice for our use here, because all our peers have already exchanged their public RSA key or PSK. Even if some attacker spoofs the DNS, no information could leak, because the IPsec tunnel to the rogue endpoint would never get established. It is missing vital credentials—either the private RSA key or the PSK. So we can safely use:

left=west.testbed.xelerance.net

right=east.testbed.xelerance.net

Openswan would automatically resolve these DNS names to IP addresses when a connection is started. This method can be used with free DNS services, such as DynDNS.org.

Roadwarriors

While FQDNs are appropriate for infrequently changing IP addresses, it does not really address the problem of frequent IP address changes, such as in the case of a traveling laptop. We do not want to change some DNS entry every time we turn on our laptop. The issue we need to solve here is how to properly recognize an incoming, unknown IP address as our roadwarrior. This can be done by explicitly setting the ID for a connection. So far, we have not used the leftid= and rightid= option, and Openswan has automatically set our unused ID to the IP address. We can, however, choose to set it to something else. And remember, we only need to tell the other end who we are, not prove it. The security of the connection still depends on both ends having inside information about the other party, in the form of a public RSA key or a PSK.

On West, we would use:

left=west.testbed.xelerance.net

right=%any

rightid=@east

On East, we would use:

right=west.testbe.xelerance.net

left=%defaultroute

leftid=@east

When East, coming from an unknown IP address, initiates a connection to West, the two will first go through Phase 1 of the IKE negotiation. This gives them privacy. Then East will send its ID @east to West, which can then select the proper credentials (such as RSA key) for communicating to East, and finish Phase 2. Only the real East could read (and write) the required encryption.

The %any keyword is used to denote an unknown incoming IP address. The %defaultroute keyword is used to denote the current IP address we have as our outgoing IP address.

Due to the difference with %any and %defaultroute, you can't just copy such a connection definition from one end to the other. You will have to change %any to %defaultroute. It is also recommended to use left parameters for the local side of roadwarriors.

91

Configuring IPsec

For clarity, one could also switch West to use a leftid= when rightid= is used, though this is technically not necessary.

The @ symbol prevents Openswan from doing a DNS lookup on the string. This is to differentiate the string "west.testbed.xelerance.net" from the hostname west.testbed.xelerance.net. A hostname would be resolved to an IP address, which would then be used to determine the proper connection, which is not what we intend to happen here in our roadwarrior example.

Although this mechanism would allow both ends to be on dynamic IP, in practice there is the fundamental problem that neither party would know where to find the other.

The right=%any and left=%defaultroute settings cannot be used in the same connection definition. Openswan would be unable to orient this connection and would not be able to determine whether it is supposed to be left or right, even though it could possibly deduce this from the known RSA keys.

Multiple Roadwarrior Connections

This mechanism also allows for multiple connections. For instance, if we want a connection from North (also on dynamic IP) to West, we could set up the following connections:

conn west-east left=west.testbed.xelerance.net right=%any

rightid=@east leftrsasigkey=0sAQQED1....

rightrsasigkey=0sAQV7yV....

auto=add

conn west-north left=west.testbed.xelerance.net right=%any

rightid=@north leftrsasigkey=0sAQQED1....

rightrsasigkey=0sAQ5GP....

auto=add

Note that the rightrsasigkey= settings for these two entries are different. The first would contain East's public RSA key, and the second connection would contain North's public RSA key.

Dynamic IP and PSKs

There is an additional problem with PSKs that constitutes another reason not to use them. Our examples stored the PSKs based on the IP addresses of both endpoints. We can use hostnames instead of IP addresses, but how do we handle secrets and dynamic IP addresses for roadwarriors? Well, we can use the %any keyword to specify the PSK in ipsec.secrets:

193.110.158.81 %any : PSK "the passphrase"

While this works, we cannot use multiple secret entries with %any. We cannot try a bunch of PSKs one after the other for each packet, and we cannot use the rightid= to distinguish connections and pick a different PSK either. The server (West) needs to look up the secret before it can decode the client's payload containing that ID, a limitation of the current Main Mode protocol. The only way out of this dilemma is a bad one—give all the roadwarriors the same secret.

92