Configuring IPsec
NAT Traversal
Before we enable NAT traversal, let us remind you of a few common problems with NAT traversal that cannot be prevented.
The most important issue is that if you are adding NAT traversal to a VPN connection for an office network that is on a private IP space, you cannot support remote clients on that same private IP space. So if you use 10.0.1.0/24 at the office, and your roadwarrior is behind ADSL on 10.0.1.2, the IPsec tunnel will fail. An IP address cannot be at both endpoints at once.
IP ranges that are used as a subnet must be excluded from NAT-Traversal usage. It is very important to pick good and small ranges for both ends. For instance, 192.168.0.0/16 is often used by ADSL modems. 10.0.0.0/8 is also frequently used. These would be poor choices for a company network IP range. Much better choices would be 10.145.1.0/24 or something similarly random. If there is an IP conflict, it is possible to do some NAT on them (outside the VPN tunnel, not inside!) but it might turn out to be more costly and problematic than just renumbering one end, especially if this is an end user's home network.
Another implication of this is that you should make your office network reasonably small. Do not pick 10.0.0.0/8 because you will be causing a huge overlap with all the home networks that you want to connect to you. Of course, this already applies to office-to-office networks as well. If you have a few hundred offices, you should pick their network ranges wisely. For instance, if you have a four digit shop number that is used internally, number the networks according to those unique digits, for instance 10.ab.cd.0/24 where abcd is the branch office number.
config setup interfaces=%defaultroute
#klipsdebug=none
#plutodebug=control nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:!10.3.4.0/24
#keep_alive=20
conn sunset-roadwarrior left=193.110.157.131 leftsubnet=10.3.4.0/24 leftrsasigkey=0sAQ....
right=%any
rightsubnet=vhost:%no,%priv rightrsasigkey=0sAQ....
auto=start
So first we enable NAT-T support for Openswan with nat_traversal=yes. Remember that NAT- T requires kernel-level support. NETKEY supports NAT-T, but for KLIPS, you must apply the NAT-T patch.
Next, we specify which IP ranges may occur behind a NAT device. In the case above, we allow the 10.0.0.0/8 and 192.168.0.0/16 ranges. The last entry, which uses an ! symbol to mean not, excludes the range 10.3.4.0/24 from being a valid range, since that is the range used for Sunset's LAN in our example.
96
Chapter 4
When a connection using NAT-T is detected, Openswan will send keep alive packets to prevent the NAT router from deleting the connection as unused. These packets are sent every 20 seconds, but this behavior can be changed using the keep_alive= option.
In this connection definition, a new line appears specifying rightsubnet=. This entry is going to match the internal IP address of the roadwarrior in a /32 subnet. The %priv contains the ranges we put in our global virtual_private range. The %no is there to signify the subnet might not be specified in all cases. This is to ensure our roadwarrior can still connect when it is not behind a NAT router. After all, when NAT-T is not triggered, no rightsubnet= would be received for that connection.
For roadwarriors to work from public IPs as well as from behind NAT, you must specify
rightsubnet=vhost:%no,%priv
Most often, this type of connection will be used not for just one roadwarrior connection, but for many different ones. They will not all be using the same RSA key. Though you could make multiple connections of these types, differentiating each with its rightid= line, there is a better way to do this using X.509 Certificates. We will discuss these in the next chapter.
Deprecated Syntax
Openswan still supports an older format for specifying NAT-related options using the subnetwithin= syntax. This code was part of the X.509 patch and accomplishes the same as the vhost= syntax, but has less flexibility. It will likely be removed in the future, so we do not recommend using this syntax.
Confirming a Functional NAT-T
If you start Openswan and the kernel supports NAT-T, you will receive a message similar to:
Aug 30 23:15:08 nsavax pluto[22096]: Starting Pluto (Openswan Version 2.1.5 X.509-1.4.8-1 PLUTO_USES_KEYRR)
Aug 30 23:15:08 nsavax pluto[22096]: including NAT-Traversal patch (Version 0.6c)
If your kernel does not support NAT-Traversal, you will see:
Aug 30 23:17:01 nsavax pluto[5862]: NAT-Traversal: ESPINUDP(1) not supported by kernel -- NAT-T disabled
If the Openswan userland (pluto) supports NAT-T but it has not been enabled in /etc/ipsec.conf, you will see a message similar to:
Aug 30 22:53:19 nsavax pluto[4818]: including NAT-Traversal patch (Version 0.6c) [disabled]
You can further confirm that NAT-Traversal is enabled and working by checking whether the host is listening on UDP ports 4500 (special NAT-T IKE). This can be done with the netstat command:
# netstat -uln |
|
|
|
Active Internet connections (only servers) |
|
||
Proto |
Recv-Q |
Send-Q Local Address |
Foreign Address State |
udp 0 |
0 |
127.0.0.1:4500 |
0.0.0.0:* |
97