Home Recent Changes WikiHelp
Openswan /
PolicyGroups
Login
Last modified: August 04, 2006, at 02:48 PM

How to Configure Openswan with PolicyGroups

What are PolicyGroups?

PolicyGroups are an elegant general mechanism to configure Openswan. They are useful for many Openswan users.

In previous Openswan versions, you needed to configure each IPsec connection explicitly, on both local and remote hosts. This could become complex.

By contrast, Policy Groups allow you to set local IPsec policy for lists of remote hosts and networks, simply by listing the hosts and networks which you wish to have special treatment in one of several Policy Group files. Openswan then internally creates the connections needed to implement each policy.

In the next section we describe our five Base Policy Groups, which you can use to configure IPsec in many useful ways. Later, we will show you how to create an IPsec VPN using one line of configuration for each remote host or network.

Built-In Security Options

Openswan offers these Base Policy Groups:

Notes:

Using Policy Groups

The Base Policy Groups which build IPsec connections rely on Opportunistic Encryption. To use the following examples, you must first become OE-capable, as described in our quickstart guide.

Example 1: Using a Policy Group

To use any policy group, place CIDR blocks (names, IPs or IP ranges) in the policy group file /etc/ipsec.d/policies/groupname?. Then, reread all the policy group files so that the change takes effect.

One common use: when running OE, connections may be slow at startup. To avoid these delays, run a caching DNS server locally, and place the primary DNS server on which this relies in the clear policy group. Refer to it by IP to avoid a name lookup. For example:

{{{

    [root@xy root]# cat /etc/ipsec.d/policies/clear
    # This file defines the set of CIDRs (network/mask-length) to which
    # communication should always be in the clear.
    ....
    192.0.2.192   # upstream nameserver's IP.

}}}

To make the change take effect, reload your policies with:

{{{

    ipsec auto --rereadgroups

}}}

Of course, if the upstream DNS server is OE capable, this is not necessary.

Example 2: Choosing a Default Policy

You will likely want to define a default behaviour when communicating with systems for which you have no pre-configured connection in ipsec.conf. A popular default policy is private-or-clear, which tells Openswan to prefer encrypted communication to the listed CIDR blocks. Failing that, it allows talk in the clear. To make this your default policy, place fullnet (0.0.0.0/0) in the private-or-clear policy group file:

{{{

    [root@xy root]# cat /etc/ipsec.d/policies/private-or-clear
    # This file defines the set of CIDRs (network/mask-length) to which
    # communication should be private, if possible, but in the clear otherwise.
    ....
    0.0.0.0/0

}}}

and reload your policies with

{{{

    ipsec auto --rereadgroups

}}}

Then, test your ability to create OE connections with this test.

Example 3: Defining Local Security Policy

You can combine our base policy groups to create local IPsec security policy. Just put CIDR blocks in the appropriate group files. For example:

{{{

    [root@xy root]# cd /etc/ipsec.d/policies
    [root@xy policies]# cat private
        192.0.2.96/27              # The finance department
        192.0.2.192/29             # HR
	192.0.2.12                 # HR gateway
        irc.private.example.com    # Private IRC server

    [root@xy policies]# cat private-or-clear
        0.0.0.0/0                  # My default policy: try to encrypt.

    [root@xy policies]# cat clear
        192.0.2.18/32              # My POP3 server
        192.0.2.19/32              # My Web proxy

    [root@xy policies]# cat block
        spamsource.example.com

}}}

To make these settings take effect, type:

{{{

    ipsec auto --rereadgroups

}}}

Notes:

 Names are resolved at Openswan startup, or when the policies are reloaded. Unfortunately, name lookup can hold up the startup process. If you have fast DNS servers, the problem may be less severe.

Example 4: An IPsec VPN with the private Group

You can create an IPsec VPN with only one line of configuration per host, using the private policy group.

First, use our quickstart guide to set up each participating host with a Openswan install and OE.

In one host's /etc/ipsec.d/policies/private, list the peers to which you wish to protect traffic. For example:

{{{

    [root@xy root]# cd /etc/ipsec.d/policies
    [root@xy policies]# cat private
        192.0.2.9              # several hosts at example.com
        192.0.2.11
        192.0.2.12
        irc.private.example.com

}}}

Copy this private file to each host. Remove the local host, and add the host which you first configured.

{{{

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

}}}

On each host, reread the policy groups with

{{{

    ipsec auto --rereadgroups

}}}

Test by pinging between two hosts. After a second or two, traffic should flow, and

{{{

    ipsec eroute

}}}

should yield something like

{{{

    192.0.2.11/32   -> 192.0.2.8/32  => tun0x149f@192.0.2.8

}}}

where your host IPs are substituted for 192.0.2.11 and 192.0.2.8.

If traffic does not flow, there may be an error in your OE setup. Revisit our quickstart guide.

The next two examples show you how to add subnets to this IPsec VPN.

Example 5: Protecting a Subnet

To protect traffic to a subnet behind your Openswan gateway, you'll need additional DNS records, and new policy groups. Suppose you wish to secure traffic to a subnet 192.0.2.192/29 behind 192.0.2.12, an OE-capable gateway.

To set up the DNS, use our gateway OE instructions.

To create the policy groups for your subnet, copy these connections to /etc/ipsec.conf. Substitute your subnet's IPs for 192.0.2.128/29.

{{{

conn private-net

    also=private  # inherits settings (eg. auto=start) from built in conn
    leftsubnet=192.0.2.128/29  # your subnet's IPs here

conn private-or-clear-net

    also=private-or-clear
    leftsubnet=192.0.2.128/29

conn clear-or-private-net

    also=clear-or-private
    leftsubnet=192.0.2.128/29

conn clear-net

    also=clear
    leftsubnet=192.0.2.128/29

conn block-net

    also=block
    leftsubnet=192.0.2.128/29

}}}

Copy the base policy group files (which apply to the gateway's connections) to serve as the initial policy group files for the subnet's groups:

{{{

    cp -p /etc/ipsec.d/policies/private /etc/ipsec.d/policies/private-net
    cp -p /etc/ipsec.d/policies/private-or-clear /etc/ipsec.d/policies/private-or-clear-net
    cp -p /etc/ipsec.d/policies/clear-or-private /etc/ipsec.d/policies/clear-or-private-net
    cp -p /etc/ipsec.d/policies/clear /etc/ipsec.d/policies/clear-net
    cp -p /etc/ipsec.d/policies/block /etc/ipsec.d/policies/block

}}}

Tip: Since a missing policy group file is equivalent to a file with no entries, you need only create files for the connections you'll use.

To test one of your new groups, place fullnet (0.0.0.0/0) in private-or-clear-net. Ping from a box on the subnet to another OE-protected box. You should see a connection, and

{{{

    ipsec eroute

}}}

should include an entry which mentions the subnet node's IP and the OE test site IP, like this:

{{{

    192.0.2.131/32   -> 192.139.46.77/32  => tun0x149f@192.0.2.11

}}}

Example 6: Adding the Subnet to the VPN

We can now add the OE-capable subnet from Example 5 to to the IPSec VPN we created in Example 4.

On each other host in the VPN, add the subnet 192.0.2.192/29 to the private policy group file, yielding for example

{{{

    [root@xy root]# cd /etc/ipsec.d/policies
    [root@xy policies]# cat private
        192.0.2.9              # several hosts at example.com
        192.0.2.11
        192.0.2.12             # HR department gateway
        192.0.2.192/29         # HR subnet
        irc.private.example.com

}}}

and reread policy groups with

{{{

    ipsec auto --rereadgroups

}}}

The subnet should now be part of the VPN. Test by pinging from a machine on the subnet 192.0.2.192/29 to any other host on the VPN:

{{{

    [root@192.0.2.194]# ping 192.0.2.11

}}}

After a second or two, traffic should flow, and

{{{

    ipsec eroute

}}}

should yield something like

{{{

    192.0.2.11/32   -> 192.0.2.194/32  => tun0x149f@192.0.2.12

}}}

Key:1.192.0.2.11/32Local start point of the protected traffic.2.192.0.2.194/32Remote end point of the protected traffic.3.192.0.2.12Remote Openswan node (gateway or host). May be the same as (2).4.[not shown]Local Openswan node (gateway or host), where you've produced the output. May be the same as (1).

For additional assurance, you can verify with a packet sniffer that the traffic is being encrypted.

Note

Appendix

Our Hidden Connections

Our Base Policy Groups are created using hidden connections. These are spelled out in man ipsec.conf and defined in /usr/local/lib/ipsec/_confread.

Custom Policy Groups

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

To create a new group:

Disabling Opportunistic Encryption

To disable OE (eg. policy groups and packetdefault), cut and paste the following lines to /etc/ipsec.conf:

{{{ conn block

    auto=ignore

conn private

    auto=ignore

conn private-or-clear

    auto=ignore

conn clear-or-private

    auto=ignore

conn clear

    auto=ignore

conn packetdefault

    auto=ignore

}}}

Restart Openswan so that the changes take effect:

{{{

    ipsec setup restart

}}}

Powered by PmWiki
view edit upload print history