The RSA keys we generate are suitable only for authentication, not for encryption. IPsec uses them only for authentication. See our IPsec section for details.

Setting up opportunistic encryption

Opportunistic encryption makes some 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. All you have to do is set up your end correctly and from there on, everything is automatic.

One of the major goals 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.

Initiate-only opportunistic encryption

In this section, we treat the simplest case of opportunistic encryption:

• 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.)
• for IPsec purposes, that one IP address is both the gateway and the client subnet

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 access to the DNS reverse map for your machine. The following sections cover situations where one or more of the above restrictions do not apply.

There are two steps:

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

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

ipsec.conf(5) for initiate-only opportunism

The ipsec.conf(5) file for this setup is:

# general IPsec setup
config setup
        # Use the default interface
        interfaces=%defaultroute
        # Use auto= parameters in conn descriptions to control startup actions.
        plutoload=%search
        plutostart=%search

# defaults for subsequent connection descriptions
conn %default
        # How to authenticate gateways
        authby=rsasig
        # default is
        # load connection description into Pluto's database
        # so it can respond if another gatway initiates
        # individual connection descriptions may override this
        auto=add

# description for opportunistic connections
conn me-to-anyone
        also=our_stuff             # our system details, stored below
        right=%opportunistic       # anyone we can authenticate
        rightrsasigkey=%dns        # look up their key in DNS
        auto=route                 # set up for opportunistic
        rekey=no                   # let unused connections die

# description of our system
# included in other connection descriptions via also= lines
# must come after the lines that use it
conn our_stuff
        # all connections should use our default route
        # also controls the source address on IPsec packets
        left=%defaultroute
        # our identity for IPsec negotiations
        # must match what is in DNS and ipsec.secrets(5)
        leftid=@xy.example.com

The last line above is the only one that you need to edit for your system. All the rest is identical for any standalone machine doing opportunistic encryption.

The @ sign in the leftid= line indicates that this machine should not attempt to look up that name. Others will, to get our public key, but we don't need to..

There is no need to provide any keys in this file. Your private key is in ipsec.secrets(5) and, for opportunistic encryption, the public keys for remote gateways are all looked up in DNS.

Also note that the left and right designations here are arbitrary. You could reverse them above with no problems.

Initiate-only DNS key

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

Find a helpful DNS administrator

You need the co-operation of a DNS administrator somewhere for this, to place a KEY record so that you can use a name in some domain he or she controls. This need not be either the domain you get your IP address from or a domain that points to your system.

For example, a reverse lookup on the IP address for a home gateway might give 123.adsl.kalamazoo.example.net, and a forward lookup for example.dyndns.org might point to that gateway. You could use either of these names as your ID for IPsec purposes, if the admins at either example.net or dyndns.org co-operate.

If not, you can use any domain whose DNS administrator is willing to help out. You do not need an A record (address record, associating your chosen name with an address) in that domain, only a KEY record.

Generate a KEY record

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

     ipsec showhostkey

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

The name here is taken from ipsec.secrets(5). If it is not what you want, edit that file to correct it, then run ipsec showhostkey again.

The name must also match what you used for leftid= in ipsec.conf(5).

Give this record to the DNS administrator, for insertion into the zone file of the domain.

Firewalling for a standalone system

Firewall rules on a standalone system doing IPsec -- opportunistic, "road warrior" remote access, or both -- can be very simple.

The first step is to allow IPsec packets (IKE on UDP port 500 plus ESP, protocol 50) in and out of your gateway. A script to set up iptables(8) rules for this is:

# edit this line to match the interface you use as default route
# ppp0 is correct for many modem, DSL or cable connections
# but perhaps not for you
world=ppp0
#
# allow IPsec
#
# IKE negotiations
iptables -A INPUT  -p udp -i $world --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -p udp -o $world --sport 500 --dport 500 -j ACCEPT
# ESP encrypton and authentication
iptables -A INPUT  -p 50 -i $world -j ACCEPT
iptables -A OUTPUT -p 50 -o $world -j ACCEPT

Optionally, you could restrict this, allowing these packets only to and from a list of known gateways.

A second firewalling step -- access controls built into the IPsec protocols -- is automatically applied:

Pluto -- the FreeS/WAN keying daemon -- deals with the IKE packets.

Pluto authenticates its partners during the IKE negotiation, and drops negotiation if authentication fails.

KLIPS -- the FreeS/WAN kernel component -- handles the ESP packets.

KLIPS drops outgoing packets

if they are routed to IPsec, but no tunnel has been negotiated for them

KLIPS drops incoming unencrypted packets

if source and destination addresses match a tunnel; the packets should have been encrypted

KLIPS drops incoming encrypted packets

if source and destination address do not match the negotiated parameters of the tunnel that delivers them

if packet-level authentication fails

These errors are logged. See our troubleshooting document for details.

Optionally, you can add a third step using whatever additional firewall rules are required for your situation. These rules can recognise packets emerging from IPsec. They are marked as arriving on an interface such as ipsec0, rather than eth0, ppp0 or whatever. For example, in an iptables(8) rule set, you would use:

-i ipsec+

to specify packets arriving on any ipsec device

-o ipsec+

to specify packets leaving via any ipsec device

It is therefore straightforward to apply whatever additional filtering you like to these packets.

Testing opportunistic connections

To check that opportunistic encryption is working, point a browser to oetest.freeswan.org, a host we have set up to do opportunistic encryption for testing. A link there will tell you whether or not you have an encrypted connection.

If using a browser is inconvenient, 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.

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.

Accepting incoming requests for opportunistic encryption

If you need to let others inititiate 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 -- then you need to do a bit more.

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.

For incoming connections, you are not the initiator so you cannot use the first message to tell the other end the identity you wish to use. You must be able to handle having the other end identify you by IP address. In many cases, that will be all the remote gateway knows.

ipsec.conf(5) to accept incoming opportunistic

Only one change is need in the ipsec.conf(5) file. You use an IP address instead of a name as your identity. For example, with the address 1.2.3.4, the section describing your system becomes:

# description of our system
# included in other connection descriptions via also= lines
# must come after the lines that use it
conn our_stuff
        # all connections should use our default route
        # also controls the source address on IPsec packets
        left=%defaultroute
        # our identity for IPsec negotiations
        # must match what is in DNS and ipsec.secrets(5)
        leftid=1.2.3.4

You must make a matching change in ipsec.secrets(5), so that the identifier for your secret key is also "1.2.3.4".

DNS for incoming opportunistic connections

To accept incoming connections, you need to put a KEY record in the DNS reverse map for your gateway. The initiator will not always know your gateway's name. It must be possible to look up the key knowing only the IP address.

The record you need looks like this:

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

As always, IP addresses in the reverse map are written backwards. In the above example, the gateway IP address is 1.2.3.4.

Firewalling incoming opportunistic connections

The basic firewalling for IPsec does not change when you support incoming connections as well as connections you initiate. You must still allow IKE (UDP port 500) and ESP (protocol 50) packets to and from your machine, as in the rules given above.

However, there are additional security concerns when you allow incoming opportunistic connections. This creates an additional path to your machine, so you need to check your rules to see that this does not provide a means for EvilDoers to bypass protections you have set up on other paths.

In particular, look at any rules you have that depend on interfaces, rules using -i ppp+, -o eth1 or similar expressions. You may need analogous rules for your ipsec interfaces.

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 which have routable addresses and are visible to the Internet. This involves:

• adding a connection description in ipsec.conf(5)
• adding a DNS record for each client, pointing to the 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

The additions to the ipsec.conf(5) file might be:

# opportunistic connections for client systems
# our gateway will build opportunistic tunnels on behalf of any
# machine in the specified subnet
conn subnet-to-anyone
        also=gate_stuff             # our system details, stored below
        also=public_subnet          # subnet description, below
        auto=route                  # set up for opportunistic
        right=%opportunistic        # anyone we can authenticate via DNS
        rekey=no                    # let unused connections die

# description of the subnet this gateway encrypts for
# numbers used here are arbitrary, just for example
conn public_subnet
       leftsubnet=42.42.42.0/24 

There is one small thing to be careful of here. An also= line must appear in the file before the conn it references, so the first section above must appear before conn gate_stuff.

Supporting additional subnets

If required, a gateway can easily provide this service for more than one subnet. You just add a connection description and a subnet description for each. For example, leaving everything else above unchanged, you could add these sections:

# opportunistic connections for additional systems
conn second-to-anyone
        also=gate_stuff             # our system details, stored below
        also=second_subnet          # subnet description, below
        right=%opportunistic        # anyone we can authenticate via DNS
        rekey=no                    # let unused connections die

# description of a second subnet this gateway encrypts for
# numbers used here are arbitrary, just for example
conn second_subnet
       leftsubnet=101.102.103.0/24 

again, you need a little care so that also= lines always come before the sections they reference.

The subnets used in these descriptions need not correspond to physical subnets. This is discussed in more detail in our advanced configuration document.

DNS entries for an opportunistic gateway

We assume you already have a KEY record in the reverse map so your gateway can accept incoming connections as 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 endpoint 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.

Firewalling for gateways

On a gateway, the IPsec-related firewall rules applied for input and output on the Internet side are exactly as shown above. A gateway exchanges exactly the same things -- UDP 500 packets and IPsec packets -- with other gateways that a standalone system does, so it can use exactly the same firewall rules as a standalone system would.

However, on a gateway there are additional things to do:

• you have other interfaces and need rules for them
• packets emerging from ipsec processing must be correctly forwarded

You need additional rules to handle these things. For example, adding some rules to the set shown above we get:

# edit this line to match the interface you use as default route
# ppp0 is correct for many modem, DSL or cable connections
# but perhaps not for you
world=ppp0
#
# edit these lines to describe your internal subnet and interface
localnet=42.42.42.0/24
internal=eth1
#
# allow IPsec
#
# IKE negotiations
iptables -A INPUT  -p udp -i $world --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -p udp -o $world --sport 500 --dport 500 -j ACCEPT
# ESP encrypton and authentication
iptables -A INPUT  -p 50 -i $world -j ACCEPT
iptables -A OUTPUT -p 50 -o $world -j ACCEPT
#
# packet forwarding for an IPsec gateway
# simplest possible rules
$ forward everything, with no attempt to filter
#
# handle packets emerging from IPsec
# ipsec+ means any of ipsec0, ipsec1, ...
iptables -A FORWARD -d $localnet -i ipsec+ -j ACCEPT
# simple rule for outbound packets
# let local net send anything
# IPsec will encrypt some of it
iptables -A FORWARD -s $localnet -i $internal -j ACCEPT 

On a production gateway, you would no doubt need tighter rules than the above. For details, see:

• netfilter documentation
• books such as:
  • Cheswick and Bellovin, Firewalls and Internet Security
  • Zeigler Linux Firewalls,
• our firewalls document
• our firewall links

"Road Warrior" remote access

A common requirement is for pre-configured connections between a specfic 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 (in particular, access to differnet 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 imitiator setup shown above.

We need to add a connection description for the pre-configured tunnel. Since we want to be right in that description, we reverse the opportunistic description so we are right there too.

Connection description for a pre-configured tunnel

We insert the new connection description before the conn our_stuff section, so that it can use an also= line referring to that section.

# description for opportunistic connections
# reversed from previous example
conn me-to-anyone
        also=our_stuff             # our system details, stored below
        left=%opportunistic        # anyone we can authenticate
        leftrsasigkey=%dns         # look up their key in DNS
        auto=route                 # set up for opportunistic
        rekey=no                   # let unused connections die

# pre-configured link to office network
# added for this example
conn us-to-office
        also=our_stuff             # our system details, stored below
        #
        # information obtained from office system admin
        # goes to the right of the = signs in these lines
        # values shown here are just for example
        # 
        left=1.2.3.4                # gateway IP address
        lefttsubnet=42.42.42.0/24   # the office network
        leftid=@gateway.example.com
        # real keys are much longer than shown here
        leftrsasigkey=0s1LgR7/oUM...

# description of our system
# included in other connection descriptions via also= lines
# must come after the lines that use it
# reversed from previous example
conn our_stuff
        # all connections should use our default route
        # also controls the source address on IPsec packets
        right=%defaultroute
        # our identity for IPsec negotiations
        # must match what is in DNS and ipsec.secrets(5)
        righttid=@xy.example.com

Everything else remains as it was when we had only opportunistic connections.

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.

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.

This needs to come before the conn gate_stuff section, so that the Warriors' connection descriptions can use also=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 -- first remove the file, then take any existing connection down with:

        ipsec auto --down connection

        ipsec auto --delete connection

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

FreeS/WAN FAQ

This is a collection of questions and answers, mostly taken from the FreeS/WAN mailing list. See the project web site for more information. All the FreeS/WAN documentation is online there.

Contributions to the FAQ are welcome. Please send them to the project mailing list.

Index of FAQ questions

• What is FreeS/WAN?
• How do I report a problem or seek help?
• Can I get ...
  • ... an off-the-shelf system that includes FreeS/WAN?
  • ... contractors or staff who know FreeS/WAN?
  • ... commercial support?
• Release questions
  • What is the current release?
  • When is the next release?
  • Are there known bugs in the current release?
• Modifications and contributions
  • Can I modify FreeS/WAN to ...?
  • Can I contribute to the project?
  • Is there detailed design documentation?
• Will FreeS/WAN work in my environment?
  • Can FreeS/WAN talk to ... ?
  • Can different FreeS/WAN versions talk to each other?
  • Is there a limit on throughput?
  • Is there a limit on number of connections?
  • Is a ... fast enough to handle FreeS/WAN with my loads?
• Will FreeS/WAN work on ...
  • ... my version of Linux?
  • ... non-Intel CPUs?
  • ... multiprocessors?
  • ... an older kernel?
  • ... the latest kernel version?
  • ... unusal network hardware?
• Does FreeS/WAN support ...
  • ... site-to-site VPN applications
  • ... remote users connecting to a LAN
  • ... remote users using shared secret authentication?
  • ... wireless networks
  • ... X.509 or other PKI certificates?
  • ... user authentication (Radius, SecureID, ...)?
  • ... assigning a "virtual identity" to a remote system?
  • ... single DES encryption?
  • ... AES encryption?
  • ... other encryption algorithms?
• Can I ...
  • ... reload connection info without restarting?
  • ... use several masqueraded subnets?
  • ... use subnets masqueraded to the same addresses?
  • ... assign a road warrior an address on my net (a virtual identity)?
  • ... support many road warriors with one gateway?
  • ... have many road warriors using shared secret authentication?
  • ... use Quality of Service routing with FreeS/WAN?
  • ... recognise dead tunnels and shut them down?
  • ... build IPsec tunnels over a demand-dialed link?
  • ... build GRE tunnels over IPsec?
• Life's little mysteries
  • I cannot ping ....
  • It takes forever to ...
  • I send packets to the tunnel with route(8) but they vanish
  • When a tunnel goes down, packets vanish
  • The firewall ate my packets!
  • Dropped connections
  • TCPdump on the gateway shows strange things
  • Traceroute does not show anything between the gateways
• Testing in stages (or .... works but ... doesn't)
  • Manually keyed connections don't work
  • One manual connection works, but second one fails
  • Manual connections work, but automatic keying doesn't
  • IPsec works, but connections using compression fail
  • Small packets work, but large transfers fail
  • Subnet-to-subnet works, but tests from the gateways don't
• Compilation problems
  • gmp.h: No such file or directory
  • ... virtual memory exhausted
• Interpreting error messages
  • route-client (or host) exited with status 7
  • SIOCADDRT:Network is unreachable
  • ipsec_setup: modprobe: Can't locate moduleipsec
  • ipsec_setup: Fatal error, kernel appears to lack KLIPS
  • ipsec_setup: ... failure to fetch key for ... from DNS
  • ipsec_setup: ... interfaces ... and ... share address ...
  • ipsec_setup: Cannot adjust kernel flags
  • Message numbers (MI3, QR1, et cetera) in Pluto messages
  • Connection names in Pluto error messages
  • Pluto: ... can't orient connection
  • ... we have no ipsecN interface for either end of this connection
  • Pluto: ... no connection is known
  • Pluto: ... no suitable connection ...
  • Pluto: ... no connection has been authorized
  • Pluto: ... OAKLEY_DES_CBC is not supported.
  • Pluto: ... no acceptable transform
  • rsasigkey dumps core
  • !Pluto failure!: ... exited with ... signal 4
  • ECONNREFUSED error message
  • klips_debug: ... no eroute!
  • ... trouble writing to /dev/ipsec ... SA already in use
  • ... ignoring ... payload
• Why don't you restrict the mailing lists to reduce spam?

What is FreeS/WAN?

FreeS/WAN is a Linux implementation of the IPsec protocols, providing security services at the IP (Internet Protocol) level of the network.

For more detail, see our introduction document or the FreeS/WAN project web site.

To start setting it up, go to our quickstart guide.

Our web links document has information on IPsec for other systems.

How do I report a problem or seek help?

See our troubleshooting document. It may guide you to a solution. If not, see its problem reporting section.

Basically, what it says is give us the output from ipsec barf from both gateways. Without full information, we cannot diagnose a problem. However, ipsec barf produces a lot of output. If at all possible, please make barfs accessible via the web or FTP rather than sending enormous mail messages.

Use the users mailing list for problem reports, rather than mailing developers directly.

• This gives you access to more expertise, including users who may have encountered and solved the same problems.
• It is more likely to get a quick response. Developers may get behind on email, or even ignore it entirely for a while, but a list message (given a reasonable Subject: line) is certain to be read by a fair number of people within hours.
• It may also be important because of cryptography export laws. A US citizen who provides technical assistance to foreign cryptographic work might be charged under the arms export regulations. Such a charge would be easier to defend if the discussion took place on a public mailing list than if it were done in private mail.

For problems involving interoperation with another IPsec implementation, try our interoperation document . If that does not help, try the mailing list. In this area, the users often know more than the developers.

Support beyond what the mailing list can provide is also available. See the next several questions.

See also these essays on How To Ask Questions The Smart Way and How to Report Bugs Effectively.

Can I get ...

Can I get an off-the-shelf system that includes FreeS/WAN?

There are a number of Linux distributions or firewall products which include FreeS/WAN. See this list. Using one of these, chosen to match your requirements and budget, may save you considerable time and effort.

If you don't know your requirements, start by reading Schneier's Secrets and Lies. That gives the best overview of security issues I have seen. Then consider hiring a consultant (see next question) to help define your requirements.

Can I hire consultants or staff who know FreeS/WAN?

If you want the help of a cont