[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sheflug] IPsec -Linux
On Wed, 28 Apr 2004, Dawson, Alan wrote:
> Well I wanted to connect to 2 lans together and a Cisco PIX was involved
> somewhere also, but I was planning on using Debian Sarge. Any good links
> and reading material would be great.
OK, here we go... one of the most useful things I've found is the page at
<http://www.ipsec-howto.org/>, especially
<http://www.ipsec-howto.org/x247.html>. Also, pretty much any of the
FreeBSD pages on IPSEC also applies, because it's using the same
implementation with the same userspace tools to manage it.
Some background on what I've got here... I've got an internal network,
192.168.64.0/24, sitting behind a *nix-based firewall/router. It in turn
has an external network, 192.168.8.0/24, which has a DSL router (with NAT)
connecting it to the outside world. In another town, our other office has
an internal network 172.18.1.0/24, with a PIX connecting that to the
outside world (in my configuration below, I've changed the PIX's external
IP address to 172.19.1.254. We want to tunnel connections from our
internal network to theirs, and note there's a NAT device between the two
tunnel endpoints.
For the tunnel to the PIX, these are the settings I'm using on my end
(they wouldn't let me touch the PIX itself, but I could always get the
config for you if you need it):
Policies, set using setkey:
---------- Cut Here ----------
172.18.1.0/24[any] 192.168.64.0/24[any] any
in ipsec
esp/tunnel/172.19.1.254-192.168.8.253/require
created: Apr 22 18:43:20 2004 lastused: Apr 27 15:02:50 2004
lifetime: 0(s) validtime: 0(s)
spid=16414 seq=1 pid=38967
refcnt=1
192.168.64.0/24[any] 172.18.1.0/24[any] any
out ipsec
esp/tunnel/192.168.8.253-172.19.1.254/require
created: Apr 22 18:43:20 2004 lastused: Apr 27 15:04:42 2004
lifetime: 0(s) validtime: 0(s)
spid=16413 seq=0 pid=38967
refcnt=1
---------- Cut Here ----------
These just tell my system that any traffic between 192.168.64.0/24 (my
internal network) and 172.18.1.0/24 (the internal network at the other
office) is to be sent through the IPSEC tunnel between 192.168.8.253 (my
system's external IP address) and 172.19.1.254 (the PIX's external IP
address). I've changed the external IP address of the PIX here, because
I'd get shot if I didn't obscure it. The external address of my end is
correct, because we've also got NAT between us and the outside world.
NAT traversal is automagic, so you don't need to explicitly set anything
for that. Just note that there's no AH specified in the policy, because
NAT destroys that.
You need one policy in each direction, otherwise the traffic will only be
encrypted one way and come back in the clear.
And my racoon.conf:
---------- Cut Here ----------
path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;
remote 172.19.1.254
{
exchange_mode aggressive,main,base ;
lifetime time 3600 sec ;
proposal_check obey ;
my_identifier address public.ip.address ;
# peers_identifier address 172.19.1.254 ;
peers_identifier fqdn "pix-FQDN" ;
proposal {
encryption_algorithm 3des ;
hash_algorithm sha1 ;
authentication_method pre_shared_key ;
dh_group 2 ;
}
}
sainfo address 192.168.64.0/24 any address 172.18.1.0/24 any
{
pfs_group 2 ;
lifetime time 3600 sec ;
encryption_algorithm 3des ;
authentication_algorithm hmac_sha1 ;
compression_algorithm deflate ;
}
---------- Cut Here ----------
The "remote 172.19.1.254" clause sets up the authentication of the far
end, using the outside interface of the PIX as the connection endpoint.
Not that if you're behind a NAT device, the "my_identifier address
nnn.nnn.nnn.nnn" needs to list the publically-reachable IP address you
have on the *outside of your NAT system*. If it doesn't, the PIX won't
know who on Earth you are, and you'll never get anywhere.
The sainfo clause sets up the Security Associations for the connection,
once authentication has happened successfully, and sets the lifetime of
the key before it's renegotiated.
You'll need to run racoon in the forground, with debugging (racoon -Fd)
on, to make sure all is happening as it should - the contractor they
employed to set up the PIX on the other end told me that it would identify
using the external IP address, but it didn't - it was actually using the
FQDN. If they get that wrong, phase one negotiation will fail, but you'll
see why in the racoon debugging output and you can change your
configuration to suit. If you don't run racoon with debugging output on,
you'll have no idea why it fails. If they're using an FQDN, you'll need
to use aggressive mode, too.
Other useful hint: when you're trying this out, run tcpdump on your
external interface and watch for traffic between the two points. You
should, with luck, see something like this (this is me pinging a host on
the other network from my workstation):
09:53:47.773446 et.dmz.endace.com.isakmp > 172.19.1.254.isakmp: isakmp: phase 1 I agg: [|sa]
09:53:48.020416 172.19.1.254.isakmp > et.dmz.endace.com.isakmp: isakmp: phase 1 R agg: [|sa]
09:53:48.106313 et.dmz.endace.com.isakmp > 172.19.1.254.isakmp: isakmp: phase 1 I agg:
(hash: len=20)
09:53:48.143999 et.dmz.endace.com.isakmp > 172.19.1.254.isakmp: isakmp: phase 2/others I oakley-quick[E]: [encrypted hash]
09:53:48.186311 172.19.1.254.isakmp > et.dmz.endace.com.isakmp: isakmp: phase 2/others R inf[E]: [encrypted hash]
09:53:48.418007 172.19.1.254.isakmp > et.dmz.endace.com.isakmp: isakmp: phase 2/others R oakley-quick[E]: [encrypted hash]
09:53:48.418535 et.dmz.endace.com.isakmp > 172.19.1.254.isakmp: isakmp: phase 2/others I oakley-quick[E]: [encrypted hash]
09:53:48.718121 et.dmz.endace.com > 172.19.1.254: ESP(spi=0x59e2cbc4,seq=0x1)
09:53:49.718966 et.dmz.endace.com > 172.19.1.254: ESP(spi=0x59e2cbc4,seq=0x2)
09:53:50.719788 et.dmz.endace.com > 172.19.1.254: ESP(spi=0x59e2cbc4,seq=0x3)
09:53:51.720623 et.dmz.endace.com > 172.19.1.254: ESP(spi=0x59e2cbc4,seq=0x4)
09:53:52.721443 et.dmz.endace.com > 172.19.1.254: ESP(spi=0x59e2cbc4,seq=0x5)
09:53:53.722293 et.dmz.endace.com > 172.19.1.254: ESP(spi=0x59e2cbc4,seq=0x6)
09:53:54.723114 et.dmz.endace.com > 172.19.1.254: ESP(spi=0x59e2cbc4,seq=0x7)
The isakmp stuff is the initial tunnel setup; it takes a few seconds (and
will be repeated every so often depending on your sainfo lifetime
setting), and the rest is encrypted traffic through the tunnel. If your
IKE setup isn't right, the isakmp setup won't finish and you'll never see
any ESP traffic at all.
I hope this helps; if not, just give me a yell and I'll happily work
through the details with you.
Cheers
Richard
--
Richard Stevenson : Geek
___________________________________________________________________
Sheffield Linux User's Group -
http://www.sheflug.co.uk/mailfaq.html
GNU the choice of a complete generation.