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.
To set up opportunistic encryption, you will need:
Note: Only Linux FreeS/WAN supports opportunistic encryption.
Our instructions are for a recent Red Hat with a stock Red Hat kernel. For other ways to install, see our install document.
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
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
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
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.
Determine the best form of opportunism your system can support.
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.
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 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.
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.
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.
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.
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
That's it! Test your connection.
This allows you to initiate and receive opportunistic connections from one machine.
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.
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/
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/"
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.
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.
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.
That's it. Now, test your connection.
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/"
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.
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]
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
Instructions are in the next section.
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/32 | Local start point of the protected traffic. |
2. | 192.0.2.194/32 | Remote end point of the protected traffic. |
3. | 192.0.48.38 | Remote 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)
Please see our policy groups document for more ways to set up Opportunistic Encryption.
You may also wish to make some VPN connections .