[Openswan Users] OpenSWAN 2.4.12 doesn't create complete IPSec NETKEY policy on Debian Etch?
Mark Cave-Ayland
mark.cave-ayland at siriusit.co.uk
Thu Jun 19 11:08:18 EDT 2008
Hi there,
I'm currently trying to create a VPN between 2 servers running Debian
Etch (using OpenSwan 2.4.12 locally and OpenSwan 2.4.6 remotely), and I
am experiencing a strange problem whereby only the outgoing IPSec
security policy is created at the local server. I'll see if I can
explain the situation further below:
Local Server
------------
ppp0/ppp1: Link to internet (these are load balanced using iproute2)
The main IP range (A.B.C.*) is routed over these links
eth0: 192.168.1.1
eth1: 192.168.2.1
eth2: 192.168.3.1
A.B.C.1
The aim of the setup is to allow access to a remote 192.168.10.x network
across the internet. My initial experiments involve simply forwarding
traffic from the 192.168.1.x network across the tunnel to the
192.168.10.x network using the following ipsec.conf:
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
# NAT-TRAVERSAL support, see README.NAT-Traversal
nat_traversal=yes
#
# enable this if you see "failed to find any available worker"
# nhelpers=0
plutodebug="none"
klipsdebug="none"
conn NETA-NETB
left=A.B.C.D
leftcert=/etc/ipsec.d/certs/mycert.pem
leftid="CN=ipsec.local.co.uk"
leftsubnet=192.168.1.0/24
right=E.F.G.H
rightid="CN=ipsec.remote.co.uk"
rightsubnet=192.168.10.0/24
type=tunnel
auto=add
Now I can bring up the tunnel using "ip auto --up NETA-NETB" without any
problems; I can see the security negotiations taking place and the
correct entries are placed in the routing tables. However, I can't seem
to contact any machines on the remote 192.168.10.x network from the
local end.
I tried to test the tunnel by pinging a machine on the remote network,
and using tcpdump I can see the ESP packets leaving the local server,
and an incoming ESP packet coming back in response. But it seems that
the incoming response is being dropped when it gets back to the local
server.
Looking further into this, it appears as if the IPSec policy is not
being properly created at the local end. If I run "setkey -DP" on the
local server then I see the following:
192.168.1.0/24[any] 192.168.10.0/24[any] any
out ipsec
esp/tunnel/A.B.C.D-E.F.G.H/unique#16389
created: Jun 18 12:22:45 2008 lastused:
lifetime: 0(s) validtime: 0(s)
spid=15745 seq=1 pid=14444
refcnt=1
This contrasts to the remote end which looks like this:
192.168.1.0/24[any] 192.168.10.0/24[any] any
in ipsec
esp/tunnel/A.B.C.D-E.F.G.H/unique#16393
created: Jun 18 16:39:54 2008 lastused:
lifetime: 0(s) validtime: 0(s)
spid=648 seq=17 pid=4425
refcnt=1
192.168.10.0/24[any] 192.168.1.0/24[any] any
out ipsec
esp/tunnel/A.B.C.D-E.F.G.H/unique#16393
created: Jun 18 16:39:54 2008 lastused:
lifetime: 0(s) validtime: 0(s)
spid=665 seq=14 pid=4425
refcnt=1
192.168.1.0/24[any] 192.168.10.0/24[any] any
fwd ipsec
esp/tunnel/A.B.C.D-E.F.G.H/unique#16393
created: Jun 18 16:39:54 2008 lastused:
lifetime: 0(s) validtime: 0(s)
spid=658 seq=11 pid=4425
refcnt=1
So, in other words, there is only an outgoing ipsec policy on the local
server - no in or fwd ipsec policies are created. I suspect what
is happening is that the incoming responses are being dropped because
there is no corresponding policy in place.
If I enable klips debugging at both ends then I see this:
Local server:
Jun 18 17:09:55 local pluto[21482]: | processing connection NETA-NETB
Jun 18 17:09:55 local pluto[21482]: "NETA-NETB" #1: initiating Main Mode
Jun 18 17:09:55 local pluto[21482]: | processing connection NETA-NETB
Jun 18 17:09:55 local pluto[21482]: "NETA-NETB" #1: ignoring unknown
Vendor ID payload [4f456c4c4f5d5264574e5244]
Jun 18 17:09:55 local pluto[21482]: "NETA-NETB" #1: received Vendor ID
payload [Dead Peer Detection]
Jun 18 17:09:55 local pluto[21482]: "NETA-NETB" #1: received Vendor ID
payload [RFC 3947] method set to=109
Jun 18 17:09:55 local pluto[21482]: | ike_alg_enc_ok(ealg=5,key_len=0):
blocksize=8, keyminlen=192, keydeflen=192, keymaxlen=192, ret=1
Jun 18 17:09:55 local pluto[21482]: "NETA-NETB" #1: enabling possible
NAT-traversal with method RFC 3947 (NAT-Traversal)
Jun 18 17:09:55 local pluto[21482]: | processing connection NETA-NETB
Jun 18 17:09:55 local pluto[21482]: "NETA-NETB" #1: transition from
state STATE_MAIN_I1 to state STATE_MAIN_I2
Jun 18 17:09:55 local pluto[21482]: "NETA-NETB" #1: STATE_MAIN_I2: sent
MI2, expecting MR2
Jun 18 17:09:56 local pluto[21482]: | processing connection NETA-NETB
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #1: NAT-Traversal:
Result using RFC 3947 (NAT-Traversal): no NAT detected
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #1: I am sending my cert
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #1: I am sending a
certificate request
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #1: transition from
state STATE_MAIN_I2 to state STATE_MAIN_I3
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #1: STATE_MAIN_I3: sent
MI3, expecting MR3
Jun 18 17:09:56 local pluto[21482]: | processing connection NETA-NETB
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #1: Main mode peer ID is
ID_DER_ASN1_DN: 'CN=remote'
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #1: no crl from issuer
"CN=remote" found (strict=no)
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #1: transition from
state STATE_MAIN_I3 to state STATE_MAIN_I4
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #1: STATE_MAIN_I4:
ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192
prf=oakley_md5 group=modp1536}
Jun 18 17:09:56 local pluto[21482]: | processing connection NETA-NETB
Jun 18 17:09:56 local pluto[21482]: "NETA-NETB" #2: initiating Quick
Mode RSASIG+ENCRYPT+COMPRESS+TUNNEL+PFS+DISABLEARRIVALCHECK+UP {using
isakmp#1}
Jun 18 17:09:56 local pluto[21482]: | processing connection NETA-NETB
Jun 18 17:09:56 local pluto[21482]: | netlink_get_spi: allocated
0x8df67116 for esp.0 at A.B.C.D
Jun 18 17:09:56 local pluto[21482]: | netlink_get_spi: allocated 0xe5b9
for comp.0 at A.B.C.D
Jun 18 17:09:56 local pluto[21482]: | processing connection NETA-NETB
Jun 18 17:09:56 local pluto[21482]: | eroute_connection add eroute
192.168.1.0/24:0 --0-> 192.168.10.0/24:0 => tun.0 at E.F.G.H (raw_eroute)
Jun 18 17:09:57 local pluto[21482]: "NETA-NETB" #2: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2
Jun 18 17:09:57 local pluto[21482]: "NETA-NETB" #2: STATE_QUICK_I2: sent
QI2, IPsec SA established {ESP=>0xd5797e7c <0x8df67116
xfrm=AES_0-HMAC_SHA1 IPCOMP=>0x00006315 <0x0000e5b9 NATD=none DPD=none}
Remote server:
Jun 18 17:00:35 remote pluto[4197]: | processing connection NETB-NETA
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: initiating Main Mode
Jun 18 17:00:35 remote pluto[4197]: | processing connection NETB-NETA
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: ignoring unknown
Vendor ID payload [4f45606c50487c5662707575]
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: received Vendor ID
payload [Dead Peer Detection]
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: received Vendor ID
payload [RFC 3947] method set to=110
Jun 18 17:00:35 remote pluto[4197]: | ike_alg_enc_ok(ealg=5,key_len=0):
blocksize=8, keyminlen=192, keydeflen=192, keymaxlen=192, ret=1
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: enabling possible
NAT-traversal with method 3
Jun 18 17:00:35 remote pluto[4197]: | processing connection NETB-NETA
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: transition from
state STATE_MAIN_I1 to state STATE_MAIN_I2
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: STATE_MAIN_I2: sent
MI2, expecting MR2
Jun 18 17:00:35 remote pluto[4197]: | processing connection NETB-NETA
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: NAT-Traversal:
Result using 3: no NAT detected
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: I am sending my cert
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: I am sending a
certificate request
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: transition from
state STATE_MAIN_I2 to state STATE_MAIN_I3
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: STATE_MAIN_I3: sent
MI3, expecting MR3
Jun 18 17:00:35 remote pluto[4197]: | processing connection NETB-NETA
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: Main mode peer ID
is ID_DER_ASN1_DN: 'CN=local'
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: ocsp status is
stale or not in cache
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: transition from
state STATE_MAIN_I3 to state STATE_MAIN_I4
Jun 18 17:00:35 remote pluto[4197]: "NETB-NETA" #35: STATE_MAIN_I4:
ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192
prf=oakley_md5 group=modp1536}
Jun 18 17:00:36 remote pluto[4197]: | processing connection NETB-NETA
Jun 18 17:00:36 remote pluto[4197]: "NETB-NETA" #37: initiating Quick
Mode RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#35}
Jun 18 17:00:36 remote pluto[4197]: | processing connection NETB-NETA
Jun 18 17:00:36 remote pluto[4197]: | netlink_get_spi: allocated
0x1e7d8526 for esp.0 at E.F.G.H
Jun 18 17:00:36 remote pluto[4197]: | processing connection NETB-NETA
Jun 18 17:00:36 remote pluto[4197]: | add inbound eroute
192.168.1.0/24:0 --0-> 192.168.10.0/24:0 => tun.10000 at E.F.G.H (raw_eroute)
Jun 18 17:00:36 remote pluto[4197]: | eroute_connection replace eroute
192.168.10.0/24:0 --0-> 192.168.1.0/24:0 => tun.0 at A.B.C.D (raw_eroute)
Jun 18 17:00:36 remote pluto[4197]: "NETB-NETA" #37: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2
Jun 18 17:00:36 remote pluto[4197]: "NETB-NETA" #37: STATE_QUICK_I2:
sent QI2, IPsec SA established {ESP=>0x1a62fac9 <0x1e7d8526
xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}
AIUI the part of interest is that the logs on the local server are
missing the "add inbound eroute" part which is why the in and fwd
policies are missing from the setkey output - but I have absolutely no
idea why. Can anyone help explain how I can get the IPSec VPN set up to
work in both directions?
Many thanks,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
More information about the Users
mailing list