Introduction to FreeS/WAN
Keywords: Linux, IPsec, VPN, security, encryption, cryptography, FreeS/WAN, FreeSWAN

# Configuring Linux FreeS/WAN with Food Groups

NOTE to readers: This is an in-process file on a feature that is not yet fully implemented. See the design list discussions for the software's latest status.

## What are Food Groups?

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

By defining security policy for groups of IPs (or named domains), you can easily conceptualize what you want to do with IPsec. Linux FreeS/WAN then does all the hard work of translating that into connection descriptions, and establishing your connections.

We call our security policies "Food Groups" because, like the food groups we learned about in school, they're basic building blocks from which something more complete can be formed. In this case, that something is a total IPsec security policy for the node or network you're protecting.

Food Groups rely on Opportunistic Encryption to do this.

This new feature can be used right alongside your existing ipsec.conf. On 2.x revisions to ipsec.conf, see our Upgrading Guide.

NOTE to Developers: Can we accept names and standalone IP addresses in food group files?

### Built-in Security Policies

Linux FreeS/WAN offers these built in security policies (Food 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.

## How to use them

### Example 1: Using a built-in group

Configuring food groups is as easy as putting names, IPs or IP ranges in a file with the same name as the group, under /etc/freeswan-groups. (on Mandrake: /etc/freeswan/freeswan-groups).

Why did you put them in /etc/init.d? Clutter factor? Will a FS install create empty food group files with the standard names?

        cd /etc/freeswan-groups
        echo "193.110.157.0/24  #includes oetest.freeswan.nl" >> oe-or-clear
        chmod 550 oe-or-clear   # The right permissions =??

FreeS/WAN will automatically create a connection to cover this case, and will bring it up when need be. To test this,

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

NOTE to Developers: I would like to see "ipsec look" output which includes *only* information relevant to one food group. I think it's important that users can easily display this type of information.
Proposed syntax:
ipsec look --group [groupname] [--quick]
Often all I want to see is the lines with the arrows. Maybe the --quick format could just do that.

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 this doesn't work, troubleshoot like this.

### Example 2: defining security policy with Food Groups

Using several food group files, you can create a detailed IPsec security policy.

Indicate how you would like traffic to any peer handled, by listing its name or IP(s) in the appropriate file. For example:

        cd /etc/freeswan-groups
        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   # My POP3 server
            66.66.66.53   # A Web proxy

        block
            mail.spamworks.com

Notice that you can define a default policy with the range 0.0.0.0/0. In our example, any traffic without more specific instructions will fall into the oe-or-clear category.

Is there a default default? When does it come into play?

## Custom Food Groups

A food group is built using a special connection description, which:

- is generic. That is, it uses right=[%group|%opportunistic|%opportunisticgroup] rather than specific IPs. It is then cloned for every IP or IP range listed in its file.
- often has a failure rule. This rule, written failureshunt=[passthrough|drop|reject], shows FreeS/WAN what to do with packets for these IPs if it fails to establish the connection. There is no default failure rule. (What happens if you don't connect?)

Note: It is important for our error reporting to distinguish between a general-case failure (this conn is never going to work) and a specific-case failure (can't connect, failing to block).

The connections that comprise our standard food groups are hidden behind the scenes. Our standard oe-or-clear connection is created using this hidden connection:

    conn OEself
       asdfasdf
       asdfdsaf

To create a new group you:

1. Create its connection definition. [Test it as much as possible at this stage].
2. Create a food groups file in /etc/freeswan-groups with the same name.
3. Put an OE-capable entry in that file.
4. Test.

### Example 1: Altering a built-in group

We can alter OEself slightly to make a new group. The name must now be different.

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

### Example 2: An entirely new group

Claudia will think of an example.

Before building further, test your connection by this method:

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

#### Test

        cd /etc/freeswan-groups
        echo "193.110.157.0/24  #includes oetest.freeswan.nl" > custom_group

Use different IPs, obviously.