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.
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.
Linux FreeS/WAN offers these Base Policy Groups:
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.
Base Policy Groups rely on OE. To use the following examples, you must first become OE-capable, as described here.
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.
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:
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:
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.
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.