How to Configure Linux FreeS/WAN with Policy Groups

Policy groups are a new feature that we're getting ready for 2.0. Testing is appreciated, as is feedback via design@lists.freeswan.org.

What are Policy Groups?

Policy Groups provide a new way of configuring Linux FreeS/WAN.

By defining IPsec behaviour for groups of IPs (or named domains), you can easily conceptualize an overall IPsec security policy. Linux FreeS/WAN then translates that into connection descriptions, and establishes your connections.

Our Base Policy Groups rely on Opportunistic Encryption to do this. However, Policy Groups are a flexible tool -- they can also be used as a shorthand to configure VPNs, as in this example.

Policy Groups can be used with your existing ipsec.conf. You can have VPN connections explictly defined in ipsec.conf, and define other behaviour with policy groups.

As of 2.0-pre0, there have been significant revisions to ipsec.conf; details in our Upgrading Guide.

Built-In Security Options

Linux FreeS/WAN offers these Base Policy Groups:

oe-or-bust (OE-based VPN)
Attempt to negotiate opportunistically. On failure, block.
oe-or-clear
Attempt to opportunistically negotiate a tunnel. On failure, communicate in the clear
clear-or-oe (Opportunistic Responder)
Communicate in the clear. If the other side negotiates opportunistically, go along with that.
clear
Communicate with these in the clear.
block
Block listed IP addresses from communicating with this machine.

You can also define your own groups.

All Policy Groups are bidirectional. This chart shows some technical details. FreeS/WAN does not support one-way encryption, since it can give users a false sense of security.

Using Base Policy Groups

Base Policy Groups rely on OE. To use the following examples, you must first become OE-capable, as described here.

Example 1: Using a base group

This is as easy as putting names, IPs or IP ranges in /etc/ipsec.d/groupname.

    cd /etc/ipsec.d
    echo "193.110.157.0/24  #includes oetest.freeswan.nl" >> oe-or-clear

Now, when we try to contact oetest.freeswan.nl, FreeS/WAN will automatically bring up a connection.

To test this,

    ping oetest.freeswan.nl
    ipsec look | grep " -> "

You should see something like:

    40.40.40.40/32   -> 193.110.157.10/32  => tun0x149f@193.110.157.77 esp0xf8754dc8@193.110.157.77
    40.40.40.40/32   -> 193.110.157.14/32  => tun0x14a3@193.110.157.75 esp0xa9520f54@193.110.157.75

indicating tunnels between your node or network [here, 40.40.40.40/32] and the two targets passiveOE.freeswan.nl (193.110.157.10) and activeOE.freeswan.nl (193.110.157.14).

If the other side cannot do OE, the connection will fall back to clear. Since OEtest is properly set up for OE, if you don't see a tunnel, check your local OE capability as directed in our quickstart guide.

Example 2: Defining IPsec Security Policy with Groups

We can indicate how we'd like traffic to any peer handled, by listing its name or IP range in the appropriate file. For example:

    cd /etc/ipsec.d
    cat oe-or-bust
        40.40.38.0/27    # The finance department
        40.40.38.0/27    # HR
        40.40.40.26/32    # Barb's machine
        40.40.40.33/32    # Our IRC server
  
    cat oe-or-clear
        0.0.0.0/0    # My default policy: try to encrypt.

    cat clear
        66.66.66.45/32   # My POP3 server
        66.66.66.53/32   # My Web proxy

    block
        mail.spamworks.com

Notes:

Custom Policy Groups

You are now in experimental territory. This doc has not been tested, so use at your own risk.

A policy group is built using a special connection description in ipsec.conf, which:

The connections that comprise our Base Policy Groups are hidden behind the scenes. For example, our standard oe-or-clear connection is created using this hidden connection:

    conn OEgroup  #check this conn's specifics
        rightsubnet=%opportunisticgroup
        also=OEself
    conn OEself
        left=%defaultroute
        leftrsasigkey=%dnsondemand
        right=%opportunistic
        rightrsasigkey=%dnsondemand
        keyingtries=3
        ikelifetime=1h
        keylife=1h
        rekey=no
        auto=route

See man ipsec.conf for explanations of these settings.

To create a new group:

  1. Create its connection definition in ipsec.conf.
  2. Create a Policy Group file in /etc/ipsec.d with the same name as your connection.
  3. Put a name or IP range in that file.
  4. Test.

Example 3: Variation on a Base Policy Group

We can alter OEgroup slightly to make a new group. The name must now be different. For example OE_persistent, which will establish an OE connection, and try to keep it open forever.

HOWTO: Alter this line. Create this file. Test it.

Example 4: Policy Group as shorthand for several VPNs

We can create a Custom Policy Group to link several friends' computers to a network behind an IPsec gateway.

    conn friends
        left=%defaultroute             # Local vitals
        leftsubnet=42.42.42.0/24       # 
        leftnexthop=%defaultroute      # correct in many situations 
        right=%group
        authby=secret
        auto=add

Does this get started on ping? Do we need to explicitly start if auto!=start. Then: error in intro to this doc.

Before building further, we test the connection with:

    ipsec auto --add friends --showonly

If it doesn't work it may be because of a, b, c. Troubleshoot like this.

On her notebook, each friend must also configure a return conn. Barbara at 40.40.52.1/32 might have in ipsec.conf:

    version 2
    conn back_at_you
        left=42.42.42.1                # Your IP
        leftsubnet=42.42.42.0/24       #
        right=40.40.52.1/32             # Friend's IP
        rightnexthop=%defaultroute      # correct in many situations
        authby=secret
        auto=start

All the friends will also need to share a secret by some secure means. Barbara's ipsec.secrets looks like this:

    42.42.42.1 : PSK "verysecretsecret"

Back at my machine, I make a Policy Group file titled friends

    cd /etc/ipsec.d
    vi friends

I add the friends' names and/or IP ranges:

    44.44.44.61/32
    40.40.52.1/32
    mattspc.org

And I edit my own ipsec.secrets: (shouldn't there be some shorthand for this?)

To start a connection, I ping a friend. To see the results, I type:

   ipsec look

I should now see a connection, for example:

   snip tunnel text here

If you hit a snag, see our FAQ.