Chapter 4
We strongly discourage the use of one secret for a group of connections, and recommend not using PSKs with roadwarriors wherever possible. Windows and Mac OS X roadwarriors can use X.509, although if you need to support Apple roadwarriors, PSK is often the only way.
PSK and NAT
One question that is often asked is how to use PSK with dynamic IP addresses when NAT is also involved, sometimes even with port forwarding or IPsec passthrough. While you might get it to work, it will be a long painful experience. PSKs without IDs or public keys are identified based on the IP address. If the address is in any kind of way dynamic or rewritten, or port forwarded, you are asking for a lot of trouble. One thing to be aware of, if trying this type of solution in spite of the warnings, is that the file ipsec.secrets has no left-and-right-style mirroring like ipsec.conf because it is just too dangerous to mix up the PSKs of various connections.
Mixing PSK and RSA
In the past, there have been problems with Openswan correctly identifying different PSKand RSA-based connections using the %any keyword. This was due to Openswan finding out too late what kind of connection was being requested. The result was that you could only have one connection with %any, not two or more.
This problem has been partially fixed in Openswan 2.3.1. You can now have multiple RSA connections with %any, but still only one PSK connection with %any.
Connection Management
For small VPN systems, restarting the entire Openswan subsystem is not a problem. For larger systems with production tunnels though, it's obviously not an option. Openswan allows you to change connection definitions, remove them, or add new ones just by editing ipsec.conf or its include files. You can then use the ipsec auto command to activate your changes without the need to completely restart Openswan.
Command |
Description |
|
|
ipsec auto --add newconnection |
Load a new connection into Openswan. |
ipsec auto --delete connection |
Remove a connection from Openswan. If active it will first close |
|
the connection. |
ipsec auto --up connection |
Initiate a loaded connection. |
ipsec auto --down connection |
Tear the current IPsec tunnel down. |
ipsec auto --replace connection |
The equivalent to sequentially run down, delete, and add. |
ipsec auto –status |
Show a status report about connections. |
|
|
|
93 |
Configuring IPsec
To first delete, and then add a connection, you can use –-replace. If a connection is active, delete will bring it down before deletion, thereby notifying the other end.
The auto= option is ignored when using these commands explicitly, otherwise one could never change a connection from its default state. This means one can bring up a connection that has auto=ignore. It also means that to load and activate a connection, you have to use both add and up, even if auto=start is defined for the connection.
Be sure to delete a connection before removing it from ipsec.conf, otherwise you will not be able to get rid of the tunnel without a full restart, since the --delete command will no longer be able to find the removed connection section.
If you want to see only active tunnels, ipsec eroute might be a more convenient command than the status command. The status command will provide a lot more information, however. Another command that can be used is ipsec look.
If you change ipsec.secrets, you must tell Openswan to re-read the secrets using:
# ipsec auto --rereadsecrets
or you can play safe and issue:
# ipsec auto --rereadall
Subnet Extrusion
With IPsec tunnels, we can do more than just connect two existing subnets with each other. We can also move a subnet, or a part of a subnet, through an IPsec tunnel to another location. This is called subnet extrusion, as shown in the diagram below:
In this figure, packets for 193.111.228.64/30 that end up on 193.110.157.1 will now be sent further via IPsec to 209.112.44.4. Response packets travel back the same way and once they reach 193.110.157.1 will be sent plaintext onto the subnet.
Imagine we want to move a small part of Sunset, the first 64 addresses, to appear at East. We would use the following conn definition:
conn sunset-extrude left=193.110.157.131 leftsubnet=0.0.0.0/0 leftrsasigkey=0sAQ1234....
right=205.150.200.209
rightsubnet=193.111.228.0/26 rightrsasigkey=0sAQ5678....
auto=start
94
Chapter 4
The example uses RSA, but you can also use PSK if you want to. The important option is to define the leftsubnet= as the entire Internet. This will cause all packets on East with a source address in the righsubnet= range, and destination anywhere on the net, to be sent over the tunnel to West, where they are sent on into the real world. Packets from elsewhere to the sunset-extrude subnet would be sent through regular routing to West, which will then send the packets over the IPsec tunnel to East.
With KLIPS, these packets are caught by a special route entry into the ipsecN device. In this case, a route entry for 193.111.228.0/26 into an ipsec device would be added on West. For East it is a little bit more complex, as we need to catch all packets. For this we cannot use a route of 0.0.0.0/0 into the ipsec0 device, because such a route already exists for the regular physical device (for example eth0). The trick Openswan uses is to split the whole Internet into two parts, 0.0.0.0/1 and 128.0.0.0/1, and route those two subnets, which together describe the entire internet, into the ipsec0 device. This trick works because these routes are more specific than the normal default route.
With NETKEY, you will not see any special routes.
Several people use this type of setup to get more public IP addresses on their home ADSL network. Of course, one should realize that all packets to and from such a subnet will first travel to West and then to East, so if West has limited uplink capacity, this might be a problem, even if East has enough bandwidth. Though one could theoretically send the packets from East outside the IPsec tunnel, straight onto the Internet, this might be blocked by some ISPs. Most ISPs block packets with a source address that is not their own. And some ISPs check the BGP routing table and could decide these are spoofed packets. Additionally, asymmetric links are always a bit more problematic than symmetrical links, so even if the packets make it, it might still be better to first send them back to West.
You can even combine this with NAT. If you use sunset-extrude's IP behind a NAT gateway with some single ADSL IP address on it, all the packets that you do not send back through the tunnel will get translated by the NAT gateway and hit the Internet from East. This can be useful for large transfers of public data from a fixed IP address for which you don't need the encryption per se, such as an internet radio station, or a big public file repository site. With KLIPS, you can just use a host route that is more specific to point to your default outgoing interface, for instance to exclude ftp.openswan.org from your ADSL (PPTP-based) link, you could use:
# route add -host ftp.openswan.org gw yourdefaultgw dev ppp0
Since this route is more specific than the route into the ipsecN device, these packets would not be sent through the VPN tunnel, and would be translated by the NAT rules as if no IPsec setup existed. On NETKEY you would have to define a special passthrough conn:
conn pass-ftp.openswan.org left=205.150.200.209 leftsubnet=193.111.228.0/64 right=ftp.openswan.org type=passthrough authby=never
One can also use right=%any with a rightsubnet= to exclude a range of IP addresses.
95