Chapter 6

The trap eroute

In the eroute table given above, we see that all packets (0.0.0.0/0) are first trapped. This means that any packet with whatever source address to whatever destination address, for which we do not already have an eroute entry, will be cached while Openswan tries to determinate whether it can set up an OE-based IPsec tunnel for this destination.

The pass eroute

The eroute table also lists two pass eroutes. One of them is to 193.110.157.2. In our OE setup for bofh.xelerance.com, we had added 193.110.157.2 to our clear policy, since that is the IP address of the ns.xtdnet.nl name server, which is used by bofh.xelerance.com.

The hold eroute

The hold eroute in the table shows us there is a problem. It seems 193.110.157.5 is advertising OE, but an IPsec connection to it has failed to establish. Packets to this IP are being held, and if there are too many packets to hold, they will be dropped. The logs for this attempt also show us why:

Nov 7 20:28:41 bofh pluto[1970]: "private-or-clear#0.0.0.0/0"[2] 193.110.157.76===193.110.157.5/32 #4: initiating Main Mode

Nov 7 20:28:41 bofh pluto[1970]: "private-or-clear#0.0.0.0/0"[2]

...193.110.157.76===193.110.157.5/32 #4: ERROR: asynchronous network error report on eth0 for message to 193.110.157.76 port 500, complainant 193.110.157.76: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

To establish an OE connection to 193.110.157.5, we were apparently directed to the machine on the IP address 193.110.157.76. A DNS lookup confirms this:

# host -t txt 5.157.110.193.in-addr.arpa

5.157.110.193.in-addr.arpa text "X-IPsec-Server(10)=193.110.157.76 AQOARC[...]

Indeed, 193.110.157.76 is the OE gateway for 193.110.157.5.

However, that machine was not running an IKE daemon on UDP port 500, as shown by the ICMP Connection Refused message. In other words, it is not running Openswan. Since the host is advertising its OE capability, but it is not working, we will not be able to communicate with that host unless Openswan is started on 193.110.157.76. A workaround would be to add 193.110.157.5/32 to the clear policy file.

Manipulating OE Connections Manually

Since OE uses instances of special connections, you cannot use ipsec auto --add or ipsec auto – delete on them as you would with static conns. But you can manually attempt to trigger an OE connecting using the following command:

# ipsec whack --oppowhere myipaddress --oppothere remotehost

143

Opportunistic Encryption

Advanced OE Setups

A good system administrator usually uses separate IP addresses for separate services. When a service, such as a web server, mail server, or DNS server, is moved to another physical computer, the IP address moves along with it, and the transition happens smoothly without interruption. There are of course many other reasons why a server can have more than one IP address, but nevertheless many hosts on the Internet have multiple IP addresses.

Sometimes it can be desirable to exclude some IP addresses from OE, but to enable OE for the other IP addresses. For instance, a very busy DNS server may not have the resources to initiate OE for all incoming requests, but if that same server is an email server, you might wish to protect all outgoing SMTP connections using OE. This can be done, using the (old-style) IP aliases. The following is an example configuration for such a scenario:

config setup

interfaces="ipsec0=eth0 ipsec1=eth0:2 ipsec2=eth0:3" conn eth0_2-to-anyone

# 193.110.157.5 is actually the IP address on eth0:2 leftsubnet=193.110.157.5/32

also=eth0-to-anyone conn eth0_3-to-anyone

# 193.110.157.7 is actually the IP address on eth0:3 leftsubnet=193.110.157.7/32

also=eth0-to-anyone conn eth0-to-anyone

left=193.110.157.76

right=%opportunistic

keylife=5m

rekey=no

# uncomment to enable incoming; change to auto=route for outgoing #auto=add

conn packetdefault auto=ignore

Do not use the ip command to add IP address to a server if you want to exclude them with the above method.

Caveats

Of course there are a few tricks for solving some of the practical problems. First, OE has a hole for IKE packets, so they don't trigger the OE mechanism. Otherwise that would only result in both ends trying to set up tunnels simultaneously.

With KLIPS, packets triggering an OE connection are cached, but with NETKEY, these packets are lost and an obscure (and incorrect) Resource temporarily unavailable message is logged. We do not yet recommend using NETKEY with OE, but hopefully, NETKEY will add this functionality in the near future.

If you are behind NAT, you currently have to manually disable your OE settings.

144

Chapter 6

As is to be expected, there are some problems with DNS. We do really want to protect DNS traffic with OE; such traffic is after all clearly worth protecting as part of your privacy. What if the name server supports OE? What if our resolver is behind OE? Well, we will have to live with some initial DNS problems. In practice, this means that for the first minute or so after starting Openswan with OE, a bunch of packets will be queued or lost, until we have established either a clear or encrypted connection to our name servers. Even if the name server supports OE, we will still have to reach it in plaintext before we query its records to use OE. This may all sound complex, but it's all rather harmless.

When deploying OE for the first time, give it several minutes to start before declaring that it doesn't work.

Summary

This chapter has provided an in-depth examination of OE, a mechanism for the spontaneous setup of IPsec tunnels to hosts on the Internet without prior arrangement. We have shown how to configure it, how to add the proper DNS records, and how to protect subnets of hosts behind a single security gateway. If you wish to enhance the security of your DNS records, perhaps this is a good moment to configure and set up DNSSEC.

145