Contents Previous Next

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 several connection descriptions, and establishes your connections.

Our Base Policy Groups rely on Opportunistic Encryption (OE) to do this.

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:

private (OE-based VPN)
Attempt to negotiate opportunistically. On failure, block.
private-or-clear
Attempt to opportunistically negotiate a tunnel. On failure, communicate in the clear.
clear-or-private (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/policies/[groupname] (in -pre3, /etc/ipsec.d/ [groupname]).

In fact, if you have walked through our quickstart guide, you have already used the private-or-clear policy group. With this policy, FreeS/WAN tries to encrypt opportunistically to a listed peer. Failing that, you can connect to that peer in the clear.

You defined it as your default policy by placing the wildcard 0.0.0.0/0 in the private-or-clear policy group file:

    cat /etc/ipsec.d/policies/private-or-clear     #in pre-3, /etc/ipsec.d
        0.0.0.0/0     # Any IP or group of IPs

and reloading the policy group files with

    ipsec auto --rereadgroups

Should you wish to turn OE functionality off, comment out that line:

    cat /etc/ipsec.d/policies/private-or-clear     #in pre-3, /etc/ipsec.d
        # 0.0.0.0/0     

and reload your policies with

    ipsec auto --rereadgroups

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/policies
    cat private
        40.40.38.0/27            # The finance department
        40.40.39.0/27            # HR
	40.40.41.1/32            # HR gateway
        40.40.40.26/32           # Barb's machine
        irc.ourdepartment.org    # Private IRC server
  
    cat private-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

    cat block
        mail.spamworks.com

To make these settings take effect, type:

    ipsec auto --rereadgroups

Notes:

Example 3: Creating a VPN with the private policy group

A private policy demands that, to communicate with a node, we MUST use Opportunistic Encryption. Because it forces all traffic to certain nodes to be encrypted, you can use the private policy group to implement a VPN via OE.

First, set up each participating node (gateway or laptop) with a FreeS/WAN install, and make it OE-capable. Use the instructions in our quickstart guide.

Then, in one node's /etc/ipsec.d/policies/private, (on -pre3, /etc/ipsec.d/private) list the IPs to which you wish to protect traffic. Include your own IP to facilitate later copying. For example

    cd /etc/ipsec.d/policies
    cat private
        40.40.38.0/27            # The finance department
	40.40.41.2/32            # Finance department gateway
        40.40.39.0/27            # HR
	40.40.41.1/32            # HR gateway
        40.40.40.26/32           # Barb's machine
        40.40.40.28/32           # My machine
        irc.ourdepartment.org    # Private IRC server

Policy group file format is explained in Example 2.

If the peer node is a gateway, include the gateway IP. This protects MASQ'd traffic, and traffic to the gateway. Always include the subnets a gateway can opportunistically protect.

Copy this file to each node.

    scp2 /etc/ipsec.d/policies/private root@40.40.40.26:/etc/ipsec.d/policies/private

On each node, make your changes take effect with

    ipsec auto --rereadgroups

Test by pinging from one node to another. After a few seconds, you should see a tunnel between the two. Your ping traffic should flow, and

    ipsec look | grep " -> "

should yield something like

    40.40.40.40/32   -> 40.40.39.8/32  => tun0x149f@40.40.41.1 esp0xf8754dc8@40.40.40.45

Key:

1.40.40.40.40/32Local start point of the protected traffic.
2.40.40.39.8/32Remote end point of the protected traffic.
3.40.40.41.1Remote FreeS/WAN node (gateway or standalone machine). May be the same as (2).
4.[not shown]Local FreeS/WAN node (gateway or standalone machine). May be the same as (1).

If you are using a gateway, test not only to the gateway but also to its subnets.

If your ping traffic does not flow, you may not have set up the nodes correctly for OE. Revisit the tests in our quickstart guide.

You can verify with a packet sniffer that the traffic is being encrypted. We recommend ethereal.

Note: Because strangers can also connect via OE, this type of VPN requires a stricter firewalling policy than a conventional VPN.

Custom Policy Groups

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.

To create a new group:

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

Example 4: Variation on a Base Policy Group

Suppose we'd like to create a group which would make opportunistic connections and, if successful, try to keep them open forever.

Copy this connection into your ipsec.conf. It is similar to our hidden connection OEself, with one small change.

    conn OEpersistent
        left=%defaultroute
        leftrsasigkey=%dnsondemand
        right=%opportunistic
        rightrsasigkey=%dnsondemand
        keyingtries=3
        ikelifetime=1h
        keylife=1h
        rekey=yes                  # rekeys persistently, unlike OEself
        failureshunt=passthrough   # fails to clear
        auto=route

Next, create the group file, and place in it a sample entry:

    echo "oetest.freeswan.nl" >> /etc/ipsec.d/policies/OEpersistent

(In -pre3, use /etc/ipsec.d/OEpersistent.)

If you've stepped through Example 1 you may also need to remove oetest from another group file.

Load the new configs with

    ipsec auto --rereadgroups

Ping oetest to open the connection.

    ping oetest.freeswan.nl

After a few seconds, look for the connection:

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

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.

Do some other tasks. After an hour and ten minutes, again run

    ipsec look | grep " -> "

Even if you have not attempted to contact oetest in the interim, you should still see its tunnels, as above.

For more immediate results, do the above procedure with keylifetime=5m, and check for your rekeyed tunnels after ten minutes.

That's it. Your OEpersistent connection works.

Now, add any other IPs with which you'd like to have an OEpersistent connection, to /etc/ipsec.d/policies/OEpersistent. To make this your default policy, put 0.0.0.0/0 in this file, and reload your policies:

    echo "0.0.0.0/0" > /etc/ipsec.d/policies/OEpersistent
    ipsec auto --rereadgroups

Appendix: Our hidden connections

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
        failureshunt=passthrough   # fail to clear
        auto=route

See man ipsec.conf for explanations of these settings.


Contents Previous Next