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 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.
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/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
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:
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/32 | Local start point of the protected traffic. |
2. | 40.40.39.8/32 | Remote end point of the protected traffic. |
3. | 40.40.41.1 | Remote 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.
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:
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
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.