Linux FreeS/WAN Configuration

• RTFM
• Simplifying ipsec.conf files
• Choosing your connection types
• Setting up various types
  • Using RSA authentication
    • RSA signature examples
  • Using shared secrets in production
  • Using manual keying in production
• Setting up connections at boot time
• Multiple tunnels between a pair of gateways
• Many tunnels from a single gateway
• Variations on IPSEC
  • Extruded Subnets
  • Road Warrior support
  • Dynamic Network Interfaces
  • Unencrypted Tunnels

Our Setup document covers installation and testing of the Linux FreeS/WAN IPSEC implementation. If you have not yet read that, you should probably go there first.

The Setup document should get you to the point where you have a working FreeS/WAN installation. Of course, a working installation is not all you need for a production system. You still have to configure it for your requirements and circumstances. That is covered here.

RTFM (please Read The Fine Manuals)

You will need to refer to the manual pages for various things. We provide an HTML list of man pages with links to HTML versions of the pages themselves. The pages are of course also available via the man command.

For configuration, the critical page is ipsec.conf(5). You will also need to refer to ipsec.secrets(5). Others which may be relevant include ipsec_manual(8), ipsec_auto(8), ipsec_pluto(8) and ipsec_rsasigkey(8).

• a conn %default connection description for information common to all connections
• also= lines allow a piece of a description to be defined in one place and used in several (the definition must be after all references)
• include directives allow information to be stored in separate files but used as part of the configuration

conn %default
        type=tunnel
        pfs=yes
        keylife=2h
        authby=rsasig                   # all connections use RSA authentication
        keyingtries=1                   # road warrior can retry, we shouldn't
        # some parameters are common to all remote systems
        right=0.0.0.0                   # accept from any address

# pick up all remote system descriptions
# uses shell wildcards
include /etc/ipsec/remote.*.conn

# left side of all connections is the same
# define it after the descriptions which use it
conn leftstuff
        left=101.101.101.101
        leftnexthop=101.101.101.1
        leftsubnet=202.202.202.0/24
        leftid=@gateway.example.org

conn myname
        # pick up common info for all connections
        also=leftstuff
        # identify the remote machine
        rightid=@myname.example.org
        rightrsasigkey=0xfc641fd6d9a24...
        # we cannot use auto= in default or an also= section
        # so do it here
        auto=load                       # load, but don't start

Note that if auto=load or auto=start paraneters are used, they must be in the actual connection descriptions. Neither putting them in the conn default section nor including them via an also= line will work.

Choosing your connection types

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

• authentication with x.509 certificates (current for an older version of FreeS/WAN)

This is not implemented in this release.

Advantages of public key methods

• 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 connections, all using shared secrets. Then you have 20 secrets to manage, each of which should be kept secret not only from outsiders, but also from the 19 administrators for other connections. This may be possible with 20 connections, but rapidly becomes problematic for large numbers.
  • With public key techniques, the only thing you have to keep secret is your private key, and you keep that secret from everyone.
• does not require fixed IP addresses
  • When shared secrets are used in IPSEC, the responder must be able to tell which secret to use by looking at the IP address on the incoming packets. When the other parties do not have a fixed IP address to be identified by (for example, on nearly all dialup ISP connections and many cable or ADSL links), this does not work well -- all must share the same secret!
  • When RSA authentication is in use, the initiator can identify itself by name before the key must be determined. The responder then checks that the message is signed with the public key corresponding to that name.

• 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

Overall, public key methods are more secure, more easily managed and more flexible. We recommend that they be used for most connections.

Note, however, that the RSA algorithm is patented in the US and that the FreeS/WAN project has not obtained a license under that patent. Until September 20, 2000 when the patent runs out, US users who do not have their own licenses will be violating the patent if they use RSA authentication. You can disable the feature entirely by setting the NO_RSA option in the Pluto Makefile.

Here are the steps to using RSA authentication. See the pluto(8), ipsec.conf(5) and ipsec.secrets(5) man pages for additional detail if required.

1. On each gateway, generate an RSA key pair (private and public) using ipsec_rsasigkey(8).
2. Put the private key in ipsec.secrets , with a wrapper. The result looks like this:

   : RSA {
         <stuff generated by rsasigkey>
         }
   

   Note that:
   • the ":" must be unindented (at the margin)
   • the other lines, including the "}", must be indented (not at the margin)
   • spaces are needed to separate tokens so, for example, ":RSA{" won't work.
   This means "always use this as my private RSA key". For other options, for example if you want to use different keys with different partners, see the man pages.
3. Tell everyone your public key. It will be the comment in the output of rsasigkey starting "#pubkey=0x".
4. Mark the conn descriptions which will use this method with the line "authby=rsasig".
5. Put public keys for systems you will communicate with in the conn descriptions of ipsec.conf(5). Add the public key for left as "leftrsasigkey=" followed by the (long!) number from the #pubkey comment, stating with the 0x. Ditto for "rightrsasigkey=". Pluto will only care about the one for the other side (at least for now).
6. Put the identifiers you will use in the "leftid=" and "rightid=" lines of your ipsec.conf(5) conn entries. These are the names the systems use to identify themselves during connection negotiation.

   There are four possible forms:

   • an IP address in dotted quad notation, four numbers separated by periods (10.1.19.32).
   • a domain name, which will be resolved immediately (bad.example.com).
   • a fully qualified domain name (FQDN) with a leading "@" to indicate that it should not be resolved (@good.example.com)
   • user@FQDN
   We recommend that only the @FQDN form be used in most applications. IP addresses make remarkably uninteresting names. Resolving a name to an IP address is not interesting in this context, and attempting to resolve it may cause problems if DNS is down or if someone subverts a DNS server which you rely on.

   If your domain is example.com, the names you use should be of three types:

   • machine names such as "@firewall.example.com".
   • names for other resources, chosen not to conflict, such as "@fireplug.example.com"
   • identifiers for people, such as "alice@example.com" or, if she prefers, "cleopatra@example.com".
   In order to facilitate distributing keys through DNS, we recommend avoiding
   • names from non-existent domains
   • names from other people's domains
   • names which conflict with machine names in your domain
   • user@FQDN
   For example, if you have a server alice.example.com, then you should not use "@alice.example.com" to identify Alice's laptop for IPSEC.

conn whatever
        authby=rsasig
        auto=start
        left=101.101.101.101
        leftnexthop=101.101.101.1
        leftsubnet=192.168.100.47/24    # non-routable RFC 1918 subnet
        leftfirewall=yes                # so we need this line [only works with ipfwadm]
        leftrsasigkey=0x400d1000351e27e667bf642ef700...
        leftid=@gateway.example.org
        right=202.202.202.202
        rightnexthop=202.202.202.1
        rightsubnet=203.203.203.0/24    # routable subnet
        rightrsasigkey=0xfc641fd6d9a2444b7e4b8e732b9d1...
        rightid=@remotegate.example.org

To support multiple road warriors connecting to one gateway, you need do nothing special on the road warrior side (but be sure to restart whenever a public link comes up). A conn description for one of them might be:

conn whatever
        authby=rsasig
        auto=start
        left=101.101.101.101
        leftnexthop=101.101.101.1
        leftsubnet=192.168.100.47/24    # non-routable RFC 1918 subnet
        leftfirewall=yes                # so we need this line
        leftrsasigkey=0x2ef700d6ddfdbc19...
        leftid=@gateway.example.org
        right=%defaultroute
        rightrsasigkey=0xfc641fd6d9a2444b7...
        rightid=@my_road_ID.example.org

conn whatever
        authby=rsasig
        auto=load                       # load, but don't start
        keyingtries=1                   # road warrior can retry, we shouldn't 
        left=101.101.101.101
        leftnexthop=101.101.101.1
        leftsubnet=192.168.100.47/24    # non-routable RFC 1918 subnet
        leftfirewall=yes                # so we need this line
        leftrsasigkey=0x2ef700d6ddfdbc19...
        leftid=@gateway.example.org
        right=0.0.0.0                   # accept from any address
        rightrsasigkey=0xfc641fd6d9a24b7...
        rightid=@my_road_ID.example.org

We only load the connection at boot. There is no point in trying to start it from the gateway end -- we don't know the other side's IP address. Let the road warrior do that.

When a connection goes down, we try only once to rekey. This avoids excessive overheads when the Road Warrior shuts down (our end is not told that this has happened). Or if, for example, some ISP's router begins emitting smoke and takes a few dozen road warriors offline. You really do not want the gateway retrying them all multiple times. Some other small value, perhaps 3 or 10, might be appropriate for some gateways, but using zero (retry forever) is definitely not recommended.

The invalid IP address 0.0.0.0 is used to tell the gateway to accept connections with this ID from any address.

Putting public keys in DNS

• both our code is much better tested (you can help with that!)
• and secure DNS is widely deployed

The relevant lines in the config file would look like this:

        leftid=@gateway.example.com
        leftrsasigkey=%dns

The public key, in our format, must be in a KEY record of the appropriate DNS for this to work.

If the ID is an IP number, the KEY record is sought in the entry found by doing a reverse lookup of that IP number.

Using shared secrets in production

• 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.

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
• change keys regularly
• 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

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

        also=samplesep-keys

include ipsec.*.conf

conn samplesep-keys
        espenckey=[192 bits]
        espauthkey=[128 bits]

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.

Creating keys with ranbits

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

• 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=ppp1"

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

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

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 requires a lot of duplication of details. Judicious use of also= and include can reduce this problem.

Subject: Re: Maximum number of ipsec tunnels?
   Date: Tue, 18 Apr 2000
   From: "John S. Denker" <jsd@research.att.com>

Christopher Ferris wrote:
>> What are the maximum number ipsec tunnels FreeS/WAN can handle??

Henry Spencer wrote:
>>
>There is no particular limit.  Some of the setup procedures currently
>scale poorly to large numbers of connections, but there are (clumsy)
>workarounds for that now, and proper fixes are coming.

1) "Large" numbers means anything over 50 or so.  I routinely run boxes
with about 200 tunnels.  Once you get more than 50 or so, you need to worry
about several scalability issues:

a) You need to put a "-" sign in syslogd.conf, and rotate the logs daily
not weekly.

b) Processor load per tunnel is small unless the tunnel is not up, in which
case a new half-key gets generated every 90 seconds, which can add up if
you've got a lot of down tunnels.

c) There's other bits of lore you need when running a large number of
tunnels.  For instance, systematically keeping the .conf file free of
conflicts requires tools that aren't shipped with the standard freeswan
package.

d) The pluto startup behavior is quadratic.  With 200 tunnels, this eats up
several minutes at every restart.   I'm told fixes are coming soon.

2) Other than item (1b), the CPU load depends mainly on the size of the
pipe attached, not on the number of tunnels.

It is incomplete. If you must deal with some situation not covered here, please post to the mailing list.

See also Jean-Francois Nadeau's excellent practical configurations document and our compatibility document. These cover several variations not mentioned below, such as interoperation with various other IPSEC implementations.

Extruded Subnets

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.

The extruded addresses have to be a complete subnet. Your friend's security gateway needs to be also his Internet gateway, so that all traffic from the Internet to his addresses passes through the SG.

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.

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 support

Note: This section of the FreeS/WAN 1.1 documents has been retained here for anyone who might still need it, but we now have a better way to do this. Nearly all Road Warrior problems are more easily solved with RSA authentication than with the methods given below.

"Road Warrior" is our term for the laptop user who needs to call home base and wants a secure connection, or any other system that does not have a static IP address. The problem is that Linux FreeS/WAN configuration files define connections by the IP addresses involved and a Road Warrior's IP address is not known in advance.

Our current solution is a temporary expedient, likely to be replaced by something better in the long run.

One connection may be defined for the IP address 0.0.0.0. On getting a connection request from an address it does not recognise, the server tries to authenticate it using the secret for 0.0.0.0. If this succeeds, a connection is created to the unrecognised address. For details, see ipsec_pluto(8).

This implies that all Road Warriors connecting to a server must share the same connection description and the same secret. On the client side, the Road Warrior must set up the /etc/ipsec.conf file with the current IP address before connecting.

Road Warrior example

Server end

conn whatever
        left=101.101.101.101
        leftnexthop=101.101.101.1
        leftsubnet=192.168.73.0/24
        leftfirewall=yes
        right=0.0.0.0

Nor do you set rightsubnet. When 0.0.0.0 is used as "right", and an incoming connection request matches this connection, then the actual values used for both gateway and subnet on that end are set up from the IP address on the incoming packets.

You also need to create a secret for those warriors. For example, /etc/ipsec.secrets might have the line:

101.101.101.101 0.0.0.0 "ffhffkfyuurdsdfdsrehj98753207865v"

Road Warrior end

conn whatever
        left=101.101.101.101
        leftnexthop=101.101.101.1
        leftsubnet=192.168.73.0/24
        leftfirewall=yes
        right=202.202.202.202
        rightsubnet=202.202.202.202
        rightnexthop=202.202.202.1

Note that these right* values must be changed whenever your connection changes. On recent versions of FreeS/WAN, right=%defaultroute will work for simple setups.

On this end, the secret appears as:

101.101.101.101 202.202.202.202 "ffhffkfyuurdsdfdsrehj98753207865v"

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.

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

Boot Time

• 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

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

One situation in which this comes up is when otherwise some data would be encrypted twice. Alice wants a secure tunnel from her machine to Bob's. Since she's behind one security gateway and he's behind another, part of the tunnel that they build passes through the tunnel that their site admins have built between the gateways. All of Alice and Bob's messages are encrypted twice.

There are several ways to handle this.

• Just accept the overhead of double encryption. The site admins might choose this if policy says encrypt everything, if they don't entirely trust Alice and Bob, or 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.
• 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. This is recommended over ESP with null encryption.

• Document index file
• Table of Contents
• Beginning of this file
• FreeS/WAN home page