* NEW * FreeS/WAN version 2 or better comes with an Opportunistic connection for your machine. To enable it simply set up DNS entries as described below.
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.
Opportunistic encryption is new technology and we are still working out some fine points. Please see this list of known issues.
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-1.98b_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-1.98b_2.4.18_3-0.i386.rpm
While you are there, grab the RPM signing key
rpmsign.pgp
and add it to your PGP keyring:
pgp -ka rpmsign.pgp
Check the signatures on both RPMs using:
rpm --checksig freeswan-module-1.98b_2.4.18_3-0.i386.rpm rpm --checksig freeswan-1.98b_2.4.18_3-0.i386.rpm
You should see:
freeswan-module-1.98b_2.4.18_3-0.i386.rpm: pgp md5 OK freeswan-1.98b_2.4.18_3-0.i386.rpm: pgp md5 OK
Become root:
su
Install your RPMs with:
rpm -ivh freeswan-module-1.98b_2.4.18_3-0.i386.rpm
rpm -ivh freeswan-1.98b_2.4.18_3-0.i386.rpm
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 fullest form of opportunism your system can support.
When you set yourself up as an opportunistic initiator:
Find a forward domain where you can publish your key. You'll need access to the 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.
In post-1.98b versions, check your DNS work with:
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.
If you're using an older FreeS/WAN, query your nameserver (here, 1.2.3.254):
dig @1.2.3.254 xy.example.com KEY
You should see (with the key again shortened):
;; ANSWER SECTION: xy.example.com. 6835 IN KEY 16896 4 1 AQO6DJc6LIwGq82ehvIGLKn4S...
The hidden default connection OEself will be used. You must only set leftid correctly for your system. (WARNING: this method of overriding leftid is not tested; it may not work.)
Set it in /etc/ipsec.conf's conn %default with a line like:
conn %default leftid=@xy.example.com # put your ID here
Put your FQDN ID, preceded by an @sign, in place 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. Generate a KEY record: 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): Edit it to insert the IP address in reverse map format.
In our example, 1.2.3.4 becomes 4.3.2.1.in-addr.arpa. The result: 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: where you replace 1.2.3.4 with your public IP. The record (with key shortened) looks like: 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. In post-1.98b versions, check your DNS work with: You ought to see something like: which indicates that you've passed both reverse-map tests. Test that your KEY has been published by querying your nameserver
(here, 1.2.3.254): You should see (with the key shortened for clarity): Next, test that your TXT record is visible:
You should see (with the key shortened for clarity): The hidden default connection OEself will be used.
For leftid, your system guesses the IP of your default route,
which is usually correct. However, if you've previously configured for
initiator-only opportunism, remove the
leftid= you added then. If you've made any changes, restart FreeS/WAN so that it reads the new
settings: That's it. Now, test your connection.
You need these so that your Opportunistic peers can:
On the gateway, generate a TXT record with:
Use your gateway address in place of 1.2.3.4 You should see (keys are trimmed for clarity throughout our example): 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: Above each entry, insert a line like this: It must include: The result will be a file full of TXT records, like this: Ask your ISP to publish these records in your reverse map. If your ipsec is post-1.98b, then for a couple of subnet nodes, give this
command: You should see: Test a couple of records with commands like this one: Replace 1.2.3.254 with your nameserver's IP, and
1.42.42.42.in-addr.arpa. with the reverse-format IP of one of your subnet
nodes. You should see: Cut-n-paste this connection to /etc/ipsec.conf: Set leftsubnet to the local IP range that your OE gateway will
protect. Restart FreeS/WAN: Proceed to the next section and test away. The quick method is:
A thought for the paranoid -- the feds are probably watching that site.
You should see: If you do not see this, see our FAQ. If you do, congratulations! Your machine will now encrypt whenever it
can. If you haven't already, read up on our
known issues.
Or, proceed to make some vpn connections.
In 2.00pre1 or better, OE is enabled by default.
This is accomplished by automatically
defining a conn "OEself" UNLESS the sysadmin defines one with the same
name: This will only work if %defaultroute works.
The leftid will be the resulting IP address (won't work if
you haven't filled in the reverse DNS entry).
Unlike other conns, nothing in this implicit conn is changed by conn %default.
Full Opportunism
Put KEY and TXT records in DNS
Your KEY record
ipsec showhostkey
; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000
xy.example.com IN KEY 0x4200 4 1 AQOF8tZ2...+buFuFn/
; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000
4.3.2.1.in-addr.arpa. IN KEY 0x4200 4 1 AQOF8tZ2...+buFuFn/
Your TXT record
ipsec showhostkey --txt 1.2.3.4
; RSA 2048 bits xy.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
Publish both records
Test your DNS records
with ipsec verify --host
ipsec verify --host xy.example.com
Looking for TXT in reverse map: 4.3.2.1.in-addr.arpa [OK]
Looking for KEY in reverse map: 4.3.2.1.in-addr.arpa [OK]
or the long way...
dig @1.2.3.254 4.3.2.1.in-addr.arpa. KEY
;; ANSWER SECTION:
4.3.2.1.in-addr.arpa. 6835 IN KEY 16896 4 1 AQO6DJc6LIwGq82ehvIGLKn4S...
dig @1.2.3.254 4.3.2.1.in-addr.arpa. TXT
;; ANSWER SECTION:
4.3.2.1.in-addr.arpa. 7200 IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
Configure
#leftid=xy.example.com
service ipsec restart
Test
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
ipsec showhostkey --txt 1.2.3.4
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
; RSA 2048 bits gateway.example.com Sat Apr 15 13:53:22 2000
IN TXT "X-IPsec-Server(10)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
1.42.42.42.in-addr.arpa. IN PTR arthur.example.com
1.42.42.42.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)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
2.42.42.42.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)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
3.42.42.42.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)=1.2.3.4" " AQOF8tZ2...+buFuFn/"
Publish your records
...and test them
with ipsec verify --host
ipsec verify --host ford.example.com
ipsec verify --host trillian.example.com
....
Looking for TXT in reverse map: 2.42.42.42.in-addr.arpa [OK]
....
Looking for TXT in reverse map: 3.42.42.42.in-addr.arpa [OK]
...or the long way
dig @1.2.3.254 1.42.42.42.in-addr.arpa. TXT
ANSWER SECTION:
1.42.42.42.in-addr.arpa. 180 IN TXT "X-IPsec-Server(10)=1.2.3.4 " AQOF8tZ2...+buFuFn/"
ipsec.conf(5) for an opportunistic gateway
conn OEsubnet
also=OEself # inherits other settings from built in connection
leftsubnet=42.42.42.0/24
service ipsec restart
Test
Testing opportunistic connections
links oetest.freeswan.org
You seem to be connecting from: 1.2.3.4 which DNS says is:
xy.example.com
_________________________________________________________________
Status E-route
OE enabled 16 192.139.46.73/32 -> 1.2.3.4/32 =>
tun0x2097@1.2.3.5
OE enabled 176 192.139.46.77/32 -> 1.2.3.4/32 =>
tun0x208a@1.2.3.5
Now what?
Appendix: the hidden OE connection
conn OEself
left=%defaultroute
leftrsasigkey=%none
right=%opportunistic
# rightrsasigkey=%dnsondemand # default
keyingtries=3
keylife=1h
rekey=no
# disablearrivalcheck=no # default
# authby=rsasig # default
auto=route