Contents Previous Next

Quickstart Guide to Opportunistic Encryption

Purpose

This page will get you started using Linux FreeS/WAN with opportunistic encryption (OE). OE enables you to set up IPsec tunnels without co-ordinating with another site administrator, and without hand configuring each tunnel. If enough sites support OE, a "FAX effect" occurs, and many of us can communicate without eavesdroppers.

Please see this list of known issues with Opportunistic Encryption.

Requirements

To set up opportunistic encryption, you will need:

Note: Only Linux FreeS/WAN supports opportunistic encryption.

RPM installation

Our instructions are for a recent Red Hat with a stock Red Hat kernel. For other ways to install, see our install document.

Download RPMs

Check your kernel version with

   uname -a

From our FTP site, get the kernel module which matches your kernel. For example:

    freeswan-module-2.00_2.4.18_3-0.i386.rpm

Note: Our kernel modules will only work on the Red Hat kernel they were built for, since they are very sensitive to small changes in the kernel.

Get FreeS/WAN utilities to match. For example:

    freeswan-userland-2.00_2.4.18_3-0.i386.rpm

Check signatures

While you are there, grab the RPM signing key

    freeswan-rpmsign.asc

If you're running RedHat 8.x, import this key into the RPM database:

    rpm --import freeswan-rpmsign.asc

For RedHat 7.x systems, you'll need to add it to your PGP keyring:

    pgp -ka freeswan-rpmsign.asc

Check the signatures on both RPMs using:

    rpm --checksig freeswan-module-2.00_2.4.18_3-0.i386.rpm
    rpm --checksig freeswan-userland-2.00_2.4.18_3-0.i386.rpm

You should see:

    freeswan-module-2.00_2.4.18_3-0.i386.rpm: pgp md5 OK
    freeswan-userland-2.00_2.4.18_3-0.i386.rpm: pgp md5 OK

Install the RPMs

Become root:

    su

Install your RPMs with:

    rpm -ivh freeswan-module-2.00_2.4.18_3-0.i386.rpm
    rpm -ivh freeswan-userland-2.00_2.4.18_3-0.i386.rpm

If you've installed FreeS/WAN RPMS before, see our note on upgrading from 1.x to 2.x RPMs.

Then, start FreeS/WAN:

    service ipsec start

Test

To check that you have a successful install, run:

    ipsec verify

You should see at least:

    Checking your system to see if IPsec got installed and started correctly
    Version check and ipsec on-path                             [OK]
    Checking for KLIPS support in kernel                        [OK]
    Checking for RSA private key (/etc/ipsec.secrets)           [OK]
    Checking that pluto is running                              [OK]

If any of these first four checks fails, see our troubleshooting guide.

Our Opportunistic Setups

Full or partial opportunism?

Determine the best form of opportunism your system can support.

Initiate-only setup

Restrictions

When you set up initiate-only Opportunistic Encryption (iOE):

You cannot network a group of initiator-only machines if none of these is capable of responding to OE. If one is capable of responding, you may be able to create a hub topology using routing.

Put your public key in DNS

Find a domain you can use

Find a DNS forward domain where you can publish your key. You'll need access to the DNS zone files for that domain. For the following examples, we'll use "example.com".

Dynamic IP users take note: the domain where you place your key need not be associated with the IP address for your system, or even with your system's usual hostname.

Choose your ID

Choose a name within that domain which you will use to identify your machine. Normally, but not always, your ID is the same as your machine name. Our machine is called xy, and we'll choose the corresponding FQDN xy.example.com.

Create a KEY record

Generate a DNS KEY record containing your system's public key with the command:

    ipsec showhostkey

This command takes the contents of /etc/ipsec.secrets and reformats it into something usable by ISC's BIND. The result should look like this (with the key data trimmed down for clarity):

    ; RSA 2048 bits   xy.example.com   Sat Apr 15 13:53:22 2000
    xy.example.com.   IN   KEY   0x4200 4 1 AQOF8tZ2...+buFuFn/

Change xy.example.com to your FQDN.

Publish the KEY

Insert the record into DNS, or have a system adminstrator do it for you. It may take up to 48 hours for the record to propagate, but it's usually much quicker.

Test that your key has been published

Check your DNS work

    ipsec verify --host xy.example.com

You ought to see something like:

    Looking for forward key for xy.example.com      [OK]

For this type of opportunism, only the forward key test is relevant.

Configure

Copy this connection to /etc/ipsec.conf,

conn iprivate-or-clear    
    leftid=@xy.example.com   # put your ID here
    also=private-or-clear

Use your own FQDN ID, preceded by an @sign, instead of @xy.example.com.

Restart FreeS/WAN so that the new configuration takes effect:

    service ipsec restart

Test

That's it! Test your connection.

Full Opportunism

This allows you to initiate and receive opportunistic connections from one machine.

Put KEY and TXT records in DNS

You must be able to publish these directly in the reverse domain. FreeS/WAN will not follow a PTR which appears in the reverse, since a second lookup at connection start time is too costly.

Your KEY record

Generate a KEY record:

    ipsec showhostkey

This command takes the contents of /etc/ipsec.secrets and reformats it into something usable by ISC's BIND. It will yield (with key data trimmed for clarity):

    ; RSA 2048 bits   xy.example.com   Sat Apr 15 13:53:22 2000
  xy.example.com   IN   KEY   0x4200 4 1 AQOF8tZ2...+buFuFn/

Edit it to insert the IP address in reverse map format. For example, 192.0.2.11 becomes 11.2.0.192.in-addr.arpa. The result:

    ; RSA 2048 bits   xy.example.com   Sat Apr 15 13:53:22 2000
  11.2.0.192.in-addr.arpa.   IN   KEY   0x4200 4 1 AQOF8tZ2...+buFuFn/

Your TXT record

This lets others know that this machine can receive opportunistic connections. It also lets them know that the machine is authorized to encrypt on its own behalf.

Use the command:

    ipsec showhostkey --txt 192.0.2.11

where you replace 192.0.2.11 with your public IP.

The record (with key shortened) looks like:

    ; RSA 2048 bits  xy.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"

Publish both records

Send these records to your ISP, to be published in your IP's reverse map. It may take up to 48 hours for these to propagate, but usually takes much less time.

Test your DNS records

Check your DNS work with

    ipsec verify --host xy.example.com

You ought to see something like:

    Looking for TXT in reverse map: 11.2.0.192.in-addr.arpa [OK]
    Looking for KEY in reverse map: 11.2.0.192.in-addr.arpa [OK]

which indicates that you've passed both reverse-map tests.

No Configuration Needed

FreeS/WAN ships with a default policy, private-or-clear, which creates OE connections.

If you are running a default install of RedHat 8.x, take note: you will need to alter your iptables rule setup to allow IPSec traffic through your firewall. See our firewall document for sample iptables rules.

Test

That's it. Now, test your connection.

An Opportunistic Gateway

Start from full opportunism

Do as above, with one difference -- collect all the DNS records you'll need before contacting your ISP.

TXT records for each protected machine

You need these so that your Opportunistic peers can:

On the gateway, generate a TXT record with:

    ipsec showhostkey --txt 192.0.2.11

Use your gateway address in place of 192.0.2.11.

You should see (keys are trimmed for clarity throughout our example):

    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"

This MUST BE the same key as in your gateway's KEY record, or nothing will work.

In a text file, make one copy of this TXT record for each subnet node:

    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"

    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"

    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"

Above each entry, insert a line like this:

    98.2.0.192.in-addr.arpa. IN PTR arthur.example.com

It must include:

The result will be a file of TXT records, like this:

    98.2.0.192.in-addr.arpa. IN PTR arthur.example.com 
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"

    99.2.0.192.in-addr.arpa. IN PTR ford.example.com 
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"

    100.2.0.192.in-addr.arpa. IN PTR trillian.example.com 
    ; RSA 2048 bits  gateway.example.com   Sat Apr 15 13:53:22 2000
    IN TXT  "X-IPsec-Server(10)=192.0.2.11" " AQOF8tZ2...+buFuFn/"

Publish your records

Ask your ISP to publish these records in your reverse map. Once again, there may be a delay of up to 48 hours as the records propagate.

...and test them

Check a couple of records with commands like this one:

    ipsec verify --host ford.example.com
    ipsec verify --host trillian.example.com

You should see:

    ....
    Looking for TXT in reverse map: 99.2.0.192.in-addr.arpa [OK]
    ....
    Looking for TXT in reverse map: 100.2.0.192.in-addr.arpa [OK]

ipsec.conf(5) for an opportunistic gateway

Cut-n-paste this connection to /etc/ipsec.conf:

conn private-or-clear-net
    also=private-or-clear  # inherits settings from this hidden connection
    leftsubnet=192.0.2.98/27

Change leftsubnet to the local net that your OE gateway will protect.

Type:

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

On a fresh install, this extends a default OE policy to your network.

Restart FreeS/WAN so the changes will take effect:

    service ipsec restart

Test

Instructions are in the next section.

Testing opportunistic connections

Linux FreeS/WAN has a couple of test sites:

A thought for the paranoid -- the feds may be watching these sites.

To test your OE, type one of:

   links oetest.freeswan.org
   links oetest.freeswan.nl

from any OE-protected node (host, gateway or subnet). You should see positive results. Here's an example from oetest.freeswan.org:

   You  seem  to  be  connecting  from:  192.0.2.11 which DNS says is:
   gateway.example.com
     _________________________________________________________________

   Status E-route
   OE    enabled    16    192.139.46.73/32    ->    192.0.2.11/32   =>
   tun0x2097@192.0.2.11
   OE    enabled    176    192.139.46.77/32    ->   192.0.2.11/32   =>
   tun0x208a@192.0.2.11

If you do, congratulations! Your machine will now encrypt whenever it can. If you have difficulty, see our FAQ.

When testing OE, you will often find this command useful:

   ipsec eroute

If you have established a connection, you will see a result like:

    192.0.2.11/32   -> 192.139.46.73/32  => tun0x149f@192.139.46.38

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.48.38Remote FreeS/WAN node (gateway or host). May be the same as (2).
4.[not shown]Local FreeS/WAN node (gateway or host), where you've produced the output. May be the same as (1).

For extra assurance, you may wish to use a packet sniffer such as tcpdump to verify that packets are being encrypted. You should see output that indicates ESP encrypted data, for example:

    02:17:47.353750 PPPoE  [ses 0x1e12] IP 154: xy.example.com > oetest.freeswan.org: ESP(spi=0x87150d16,seq=0x55)

Now what?

Please see our policy groups document for more ways to set up Opportunistic Encryption.

You may also wish to make some VPN connections .

Notes


Contents Previous Next