From: Paul Wouters (paul_at_xtdnet.nl)
Date: Wed Aug 07 2002 - 01:01:02 CEST
Q) I have a server with multiple IP address on the same ethernet card. How do I
use Opportunistic Encryption on all of them?
A) This is a bit more complext then a normal OE connection, but can be done.
(This assumes you have eth0 with IP 10.0.1.1 and eth0:2 with IP
10.0.1.2. The machine has a default gateway of 10.0.1.254).
First of all, you must put the normal OE DNS records in place. I tend to put KEY
and TXT records in both the reverse zone as in the forward zone(s), but if you
have access to the reverse zone, you don't need anything in the forward zone.
The thing to note here is that you need to specify the first ('real') IP as
gateway for the other ('virtual') IP's.
So in the DNS, you'd put (key material left out with [...])
1.1.0.10.in-addr.arpa IN KEY 0x4200 4 1 AQ[...]
1.1.0.10.in-addr.arpa IN TXT "X-IPsec-Server(10)=10.0.1.1 AQ[..]
2.1.0.10.in-addr.arpa IN KEY 0x4200 4 1 AQ[...]
2.1.0.10.in-addr.arpa IN TXT "X-IPsec-Server(10)=10.0.1.1 AQ[..]
You can genererate these on the host itself using the commands:
ipsec showhostkey
for the KEY records and
ipsec showhostkey --txt 10.0.1.1
for the TXT records.
Note: be VERY careful with hand editing the keys. There is a bind workaround with
spaces and quotes. do not cut and paste one output for use on different keys, unless
you understand the issue with this!
Note that as soon as put they keys into the DNS, and it propagates, that you will
cut off communication with all (active) OE machines until you actually have your
ipsec up and running!
Next, we setup an ipsec.conf file. First the setup section
config setup
interfaces="ipsec0=eth0 ipsec1=eth0:1"
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes
packetdefault=pass
Specificly notice the extra packetdefault line, and the interfaces= line that is
probably different from the stock ipsec.conf file. For each IP (virtual or real)
you need to add the interface name to the interfaces= line so pluto knows about it.
I used packetdefault=pass when I was setting this up. Maybe it can go away, but it
might give you a better chance at a proper fallback to sending packets in the clear
when OE fails [anyone from the team can comment on this?]
the default section:
conn %default
keyingtries=0
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%dns
rightrsasigkey=%dns
keylife=5m
rekey=no
The last two lines are added compared to the stock ipsec.conf. There is no good
way of saying 'good bye' to a connection, so to get rid of the connections (remember
with OE you'll get a LOT of connections, not just a few VPN's) we say rekey=no.
Another problem happens when an OE machine (either you or the other end) crashes,
reboots, or restarts the ipsec subsystem. Since the machine that didn't crash
expects to only talk crypted, it won't renegotiate a new connection until its
current connections has expired. Since redoing our key in an active session doesn't
cost that mich cpu, we choose to set a very short keylife. So if your machines with
OE crashes, you're not dead in the water for another hour.
Now we get to the real conn's:
conn eth0_1-to-anyone
# 10.0.1.2 is actuallt the IP address on eth0:1
leftsubnet=10.0.1.2/32
also=eth0-to-anyone
conn eth0-to-anyone
left=10.0.1.1
# %defaultroute doesn't work for me here
leftnexthop=10.0.1.254
right=%opportunistic
#auto=add for passive OE, auto=route for active OE
auto=route
Note that because we use the also=, the order of the conns matters. First put
all the virtual IP's, and then as last entry put the first IP.
Normally, you would want to have active OE. You want your servers to try and
connect as many other people using OE. However, it does cost time. To determine
if someone can do OE, the server needs to do a few DNS lookups. These can cost
a few seconds. For most things, such as SMTP, POP, FTP this doesn't really matter.
But for browsing this can be very annoying. So for webservers, it is probably
better to use passive OE. This means that it will respond to anyone who initiates
oe to it, but it won't try and initiate OE to others itself.
Ofcourse you can also do OE for machines behind a firewall. But be aware that
currently there are problems with using different major modes of IPsec on a
single machine. Since your central firewall likely is already doing static
tunnels, you don't want to run OE on it as well. Using a different machine only
works when that different machine is the default gateway for the machines it is
supposed to protect.
Thanks to everyone who helped me to get this up and running!
Paul
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.4 : Wed Aug 07 2002 - 04:19:38 CEST