Other configuration possibilities

This document describes various options for FreeS/WAN configuration which are less used or more complex (often both) than the standard cases described in our basic configuration document.

Choosing connection types

The first major decision you need to make before configuring additional connections is what type or types of connections you will use. There are several options, and you can use more than one concurrently.

Manual vs. automatic keying

IPsec allows two types of connections, with manual or automatic keying. FreeS/WAN starts them with commands such as:

        ipsec manual --start name
        ipsec auto --up name

The difference is in how they are keyed.

Manually keyed connections

use keys stored in ipsec.conf .

Automatically keyed connections

use keys automatically generated by the Pluto key negotiation daemon. The key negotiation protocol, IKE , must authenticate the other system. (It is vulnerable to a man-in-the-middle attack if used without authentication.) We currently support two authentication methods:

• using shared secrets stored in ipsec.secrets.
• RSA public key authentication, with our machine's private key in ipsec.secrets. Public keys for other machines may either be placed in ipsec.conf or provided via DNS.

Manually keyed connections provide weaker security than automatically keyed connections. An opponent who gets a key gets all data encrypted by it. We discuss using manual keying in production below, but this is not recommended except in special circumstances, such as needing to communicate with some implementation that offers no auto-keyed mode compatible with FreeS/WAN. Manual keying is useful for testing.

With automatically-(re)-keyed connections, the keys change often so an opponent who gets one key does not get a large amount of data. An opponent who gets a shared secret, or your private key if public key authentication is used, does not automatically gain access to any encryption keys or any data. Once your authentication mechanism has been subverted you have no way to prevent the attacker getting keys and data, but the attacker still has to work for them.

Authentication methods for auto-keying

The IKE protocol which Pluto uses to negotiate connections between gateways must use some form of authentication of peers. A gateway must know who it is talking to before it can create a secure connection. We currently support two methods for this authentication:

• shared secrets
• RSA authentication

See our links section for information on user-contributed patches which provide a third mechanism:

• authentication with x.509 certificates

As a long-term goal, FreeS/WAN plans to support distribution of public keys for authentication via secure DNS. This would allow us to support opportunistic encryption. Any two FreeS/WAN gateways could provide secure communication, without either of them having any preset information about the other.

Advantages of public key methods

Authentication with a public key method such as RSA has some important advantages over using shared secrets.

• no problem of secure transmission of secrets
  • A shared secret must be shared, so you have the problem of transmitting it securely to the other party. If you get this wrong, you have no security.
  • With a public key technique, you transmit only your public key. The system is designed to ensure that it does not matter if an enemy obtains public keys. The private key never leaves your machine.
• easier management
  • Suppose you have 20 branch offices all connecting to one gateway at head office, and all using shared secrets. Then the head office admin has 20 secrets to manage. Each of them must be kept secret not only from outsiders, but also from 19 of the branch office admins. The branch office admins have only one secret each to manage.

  If the branch offices need to talk to each other, this becomes problematic. You need another 20*19/2 = 190 secrets for branch-to-branch communication, each known to exactly two branches. Now all the branch admins have the headache of handling 20 keys, each shared with exactly one other branch or with head office.

  For larger numbers of branches, the number of connections and secrets increases quadratically and managing them becomes a nightmare. A 1000-gateway fully connected network needs 499,500 secrets, each known to exactly two players. There are ways to reduce this problem, for example by introducing a central key server, but these involve additional communication overheads, more administrative work, and new threats that must be carefully guarded against.

• With public key techniques, the only thing you have to keep secret is your private key, and you keep that secret from everyone.

As network size increaes, the number of public keys used increases linearly with the number of nodes. This still requires careful administration in large applications, but is nothing like the disaster of a quadratic increase. On a 1000-gateway network, you have 1000 private keys, each of which must be kept secure on one machine, and 1000 public keys which must be distributed. This is not a trivial problem, but it is manageable.

There is also a disadvantage:

• your private key is a single point of attack, extremely valuable to an enemy
  • with shared secrets, an attacker who steals your ipsec.secrets file can impersonate you or try man-in-the-middle attacks, but can only attack connections described in that file
  • an attacker who steals your private key gains the chance to attack not only existing connections but also any future connections created using that key

This is partly counterbalanced by the fact that the key is never transmitted and remains under your control at all times. It is likely necessary, however, to take account of this in setting security policy. For example, you should change gateway keys when an administrator leaves the company, and should change them periodically in any case.

Overall, public key methods are more secure, more easily managed and more flexible. We recommend that they be used for all connections, unless there is a compelling reason to do otherwise.

Using shared secrets in production

Generally, public key methods are preferred for reasons given above, but shared secrets can be used with no loss of security, just more work and perhaps more need to take precautions.

Putting secrets in ipsec.secrets(5)

If shared secrets are to be used to authenticate communication for the Diffie-Hellman key exchange in the IKE protocol, then those secrets must be stored in /etc/ipsec.secrets . For details, see the ipsec.secrets(5) man page.

A few considerations are vital:

• make the secrets long and unguessable. Since they need not be remembered by humans, very long ugly strings may be used. We suggest using our ipsec_ranbits(8) utility to generate long (128 bits or more) random strings.
• transmit secrets securely. You have to share them with other systems, but you lose if they are intercepted and used against you. Use PGP, SSH , hand delivery of a floppy disk which is then destroyed, or some other trustworthy method to deliver them.
• store secrets securely, in root-owned files with permissions rw------.
• limit sharing of secrets. Alice, Bob, Carol and Dave may all talk to each other, but only Alice and Bob should know the secret for an Alice-Bob link.
• do not share private keys. The private key for RSA authentication of your system is stored in ipsec.secrets(5), but it is a different class of secret from the pre-shared keys used for the "shared secret" authentication. No-one but you should have the RSA private key.

Each line has the IP addresses of the two gateways plus the secret. It should look something like this:

        10.0.0.1 11.0.0.1 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"

PSK indicates the use of a pre-s hared key. The quotes and the whitespace shown are required.

You can use any character string as your secret. For security, it should be both long and extremely hard to guess. We provide a utility to generate such strings, ipsec_ranbits(8).

You want the same secret on the two gateways used, so you create a line with that secret and the two gateway IP addresses. The installation process supplies an example secret, useful only for testing. You must change it for production use.

File security

You must deliver this file, or the relevant part of it, to the other gateway machine by some secure means. Don't just FTP or mail the file! It is vital that the secrets in it remain secret. An attacker who knew those could easily have all the data on your "secure" connection.

This file must be owned by root and should have permissions rw-------.

Shared secrets for road warriors

You can use a shared secret to support a single road warrior connecting to your gateway, and this is a reasonable thing to do in some circumstances. Public key methods have advantages, discussed above, but they are not critical in this case.

To do this, the line in ipsec.secrets(5) is something like:

        10.0.0.1 0.0.0.0 : PSK "jxTR1lnmSjuj33n4W51uW3kTR55luUmSmnlRUuWnkjRj3UuTV4T3USSu23Uk55nWu5TkTUnjT"

For more than one road warrior, shared secrets are not recommended. If shared secrets are used, then when the responder needs to look up the secret, all it knows about the sender is an IP address. This is fine if the sender is at a fixed IP address specified in the config file. It is also fine if only one road warrior uses the wildcard 0.0.0.0 address. However, if you have more than one road warrior using shared secret authentication, then they must all use that wildcard and therefore all road warriors using PSK autentication must use the same secret. Obviously, this is insecure.

For multiple road warriors, use public key authentication. Each roadwarrior can then have its own identity (our leftid= or rightid= parameters), its own public/private key pair, and its own secure connection.

Using manual keying in production

Generally, automatic keying is preferred over manual keying for production use because it is both easier to manage and more secure. Automatic keying frees the admin from much of the burden of managing keys securely, and can provide perfect forward secrecy.

However, it is possible to use manual keying in production if that is what you want to do. This might be necessary, for example, in order to interoperate with some device that either does not provide automatic keying or provides it in some version we cannot talk to.

Note that with manual keying all security rests with the keys. If an adversary acquires your keys, you've had it. He or she can read everything ever sent with those keys, including old messages he or she may have archived. You need to be really paranoid about keys if you're going to rely on manual keying for anything important.

• keep keys in files with 600 permissions, owned by root
• be extremely careful about security of your gateway systems. Anyone who breaks into a gateway and gains root privileges can get all your keys and read everything ever encrypted with those keys, both old messages he has archived and any new ones you may send.
• change keys regularly. This can be a considerable bother, (and provides an excellent reason to consider automatic keying instead), but it is absolutely essential for security. Consider a manually keyed system in which you leave the same key in place for months:
  • an attacker can have a very large sample of text sent with that key to work with. This makes various cryptographic attacks much more likely to succeed.
  • The chances of the key being compromised in some non-cryptographic manner -- a spy finds it on a discarded notepad, someone breaks into your server or your building and steals it, a staff member is bribed, tricked, seduced or coerced into revealing it, etc. -- also increase over time.
  • a successful attacker can read everything ever sent with that key. This makes any successful attack extremely damaging.
  It is clear that you must change keys often to have any useful security. The only question is how often.
• use PGP or SSH for all key transfers
• don't edit files with keys in them when someone can look over your shoulder
• worry about network security; could someone get keys by snooping packets on the LAN between your X desktop and the gateway?
• lock up your backup tapes for the gateway system
• ... and so on

Linux FreeS/WAN provides some facilities to help with this. In particular, it is good policy to keep keys in separate files so you can edit configuration information in /etc/ipsec.conf without exposing keys to "shoulder surfers" or network snoops. We support this with the also= and include syntax in ipsec.conf(5).

See the last example in our examples file. In the /etc/ipsec.conf conn samplesep section, it has the line:

        also=samplesep-keys

which tells the "ipsec manual" script to insert the configuration description labelled "samplesep-keys" if it can find it. The /etc/ipsec.conf file must also have a line such as:

include ipsec.*.conf

which tells it to read other files. One of those other files then might contain the additional data:

conn samplesep-keys
  spi=0x200
  esp=3des-md5-96
  espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
  espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf

The first line matches the label in the "also=" line, so the indented lines are inserted. The net effect is exactly as if the inserted lines had occurred in the original file in place of the "also=" line.

Variables set here are:

spi

A number needed by the manual keying code. Any 3-digit hex number will do, but if you have more than one manual connection then spi must be different for each connection.

esp

Options for ESP (Encapsulated Security Payload), the usual IPsec encryption mode. Settings here are for encryption using triple DES and authentication using MD5. Note that encryption without authentication should not be used; it is insecure.

espenkey

Key for ESP encryption. Here, a 192-bit hex number for triple DES.

espauthkey

Key for ESP authentication. Here, a 128-bit hex number for MD5.

Note that the example keys we supply are intended only for testing. For real use, you should go to automatic keying. If that is not possible, create your own keys for manual mode and keep them secret

Of course, any files containing keys must have 600 permissions and be owned by root.

If you connect in this way to multiple sites, we recommend that you keep keys for each site in a separate file and adopt some naming convention that lets you pick them all up with a single "include" line. This minimizes the risk of losing several keys to one error or attack and of accidentally giving another site admin keys which he or she has no business knowing.

Also note that if you have multiple manually keyed connections on a single machine, then the spi parameter must be different for each one. Any 3-digit hex number is OK, provided they are different for each connection. We reserve the range 0x100 to 0xfff for manual connections. Pluto assigns SPIs from 0x1000 up for automatically keyed connections.

If ipsec.conf(5) contains keys for manual mode connections, then it too must have permissions rw-------. We recommend instead that, if you must manual keying in production, you keep the keys in separate files.

Note also that ipsec.conf is installed with permissions rw-r--r--. If you plan to use manually keyed connections for anything more than initial testing, you must:

• either change permissions to rw-------
• or store keys separately in secure files and access them via include statements in ipsec.conf .

We recommend the latter method for all but the simplest configurations.

Creating keys with ranbits

You can create new random keys with the ranbits(8) utility. For example, the commands:

      umask 177
      ipsec ranbits 192  > temp
      ipsec ranbits 128 >> temp

create keys in the sizes needed for our default algorithms:

• 192-bit key for 3DES encryption
  (only 168 bits are used; parity bits are ignored)
• 128-bit key for keyed MD5 authentication

If you want to use SHA instead of MD5, that requires a 160-bit key

Note that any temporary files used must be kept secure since they contain keys. That is the reason for the umask command above. The temporary file should be deleted as soon as you are done with it. You may also want to change the umask back to its default value after you are finished working on keys.

The ranbits utility may pause for a few seconds if not enough entropy is available immediately. See ipsec_ranbits(8) and random(4) for details. You may wish to provide some activity to feed entropy into the system. For example, you might move the mouse around, type random characters, or do du /usr > /dev/null in the background.

Setting up connections at boot time

You can tell the system to set up connections automatically at boot time by putting suitable stuff in /etc/ipsec.conf on both systems. The relevant section of the file is labelled by a line reading config setup.

Details can be found in the ipsec.conf(5) man page. We also provide a file of example configurations.

The most likely options are something like:

interfaces="ipsec0=eth0 ipsec1=ppp0"

Tells KLIPS which interfaces to use. Up to four interfaces numbered ipsec[0-3] are supported. Each interface can support an arbitrary number of tunnels.

Note that for PPP, you give the ppp[0-9] device name here, not the underlying device such as modem (or eth1 if you are using PPPoE).

interfaces=%defaultroute

Alternative setting, useful in simple cases. KLIPS will pick up both its interface and the next hop information from the settings of the Linux default route.

forwardcontrol=no

Normally "no". Set to "yes" if the IP forwarding option is disabled in your network configuration. (This can be set as a kernel configuration option or later. e.g. on Redhat, it's in /etc/sysconfig/network and on SuSE you can adjust it with Yast.) Linux FreeS/WAN will then enable forwarding when starting up and turn it off when going down. This is used to ensure that no packets will be forwarded before IPsec comes up and takes control.

syslog=daemon.error

Used in messages to the system logging daemon (syslogd) to specify what type of software is sending the messages. If the settings are "daemon.error" as in our example, then syslogd treats the messages as error messages from a daemon.

Note that Pluto does not currently pay attention to this variable. The variable controls setup messages only.

klipsdebug=

Debug settings for KLIPS.

plutodebug=

Debug settings for Pluto.

... for both the above DEBUG settings

Normally, leave empty as shown above for no debugging output.
Use "all" for maximum information.
See ipsec_klipsdebug(8) and ipsec_pluto(8) man page for other options. Beware that if you set /etc/ipsec.conf to enable debug output, your system's log files may get large quickly.

dumpdir=/safe/directory

Normally, programs started by ipsec setup don't crash. If they do, by default, no core dump will be produced because such dumps would contain secrets. If you find you need to debug such crashes, you can set dumpdir to the name of a directory in which to collect the core file.

manualstart=

List of manually keyed connections to be automatically started at boot time. Useful for testing, but not for long term use. Connections which are automatically started should also be automatically re-keyed.

pluto=yes

Whether to start Pluto when ipsec startup is done.
This parameter is optional and defaults to "yes" if not present.

"yes" is strongly recommended for production use so that the keying daemon (Pluto) will automatically re-key the connections regularly. The ipsec-auto parameters ikelifetime, ipseclifetime and reykeywindow give you control over frequency of rekeying.

plutoload="reno-van reno-adam reno-nyc"

List of tunnels (by name, e.g. fred-susan or reno-van in our examples) to be loaded into Pluto's internal database at startup. In this example, Pluto loads three tunnels into its database when it is started.

If plutoload is "%search", Pluto will load any connections whose description includes "auto=add" or "auto=start".

plutostart="reno-van reno-adam reno-nyc"

List of tunnels to attempt to negotiate when Pluto is started.

If plutostart is "%search", Pluto will start any connections whose description includes "auto=start".

Note that, for a connection intended to be permanent, both gateways should be set try to start the tunnel. This allows quick recovery if either gateway is rebooted or has its IPsec restarted. If only one gateway is set to start the tunnel and the other gateway restarts, the tunnel may not be rebuilt.

plutowait=no

Controls whether Pluto waits for one tunnel to be established before starting to negotiate the next. You might set this to "yes"

• if your gateway is a very limited machine and you need to conserve resources.
• for debugging; the logs are clearer if only one connection is brought up at a time

For a busy and resource-laden production gateway, you likely want "no" so that connections are brought up in parallel and the whole process takes less time.

The example assumes you are at the Reno office and will use IPsec to Vancouver, New York City and Amsterdam.

Multiple tunnels between the same two gateways

Consider a pair of subnets, each with a security gateway, connected via the Internet:

         192.168.100.0/24           left subnet
              |
         192.168.100.1
         North Gateway
         101.101.101.101            left
              |
         101.101.101.1              left next hop
         [Internet]
         202.202.202.1              right next hop
              |
         202.202.202.202            right
         South gateway
         192.168.200.1
              |
         192.168.200.0/24           right subnet

A tunnel specification such as:

conn northnet-southnet
      left=101.101.101.101
      leftnexthop=101.101.101.1
      leftsubnet=192.168.100.0/24
      leftfirewall=yes
      right=202.202.202.202
      rightnexthop=202.202.202.1
      rightsubnet=192.168.200.0/24
      rightfirewall=yes

However, this does not cover other traffic you might want to secure. To handle all the possibilities, you might also want these connection descriptions:

conn northgate-southnet
      left=101.101.101.101
      leftnexthop=101.101.101.1
      right=202.202.202.202
      rightnexthop=202.202.202.1
      rightsubnet=192.168.200.0/24
      rightfirewall=yes

conn northnet-southgate
      left=101.101.101.101
      leftnexthop=101.101.101.1
      leftsubnet=192.168.100.0/24
      leftfirewall=yes
      right=202.202.202.202
      rightnexthop=202.202.202.1

Without these, neither gateway can do IPsec to the remote subnet. There is no IPsec tunnel or eroute set up for the traffic.

In our example, with the non-routable 192.168.* addresses used, packets would simply be discarded. In a different configuration, with routable addresses for the remote subnet, they would be sent unencrypted since there would be no IPsec eroute and there would be a normal IP route.

You might also want:

conn northgate-southgate
      left=101.101.101.101
      leftnexthop=101.101.101.1
      right=202.202.202.202
      rightnexthop=202.202.202.1

This is required if you want the two gateways to speak IPsec to each other.

This requires a lot of duplication of details. Judicious use of also= and include can reduce this problem.

Note that, while FreeS/WAN supports all four tunnel types, not all implementations do. In particular, some versions of Windows 2000 and the freely downloadable version of PGP provide only "client" functionality. You cannot use them as gateways with a subnet behind them. To get that functionality, you must upgrade to Windows 2000 server or the commercially available PGP products.

One tunnel plus advanced routing

Subject: Re: linux-ipsec: IPSec packets not entering tunnel?
   Date: Mon, 20 Nov 2000
   From: Justin Guyett <jfg@sonicity.com>

On Mon, 20 Nov 2000, Claudia Schmeing wrote:

> Right                                                         Left
>                      "home"                "office"
> 10.92.10.0/24 ---- 24.93.85.110 ========= 216.175.164.91 ---- 10.91.10.24/24
>
> I've created all four tunnels, and can ping to test each of them,
> *except* homegate-officenet.

I keep wondering why people create all four tunnels.  Why not route
traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?
And 99% of the time you don't need to access "office" directly, which
means you can eliminate all but the subnet<->subnet connection.

> I keep wondering why people create all four tunnels.  Why not route
> traffic generated from home to 10.91.10.24/24 out ipsec0 with iproute2?

This is feasible, given some iproute2 attention to source addresses, but
it isn't something we've documented yet... (partly because we're still
making some attempt to support 2.0.xx kernels, which can't do this, but
mostly because we haven't caught up with it yet).

> And 99% of the time you don't need to access "office" directly, which
> means you can eliminate all but the subnet<->subnet connection.

Correct in principle, but people will keep trying to ping to or from the
gateways during testing, and sometimes they want to run services on the
gateway machines too.

Extruded Subnets

What we call extruded subnets are a special case of VPNs.

If your buddy has some unused IP addresses, in his subnet far off at the other side of the Internet, he can loan them to you... provided that the connection between you and him is fast enough to carry all the traffic between your machines and the rest of the Internet. In effect, he "extrudes" a part of his address space over the network to you, with your Internet traffic appearing to originate from behind his Internet gateway.

Suppose your friend has a.b.c.0/24 and wants to give you a.b.c.240/28. The initial situation is:

    subnet           gateway          Internet
  a.b.c.0/24    a.b.c.1    p.q.r.s

Of course it is quite normal for various smaller subnets to exist behind your friend's gateway. For example, your friend's company might have a.b.c.16/28=development, a.b.c.32/28=marketing and so on. The Internet neither knows not cares about this; it just delivers packets to the p.q.r.s and lets the gateway do whatever needs to be done from there.

What we want to do is take a subnet, perhaps a.b.c.240/28, out of your friend's physical location while still having your friend's gateway route to it. As far as the Internet is concerned, you remain behind that gateway.

    subnet           gateway          Internet       your gate  extruded

  a.b.c.0/24   a.b.c.1     p.q.r.s              d.e.f.g         a.b.c.240/28                

                           ========== tunnel ==========

The extruded addresses have to be a complete subnet.

In our example, the friend's security gateway is also his Internet gateway, but this is not necessary. As long as all traffic from the Internet to his addresses passes through the Internet gate, the security gate could be a machine behind that. The IG would need to route all traffic for the extruded subnet to the SG, and the SG could handle the rest.

First, configure your subnet using the extruded addresses. Your security gateway's interface to your subnet needs to have an extruded address (possibly using a Linux virtual interface, if it also has to have a different address). Your gateway needs to have a route to the extruded subnet, pointing to that interface. The other machines at your site need to have addresses in that subnet, and default routes pointing to your gateway.

If any of your friend's machines need to talk to the extruded subnet, they need to have a route for the extruded subnet, pointing at his gateway.

Then set up an IPsec subnet-to-subnet tunnel between your gateway and his, with your subnet specified as the extruded subnet, and his subnet specified as "0.0.0.0/0". Do it with manual keying first for testing, and then with automatic keying for production use.

The tunnel description should be:

conn extruded
        left=p.q.r.s
        leftsubnet=0.0.0.0/0
        right=d.e.f.g
        rightsubnet=a.b.c.0/28

If either side was doing firewalling for the extruded subnet before the IPsec connection is set up, ipsec_manual and ipsec_auto need to know about that (via the {left|right}firewall parameters) so that it can be overridden for the duration of the connection.

And it all just works. Your SG routes traffic for 0.0.0.0/0 -- that is, the whole Internet -- through the tunnel to his SG, which then sends it onward as if it came from his subnet. When traffic for the extruded subnet arrives at his SG, it gets sent through the tunnel to your SG, which passes it to the right machine.

Remember that when ipsec_manual or ipsec_auto takes a connection down, it does not undo the route it made for that connection. This lets you take a connection down and bring up a new one, or a modified version of the old one, without having to rebuild the route it uses and without any risk of packets which should use IPsec accidentally going out in the clear. Because the route always points into KLIPS, the packets will always go there. Because KLIPS temporarily has no idea what to do with them (no eroute for them), they will be discarded.

If you do want to take the route down, this is what the "unroute" operation in manual and auto is for. Just do an unroute after doing the down.

Note that the route for a connection may have replaced an existing non-IPsec route. Nothing in Linux FreeS/WAN will put that pre-IPsec route back. If you need it back, you have to create it with the route command.

Road Warrior with virtual IP address

Here is a mailing list message about another way to configure for road warrior support:

Subject: Re: linux-ipsec: understanding the vpn
   Date: Thu, 28 Oct 1999 10:43:22 -0400
   From: Irving Reid <irving@nevex.com>

>  local-------linux------internet------mobile
>  LAN        box                         user
>  ...

>  now when the mobile user connects to the linux box
>  it is given a virtual IP address, i have configured it to
>  be in the 10.x.x.x range. mobile user and linux box 
>  have a tunnel between them with these IP addresses.

>   Uptil this all is fine.

If it is possible to configure your mobile client software *not* to
use a virtual IP address, that will make your life easier. It is easier
to configure FreeS/WAN to use the actual address the mobile user gets
from its ISP.

Unfortunately, some Windows clients don't let you choose.

>  what i would like to know is that how does the mobile
>  user communicate with other computers on the local
>  LAN , of course with the vpn ?

>   what IP address should the local LAN 
>  computers have ? I guess their default gateway 
>  should be the linux box ? and does the linux box need
>  to be a 2 NIC card box or one is fine.

As someone else stated, yes, the Linux box would usually be the default
IP gateway for the local lan.

However...

If you mobile user has software that *must* use a virtual IP address,
the whole picture changes. Nobody has put much effort into getting
FreeS/WAN to play well in this environment, but here's a sketch of one
approach:

Local Lan 1.0.0.0/24
    |
    +- Linux FreeS/WAN 1.0.0.2
    |
    | 1.0.0.1
 Router
    | 2.0.0.1
    |
Internet
    |
    | 3.0.0.1
Mobile User
      Virtual Address: 1.0.0.3

Note that the Local Lan network (1.0.0.x) can be registered, routable
addresses.

Now, the Mobile User sets up an IPSec security association with the
Linux box (1.0.0.2); it should ESP encapsulate all traffic to the
network 1.0.0.x **EXCEPT** UDP port 500. 500/udp is required for the key
negotiation, which needs to work outside of the IPSec tunnel.

On the Linux side, there's a bunch of stuff you need to do by hand (for
now). FreeS/WAN should correctly handle setting up the IPSec SA and
routes, but I haven't tested it so this may not work...

The FreeS/WAN conn should look like:

conn mobile
        right=1.0.0.2
        rightsubnet=1.0.0.0/24
        rightnexthop=1.0.0.1
        left=0.0.0.0  # The infamous "road warrior"
        leftsubnet=1.0.0.3/32

Note that the left subnet contains *only* the remote host's virtual
address.

Hopefully the routing table on the FreeS/WAN box ends up looking like
this:

% netstat -rn
Kernel IP routing table
Destination     Gateway      Genmask         Flags   MSS Window  irtt Iface
1.0.0.0         0.0.0.0      255.255.255.0   U      1500 0          0 eth0
127.0.0.0       0.0.0.0      255.0.0.0       U      3584 0          0 lo
0.0.0.0         1.0.0.1      0.0.0.0         UG     1500 0          0 eth0
1.0.0.3         1.0.0.1      255.255.255.255 UG     1433 0          0 ipsec0

So, if anybody sends a packet for 1.0.0.3 to the Linux box, it should
get bundled up and sent through the tunnel. To get the packets for
1.0.0.3 to the Linux box in the first place, you need to use "proxy
ARP".

How this works is: when a host or router on the local Ethernet segment
wants to send a packet to 1.0.0.3, it sends out an Ethernet level
broadcast "ARP request". If 1.0.0.3 was on the local LAN, it would
reply, saying "send IP packets for 1.0.0.3 to my Ethernet address".

Instead, you need to set up the Linux box so that _it_ answers ARP
requests for 1.0.0.3, even though that isn't its IP address. That
convinces everyone else on the lan to send 1.0.0.3 packets to the Linux
box, where the usual FreeS/WAN processing and routing take over.

% arp -i eth0 -s 1.0.0.3 -D eth0 pub

This says, if you see an ARP request on interface eth0 asking for
1.0.0.3, respond with the Ethernet address of interface eth0.

Now, as I said at the very beginning, if it is *at all* possible to
configure your client *not* to use the virtual IP address, you can avoid
this whole mess.

Dynamic Network Interfaces

Sometimes you have to cope with a situation where the network interface(s) aren't all there at boot. The common example is notebooks with PCMCIA.

Basics

The key issue here is that the config setup section of the /etc/ipsec.conf configuration file lists the connection between ipsecN and hardware interfaces, in the interfaces= variable. At any time when ipsec setup start or ipsec setup restart is run this variable must correspond to the current real situation. More precisely, it must not mention any hardware interfaces which don't currently exist. The difficulty is that an ipsec setup start command is normally run at boot time so interfaces that are not up then are mis-handled.

Boot Time

Normally, an ipsec setup start is run at boot time. However, if the hardware situation at boot time is uncertain, one of two things must be done.

• One possibility is simply not to have IPsec brought up at boot time. To do this:

        chkconfig --level 2345 ipsec off

That's for modern Red Hats or other Linuxes with chkconfig. Systems which lack this will require fiddling with symlinks in /etc/rc.d/rc?.d or the equivalent.
• Another possibility is to bring IPsec up with no interfaces, which is less aesthetically satisfying but simpler. Just put

        interfaces=

in the configuration file. KLIPS and Pluto will be started, but won't do anything.

Change Time

When the hardware *is* in place, IPsec has to be made aware of it. Someday there may be a nice way to do this.

Right now, the way to do it is to fix the /etc/ipsec.conf file appropriately, so interfaces reflects the new situation, and then restart the IPsec subsystem. This does break any existing IPsec connections.

If IPsec wasn't brought up at boot time, do

        ipsec setup start

        ipsec setup restart

If some of the hardware is to be taken out, before doing that, amend the configuration file so interfaces no longer includes it, and do

        ipsec setup restart

Again, this breaks any existing connections.

Unencrypted tunnels

Sometimes you might want to create a tunnel without encryption. Often this is a bad idea, even if you have some data which need not be private. See this discussion.

The IPsec protocols provide two ways to do build such tunnels:

using ESP with null encryption

not supported by FreeS/WAN

using AH without ESP

supported for manually keyed connections

possible with explicit commands via ipsec_whack(8) (see this list message)

not supported in the ipsec_auto(8) scripts.

There are several ways to handle this.

• Just accept the overhead of double encryption. The site admins might choose this if any of the following apply:
  • policy says encrypt everything (usually, it should)
  • they don't entirely trust Alice and Bob (usually, if they don't have to, they shouldn't)
  • if they don't feel the saved cycles are worth the time they'd need to build a non-encrypted tunnel for Alice and Bob's packets (often, they aren't)
• Use a plain IP-in-IP tunnel. These are not well documented. A good starting point is in the Linux kernel source tree, in /usr/src/linux/drivers/net/README.tunnel.
• Use a manually-keyed AH-only tunnel.

Note that if Alice and Bob want end-to-end security, they must build a tunnel end-to-end between their machines or use some other end-to-end tool such as PGP or SSL that suits their data. The only question is whether the admins build some special unencrypted tunnel for those already-encrypted packets.