Quick FreeS/WAN installation and configuration
Keywords: Linux, IPsec, VPN, security, FreeSWAN, installation, quickstart

# FreeS/WAN quick start guide

This is a quick guide to

- getting FreeS/WAN installed from a distribution CD or RPMs
- testing to see if install succeeded
- firewalling with FreeS/WAN

and then setting up some common configurations:

- opportunistic encryption
  - a system which can initiate all the encryption it needs
  - a system which also accepts incoming requests for secure connections
  - a gateway providing services for a number of clients
- "road warrior" remote access to a network
  - "road warrior" machine setup
  - network gateway setup
- network-to-network VPN

This should cover everything you need to set up

- a laptop machine
- a standalone home PC
- a home office firewall/gateway
- a simple gateway for a small company or branch office

More complex requirements are covered elsewhere:

- installing from source
- advanced configuration
- interoperation with other IPsec implementations

However, please read this quick start section first, before tackling the others.

## Easy installation

There are two easy ways to install FreeS/WAN:

- Some Linux distributions, listed in the introduction, ship with FreeS/WAN included.

  If you are using one of them, just include FreeS/WAN in the choices you make during installation, or add it to your configuration later using the distribution's tools.

  If your FreeS/WAN came on your machine, and is pre-1.98, you will need to hand generate an RSA key pair for authentication, using these instructions.

- RPM (Redhat Package Manager) packages built for your distribution may be available for download. If they are, then the installation is quite simple.

  Sources for RPM packages of FreeS/WAN are:

  - Steamballoon, the helpful folks who developed the RPM tools in our distribution
  - FreeS/WAN FTP site (At time of writing, no RPMs are there yet.)
  - one of the FreeS/WAN mirrors listed in the introduction (not yet)

  Note that:

  - you should not trust RPMs from a source you do not know
  - you should run rpm --checksig before trusting any RPM. Checking the public key signature gives you assurance that the RPM you install was not changed after they signed it.
  - the RPMs must exactly match your system. For example, an RPM built for Redhat 7.1 should not be used on 7.2.
  - the kernel RPM must be correct for your hardware. For example, a kernel compiled for an AMD Athlon will not run correctly on an Intel-based system.

  You need to download at least two RPMs:

  - FreeS/WAN kernel components, as:
    - a module, or
    - a kernel that includes FreeS/WAN code
  - FreeS/WAN utilities to match
  The two should have the same version number.

  You do not need the kernel header and kernel source RPMs to install FreeS/WAN, but Murphy's Law suggests you should download them so that the kernel source and headers on your system match the kernel actually in use.

  Once you have them, install the RPMs with rpm -i commands. You will need to be root to install a module or kernel.

  Then, start FreeS/WAN:

  - If you have opted for a FreeS/WAN module, use:

            service ipsec start

  - If you have a new kernel which contains FreeS/WAN, reboot.

If your distribution does not include FreeS/WAN and no RPMs are available, see our installation from source document.

## Testing to see if install succeeded

To check that you have a successful install, run:

        ipsec verify

or, on older FreeS/WANs:

        ipsec whack --status

ipsec verify(8) checks whether:

- FreeS/WAN's daemon component (pluto) is running, and
- its kernel parts (KLIPS) are loaded

It also anticipates future problems. For example, it tests if:

- port 500 is open to let IKE connection negotiations through
- your RSA public key, used for authenticating opportunistic connections, is already available from DNS

If your checks fail, see our troubleshooting guide.

That's it. FreeS/WAN is installed.

## Firewalling for IPSec

If you are running a firewall, you must now allow FreeS/WAN traffic through. You will also wish to consider how to protect your machine from unwanted traffic which might enter through your FreeS/WAN tunnels. There are three steps to firewalling with FreeS/WAN.

The first step is to allow IPsec packets in and out of your machine. Allow:

- IKE on UDP port 500
- ESP and AH, protocols 50 and 51. ESP and AH do not have ports, and as a result they cannot be port forwarded.

If that machine is a gateway, be sure that packets emerging from IPSec processing are correctly forwarded.

A second firewalling step -- access controls built into FreeS/WAN -- is automatically applied. For example, in some situations KLIPS determines that it should not have received a certain packet, and drops it.

Optionally, you may wish to add a third step, to filter packets emerging from your IPSec tunnels. This is a sensible precaution at any time, but becomes more important if you employ full opportunistic encryption, since that can allow strangers to bypass your usual firewall rules.

More detail is here, along with sample firewall scripts.

## Quick setups

#### ipsec.conf and ipsec.secrets for every setup

FreeS/WAN relies on two configuration files:

/etc/ipsec.conf
  which contains information about your system and your IPSec peers, and
/etc/ipsec.secrets
  which contains sensitive authentication materials, including your RSA private key. Keep its permissions at 600.

Note that Mandrake puts them in /etc/freeswan.

The remainder of this document shows you how to configure these common setups:

- opportunistic encryption
- "road warrior" remote access
- network-to-network VPN

## Setting up opportunistic encryption

Opportunistic encryption makes many aspects of the setup and administration of IPsec easier.

For opportunistic encryption, you do not need to communicate with the administrator of a site before establishing secure communications to that site. In particular, you do not have to send them your keys or collect and authenticate theirs. You also do not have to configure IP information for each connection.

Instead, you need to place some information in DNS, and create a simple configuration that will enable your system to connect securely with every other system set up for OE. This presents a clear advantage over manually setting up a large number of VPN connections.

A major goal of the FreeS/WAN project is to get opportunistic encryption widely enough deployed that a "FAX effect" comes into play. Neither a FAX machine nor opportunistic encryption is of much value if there are only a few installed, but both become much more useful as the installed base increases.

Widespread deployment of opportunistic encryption appears to be our best hope for making the Internet more secure. See discussion in our introduction.

### DNS control is required

Opportunistic encryption relies on DNS:

- to distribute public keys for authentication
- to announce how FreeS/WAN will protect packets to a given machine

To set up full opportunistic encryption, you must be able to insert resource records in the DNS reverse maps for:

- the IP of your public interface
- the IPs of the machines you're protecting

For a standalone machine or a gateway using NAT, these two IPs will be identical, so you will only need one RR.

This requires a static IP, at least on the machine running IPSec.

Normally the reverse map is controlled by your Internet Service Provider (ISP). Ask your ISP's staff if they are willing to publish a resource record, which you would provide, in your IP's reverse map.

If you cannot, you can still protect connections which you initiate. This requires simply that you can put a record in some domain's forward DNS.

Directions for initiate-only opportunism are just below; those for full opportunism are in the following section.

### Known issues with opportunistic encryption

Because opportunistic encryption relies on DNS:

- to verify that we are who we say we are, and (where relevant)
- to prove that we have the right to protect traffic for a given IP,

its authentication is only as strong as your DNS is secure .

Without secure DNS, opportunistic connections protect against passive snooping, but not active man-in-the-middle attacks.

You can make your DNS entries more trustworthy by serving them within your security perimeter. We recommend running a nameserver on your gateway, as described in our opportunism HOWTO ("Getting DNS Through").

Opportunistic encryption is new technology and we are still working out some fine points. Please see this list of known issues.

## Three opportunistic examples

In the next sections, we will tackle three typical setups for opportunistic encryption:

- initiate-only opportunism for a standalone system, or one with limited write access to DNS
- an opportunistic responder, such as a server (requires reverse DNS control)
- a gateway which opportunistically protects traffic for nodes behind it

One example does build on the previous one, but you can skip ahead to get an idea of what your situation entails.

### Initiate-only opportunistic encryption

In this section, we the case of opportunistic encryption that has the fewest requirements:

- there will be no incoming connection requests; you can initiate all the IPsec connections you ever need
- only one machine is visible on your end of the connection (though there may be a hidden NAT network behind it.)

This would apply to a standalone machine, or to a home gateway with some invisible NAT clients.

Given the above conditions, you can set up opportunistic encryption without having to add resource records to the DNS reverse map for your public IP address. Sections after this one cover situations where one or more of the above restrictions do not apply.

There are two steps:

- put your public key in DNS
- set your system up for opportunistic encryption

Once this is done, your system will automatically encrypt whenever it can.

#### Initiate-only DNS key

You need to put your system's RSA public key in a forward DNS record so that systems you communicate with can find it.

Dynamic IP users take note: the domain where you place your key need not be associated with the IP address for your system, or even with your system's usual hostname.

##### Choose an ID

When negotiating a connection, your FreeS/WAN will identify itself by a fully qualified domain name (FQDN) which tells other FreeS/WANs where to find its KEY. Choose a name, within the domain you have access to, that you will use for this purpose.

For example, if you have access to example.com's DNS, you could choose xy.example.com, even if your hostname is xyz.instance.com and the reverse map for your IP points to 12345678-ourtowns-cableco.com.

Note that xy.example.com need not be associated with your current IP address, or any IP for that matter.

##### Generate a KEY record

You can generate a DNS KEY record containing your system's public key with the command:

         ipsec showhostkey

The result should look like this (with the key data trimmed down for clarity):

      ; RSA 2048 bits   xy.example.com   Sat Apr 15 13:53:22 2000
      xy.example.com.   IN   KEY   0x4200 4 1 AQOF8tZ2...+buFuFn/

Change xy.example.com to your FQDN.

Insert the record into DNS, or have a helpful system adminstrator do so for you. Remember that it will take time (up to 48 hours, but often a lot less) for any new DNS information to propagate, so OE won't work immediately.

#### ipsec.conf(5) for initiate-only opportunism

By default, Linux FreeS/WAN ships with an opportunistic connection, conn me-to-anyone. It's easy to customize this.

Add a line to me-to-anyone which sets the parameter leftid to your FQDN, preceded by an @ sign. In our example:

    conn me-to-anyone
            ...
            leftid=@xy.example.com
            ...

The @ causes FreeS/WAN to identify itself by your FQDN, rather than by an IP which corresponds to that name.

Note that the left and right designations in ipsec.conf are arbitrary. We follow a convention of using left for local and right for remote.

Uncomment the line auto=route to enable the connection.

Normally, this is all the configuration you will need to do. However, if your FreeS/WAN is protecting an interface other than the one on your machine's default route, you will need to adjust the interfaces= line in config setup.

A full ipsec.conf(5) file for this setup is available here.

#### Testing opportunistic connections

The quick method is to point a browser to oetest.freeswan.org. A link there will tell you whether or not you have an encrypted connection.

For more detail, take these steps:

- ping oetest.freeswan.org
- ping some site that does not yet have opportunistic encryption
- run ipsec look

You should see a tunnel to the opportunistic host. It will look something like:

    1.2.3.4/32   -> 5.6.7.8/32   => tun0x146c@5.6.7.8

When FreeS/WAN cannot set up an opportunistic connection, and no explicit tunnel has been configured, its default is to allow the traffic through in the clear. For the non-opportunistic host, you should see a %pass eroute (IPsec route), the FreeS/WAN mechanism that implements that default. This looks something like:

    1.2.3.4/32   -> 9.10.11.12/32    => %pass

### Accepting incoming requests for opportunistic encryption

To enable full opportunism on your standalone system (or NATting gateway), you need to do a bit more. This will allow others to initiate encrypted connections to your system -- for example, if you run services on your machine and want remote clients to be able to access them securely.

There are two steps in the setup.

- setting up ipsec.conf(5)
- setting up the DNS entries to support it

Both need to be a little different than in the initiate-only case.

#### ipsec.conf(5) to accept incoming opportunistic

Most people can use the conn me-to-anyone exactly as it ships in the default ipsec.conf(5) file. Just uncomment auto=route to enable it.

Unlike the configuration above, do not set leftid=. By default, FreeS/WAN will use the IP address of your public interface instead of a name as your identity. Once again, if FreeS/WAN is protecting a different interface, you will need to adjust interfaces= in the config setup section.

You can refer to this sample configuration.

FreeS/WAN must also use the secret key from ipsec.secrets(5) that matches this IP address. Normally you have only one RSA key, so there is no need to alter ipsec.secrets.

#### DNS for incoming opportunistic connections

You need to put two records, a KEY record and a TXT record, in the DNS reverse map for your public IP. They need to be here because the initiating FreeS/WAN must look up your data knowing only your machine's IP address, not its name. As mentioned above, this requires your ISP's co-operation.

The KEY record you need looks like this:

      ; RSA 2048 bits   xy.example.com   Sat Apr 15 13:53:22 2000
      4.3.2.1.in-addr.arpa.   IN   KEY   0x4200 4 1 AQOF8tZ2...+buFuFn/

Generate it with ipsec showhostkey, and then edit it to insert the IP address. As always, IP addresses in the reverse map are written backwards. In our example, 1.2.3.4 becomes 4.3.2.1.in-addr.arpa.

You also need to create a TXT record, to let others know that this machine can receive opportunistic connections. It also lets them know that the machine is authorized to encrypt on its own behalf.

Use the command:

         ipsec showhostkey --txt 1.2.3.4

where you replace 1.2.3.4 with your public IP.

The record (with key shortened) looks like this:

            ; RSA 2048 bits  xy.example.com   Sat Apr 15 13:53:22 2000
            IN TXT  "X-IPsec-Server(10)=1.2.3.4 AQOF8tZ2...+buFuFn/"

Send both records to your ISP, to be published in your IP's reverse map.

#### Firewalling incoming opportunistic connections

There is a particular security concern when you allow incoming opportunism.

Incoming opportunistic packets enter your machine via an IPSec tunnel. That is, they all appear as ESP (protocol 50) packets, concealing whatever port and protocol characteristics the packet within the tunnel has. Contained in the tunnel as they pass through ppp0 or eth0, these packets can bypass your usual firewall rules on these interfaces.

Since you will be exchanging opportunistic packets with peers who are not familiar to you, you will want to firewall your ipsec interfaces the way you would any publicly accessible interface.

A simple way to do this is to create one iptables(8) table with all your filtering rules for incoming packets, and apply the entire table to all public interfaces, including ipsec interfaces.

Here's more on firewalling with opportunistic encryption.

### An opportunistic gateway

Next we expand from a standalone system (which protects only its own traffic) to a gateway (which protects traffic for other systems).

There is one special case in which gateway configuration is quite simple -- if all the machines behind the gateway are hidden from the Internet. We describe that first, then go on to describe gateways for visible clients.

#### NAT for hidden clients

If your gateway uses NAT to allow machines to access the Internet without having their own routable IP addresses, then from the point of view of anyone else on the Internet:

- the systems behind the gateway are completely hidden
- only one machine with one IP address is visible
- the gateway appears to be a standalone system

For purposes of IPsec across the Internet, your gateway can be treated as a standalone machine. Consequently,

- your ipsec.conf(5) file needs no changes to support the NAT. It can be identical to what you would use on a standalone system -- either initiate-only or with incoming connection support -- as shown above.
- the firewall rules for your Internet interface can be identical to those for a standalone system, as above
- the only thing you must change are the firewall rules that control forwarding to the NAT network

For a more detailed discussion of NAT, see our background section.

#### Gateway for visible clients

Many gateways will need to support client systems that have routable addresses and are thus visible to the Internet. To equip such a gateway with opportunistic encryption, you'll need a co-operative ISP that will allow you to insert resource records into reverse DNS.

Setup for a gateway involves:

- adding a connection description in ipsec.conf(5)
- adding a DNS record for each client, pointing to its FreeS/WAN gateway.

#### ipsec.conf(5) for an opportunistic gateway

You need only make a few additions to in the ipsec.conf(5) file:

- keep the connection description for the gateway itself
- add another one for its clients
- in that connection, specify the clients in a leftsubnet= line

In ipsec.conf(5), a new conn is needed for each local subnet to be protected by opportunistic encryption. If you are also protecting the gateway, most of the new conn can be borrowed from the old one. Place this before me-to-anyone:

    conn subnet-to-anyone
           also=me-to-anyone
           leftsubnet=42.42.42.0/24

Note that a subnet described in ipsec.conf(5) need not correspond to a physical network segment. This is discussed in more detail in our advanced configuration document.

If required, a gateway can easily provide this service for more than one subnet. You just add a connection description for each.

#### DNS entries for an opportunistic gateway

We assume you already have a KEY record in the reverse map for your gateway's public IP address, so your gateway can accept incoming connections. This is described above.

For the gateway to provide an opportunistic encryption service for other systems, it must be possible for the initiator of an IPsec connection to:

- discover the gateway's address, knowing only the IP address that packets are bound for
- verify that the gateway is authorised to encrypt for that endpoint

This is done by adding a TXT record to the reverse map for the endpoint. The record (with key shortened) looks like this:

            ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
            IN TXT  "X-IPsec-Server(10)=1.2.3.4 AQOF8tZ2...+buFuFn/"

This record must be generated on the gateway so it can get the key from ipsec.secrets(5). The command is:

         ipsec showhostkey --txt 1.2.3.4

You must supply the gateway IP address on the command line.

One of these records is required in the reverse map for each system using this gateway for opportunistic IPsec. You insert it in the reverse map part of the zone file right after the line for that system's IP address, so part of the file might look like this:

          1.42.42.42.in-addr.arpa. IN PTR arthur.example.com
            ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
            IN TXT  "X-IPsec-Server(10)=1.2.3.4 AQOF8tZ2...+buFuFn/"
          2.42.42.42.in-addr.arpa. IN PTR ford.example.com
            ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
            IN TXT  "X-IPsec-Server(10)=1.2.3.4 AQOF8tZ2...+buFuFn/"
          3.42.42.42.in-addr.arpa. IN PTR trillian.example.com
            ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
            IN TXT  "X-IPsec-Server(10)=1.2.3.4 AQOF8tZ2...+buFuFn/"

You need one TXT record per client, but the TXT records can all be identical.

## Pre-configured connections

Some circumstances call for pre-configured IPSec connections, also known as VPNs (Virtual Private Networks). In particular, when you need strong authentication, ie. to access an office network, VPN is your best current choice. This may change when secure DNS arrives, since secure DNS will strengthen the authentication system for opportunistic encryption.

Below are instructions for pre-configuring:

- "Road warrior" remote access
- Network-to-network configuration

as well as tips on:

- what to look at next

## "Road warrior" remote access

A common requirement is for pre-configured connections between a specific network and some set of remote machines. For example, an office network will often need to provide remote access services for:

- employees' or contractors' home offices (standalone machine or firewall plus client machines)
- travelling employees

We refer to the remote machines as "road warriors". For purposes of IPsec, anyone with a dynamic IP address is a road warrior.

Of course, if both the warrior and the gateway at the office are set up for opportunistic encryption, then you may not need the pre-configured connection. Here we assume that you do need it. For example:

- a corporate security policy might require explicitly-configured connections for some applications
- either end might be using a product which does not yet support opportunistic encryption

This section has three sub-sections:

- exchanging the information required to build explicitly configured connections
- setup on the "road warrior" end
- setup on the gateway end

On either end, the opportunistic setup is unaffected by this. You leave it in place so both systems can continue to do opportunistic encryption with everyone but each other.

### Information exchange

To set up an explicitly configured connection, you need some information about the system on the other end.

Connection descriptions use left and right to designate the two ends. We adopt the convention that, from the gateway's point of view left=local and right=remote.

The gateway administrator needs to know some things about each road warrior:

- the system's public key
- the ID that system uses in IPsec negotiation

To get this information, in a format suitable for insertion directly into the gateway's ipsec.conf(5) file, issue this command on the warrior machine:

            ipsec showhostkey --right

The output should look like this (with the key shortened for easy reading):

            rightid=@xy.example.com
            rightrsasigkey=0s1LgR7/oUM...

The road warrior needs to know:

- the gateway's public key
- the ID the gateway uses in IPsec negotiation

which can be generated by running ipsec showhostkey --left on the gateway. Each warrior must also know:

- the IP address of the gateway
- the subnet to which an IPsec tunnel provides access

This information should be provided in a convenient format, ready for insertion in the warrior's ipsec.conf(5) file. For example:

            left=1.2.3.4
            leftsubnet=42.42.42.0/24
            leftid=@gateway.example.com
            leftrsasigkey=0s1LgR7/oUM...

The gateway administrator typically needs to generate this only once. The same file can be given to all warriors.

Of course it is also possible to provide different versions, with access to different subnets, to different groups of warriors. See our advanced configuration document.

### Setup on the road warrior machine

To set up a road warrior machine, we start from the opportunistic initiator setup shown above.

Simply add a connection description us-to-office, with the left and right information you gathered above. This might look like:

    # pre-configured link to office network
    conn us-to-office
            # information obtained from office system admin
            left=1.2.3.4                # gateway IP address
            leftsubnet=42.42.42.0/24   # the office network
            leftid=@gateway.example.com
            # real keys are much longer than shown here
            leftrsasigkey=0s1LgR7/oUM...
            # our stuff, same when we are opportunistic initiator
            right=%defaultroute
            rightid=@xy.example.com

Here's more detail on this configuration.

We could easily add more connections as required, perhaps one each for his office, her office, the kid's school,... The file would grow longer, but nothing already in the file would need to change.

Once you have a number of connections, you may like to make your ipsec.conf modular, to save typing. See these instructions.

### Road warrior support on an office gateway

Adding road warrior support so people can connect remotely to your office network is straightforward.

We start from the opportunistic gateway setup shown above.

#### Putting connection descriptions in separate files

You could put a complete connection description for each warrior in your ipsec.conf(5) file, but this makes for a rather unmanageable file if you have many warriors.

Instead, we suggest you give each warrior its own file, choosing some directory and naming convention that suits your system and style.

For this example, we use the directory /etc/ipsec.road and use filenames based on IPsec ID, so the warrior using ID xy.example.com gets a file named xy.conf.

Using such files, you need add only one line to ipsec.conf(5). With our naming convention, the line is:

          include /etc/ipsec.road/*.conf

FreeS/WAN will then read all those files and behave as if they were part of the ipsec.conf(5) file.

We suggest you make your ipsec.conf modular, so that each file does not need to include information for the gateway side. Create a separate connection conn gate_stuff, containing this common information. For example:

    conn gate_stuff
            left=1.2.3.4
            leftsubnet=42.42.42.0/24
            leftid=@gateway.example.com
            leftrsasigkey=0s1LgR7/oUM...

You will reference this in each road warrior connection.

Your include line needs to be before conn gate_stuff. A convenient place for the line is right after the conn %default section.

Each of the road warrior files then contains a connection description for that warrior. For example:

    # connection description for road warrior "xy"
    conn gate-xy
            # use the gateway description in ipsec.conf(5)
            also=gate_stuff
            # allow connection attempt from any address
            # attempt fails if caller cannot authenticate
            right=%any
            # authentication information
            rightid=@xy.example.com
            rightrsasigkey=0s1LgR7/oUM...

With this technique, it becomes fairly simple to administer a gateway that supports many road warriors. For example:

To add a new user, simply add a suitable file.

To disable an account -- for example if a key is compromised -- take any existing connection down and delete it from Pluto's internal database with:

            ipsec auto --delete connection

and remove or correct the affected file.

If you have many users, it would be worthwhile to write scripts to automate such tasks.

## Network-to-network VPN

Often it is useful to have explicitly configured IPsec tunnels between different offices of an organisation, or between organisations that have joint projects.

Of course, if both offices are set up for opportunistic encryption and the security policies in place allow you to use that, explicitly configured tunnels become unnecessary. However, this will not always be the case.

### Gateway setup for net-to-net

Adding up a network-to-network tunnel does not require any change to the opportunistic or road warrior parts of your ipsec.conf(5). You can keep those parts exactly as shown above.

Of course, a network-to-network tunnel requires its own connection description, so you have to add that. There are two ways to do this.

identical connection description on the two ends
  needs to specify more detail so the machine can figure out which end it is on
slightly different descriptions on the two ends
  needs less detail, but you need to manage two descriptions

Choose whichever is more convenient to administer in your environment.

#### A connection description that works on either end

Here is a network-to-network tunnel description from our examples file:

    # sample tunnel
    # The network here looks like:
    #   leftsubnet====left----leftnexthop......rightnexthop----right====rightsubnet
    # If left and right are on the same Ethernet, omit leftnexthop and rightnexthop.
    conn sample
            # left security gateway (public-network address)
            left=10.0.0.1
            # next hop to reach right
            leftnexthop=10.44.55.66
            # subnet behind left (omit if there is no subnet)
            leftsubnet=172.16.0.0/24
            # right s.g., subnet behind it, and next hop to reach left
            right=10.12.12.1
            rightnexthop=10.88.77.66
            rightsubnet=192.168.0.0/24
            auto=start

If you give an explicit IP address for left (and left and right are not directly connected), then you must specify leftnexthop (the router which left sends packets to in order to get them delivered to right). Similarly, you may need to specify rightnexthop (vice versa).

The *nexthop parameters are needed because of an unfortunate interaction between FreeS/WAN and the kernel routing code. They will be eliminated in a future release, but perhaps not soon. We know they should go, but getting them out is not a simple problem.

This description can be generated on either machine and simply inserted in the ipsec.conf(5) file on the other. No change is required or desired.

#### Using slightly different descriptions

Provided both machines do IPsec over the interface that is their default route to the Internet (a common case, but by no means the only one) you can simplify the description somewhat.

When using left=%defaultroute, you do not need to specify leftnexthop. left does not need to know rightnexthop either, so on left the connection description can be:

    conn sample
            # left security gateway (public-network address)
            left=%defaultroute
            # subnet behind left (omit if there is no subnet)
            leftsubnet=172.16.0.0/24
            # right s.g., subnet behind it
            right=10.12.12.1
            rightsubnet=192.168.0.0/24
            auto=start

On right it is:

    conn sample
            # left security gateway (public-network address)
            left=10.0.0.1
            # subnet behind left (omit if there is no subnet)
            leftsubnet=172.16.0.0/24
            # right s.g., subnet behind it
            right=%defaultroute
            rightsubnet=192.168.0.0/24
            auto=start

## What next?

At this point, we have covered setup for opportunistic encryption and for simple cases of road warrior and VPN connections. You have several choices for what to look at next:

- more advanced configuration
- FreeS/WAN and firewalls
- more detail on the IPsec protocols