[Openswan Users] Again... no luck: no connection is known

Tue Jul 24 17:53:25 EDT 2007

Hi,

again I'm struggling with an OpenSwan setup...

The setup:

Roadwarrior - NAT'ing router - Internet - Nat'ing router - VPN Gateway

The VPN Gateway has the IP address 172.20.3.100 and it gets forwarded 
all traffic to udp ports 500 and 4500 reaching its router at the 
external interface. The routers internal IP is 172.20.3.1.

The VPN Gateway is running Linux Openswan U2.2.0/K2.6.8-24.19-smp (native)

It has certificates etc. installed. The connection is set up like this:

version 2.0
config setup
         interfaces="ipsec0=eth0"
         nat_traversal=yes
         plutowait=yes

virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!172.20.0.0/
16

conn test
         authby=rsasig
         auto=add
         keyingtries=3
         left=172.20.3.100
         leftnexthop=172.20.3.1
         leftprotoport=17/1701
         leftcert=VPNGW-cert.pem
         leftrsasigkey=%cert
         pfs=no
         rekey=no
         right=%any
         rightprotoport=17/1701
         rightrsasigkey=%cert
         rightsubnet=vhost:%no,%priv

In the log, when I try to connect from the Road warrior (Windows 
Vista, IPsec/L2TP, certificates and CA certificates installed so it 
does trust the VPN gateway) I get:

> Jul 24 23:28:33 com ipsec__plutorun: Starting Pluto subsystem...
> Jul 24 23:28:33 com pluto[20391]: Starting Pluto (Openswan Version 2.2.0 X.509-1.5.4 PLUTO_USES_KEYRR)
> Jul 24 23:28:33 com pluto[20391]:   including NAT-Traversal patch (Version 0.6c)
> Jul 24 23:28:33 com pluto[20391]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
> Jul 24 23:28:33 com pluto[20391]: Using Linux 2.6 IPsec interface code
> Jul 24 23:28:33 com pluto[20391]: Changing to directory '/etc/ipsec.d/cacerts'
> Jul 24 23:28:33 com pluto[20391]:   loaded CA cert file 'XXXXXX-cacert.pem' (2359 bytes)
> Jul 24 23:28:33 com pluto[20391]:   loaded CA cert file 'XXXXXX-VPN-cacert.pem' (1802 bytes)
> Jul 24 23:28:33 com pluto[20391]: Could not change to directory '/etc/ipsec.d/aacerts'
> Jul 24 23:28:33 com pluto[20391]: Could not change to directory '/etc/ipsec.d/ocspcerts'
> Jul 24 23:28:33 com pluto[20391]: Changing to directory '/etc/ipsec.d/crls'
> Jul 24 23:28:33 com pluto[20391]:   Warning: empty directory
> Jul 24 23:28:34 com pluto[20391]:   loaded host cert file '/etc/ipsec.d/certs/VPNGW-cert.pem' (1262 bytes)
> Jul 24 23:28:34 com pluto[20391]: added connection description "test"
> Jul 24 23:28:34 com pluto[20391]: listening for IKE messages
> Jul 24 23:28:34 com pluto[20391]: adding interface eth0/eth0 172.20.3.100
> Jul 24 23:28:34 com pluto[20391]: adding interface eth0/eth0 172.20.3.100:4500
> Jul 24 23:28:34 com pluto[20391]: adding interface lo/lo 127.0.0.1
> Jul 24 23:28:34 com pluto[20391]: adding interface lo/lo 127.0.0.1:4500
> Jul 24 23:28:34 com pluto[20391]: adding interface lo/lo ::1
> Jul 24 23:28:34 com pluto[20391]: loading secrets from "/etc/ipsec.secrets"
> Jul 24 23:28:34 com pluto[20391]:   loaded private key file '/etc/ipsec.d/private/VPNGW-key.pem' (952 bytes)
> Jul 24 23:29:09 com pluto[20391]: packet from 89.166.155.56:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000005]
> Jul 24 23:29:09 com pluto[20391]: packet from 89.166.155.56:500: ignoring Vendor ID payload [4a131c81070358455c5728f20e95452f]
> Jul 24 23:29:09 com pluto[20391]: packet from 89.166.155.56:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
> Jul 24 23:29:09 com pluto[20391]: packet from 89.166.155.56:500: ignoring Vendor ID payload [FRAGMENTATION]
> Jul 24 23:29:09 com pluto[20391]: packet from 89.166.155.56:500: ignoring Vendor ID payload [fb1de3cdf341b7ea16b7e5be0855f120]
> Jul 24 23:29:09 com pluto[20391]: packet from 89.166.155.56:500: ignoring Vendor ID payload [26244d38eddb61b3172a36e3d0cfb819]
> Jul 24 23:29:09 com pluto[20391]: packet from 89.166.155.56:500: ignoring Vendor ID payload [e3a5966a76379fe707228231e5ce8652]
> Jul 24 23:29:09 com pluto[20391]: "test"[1] 89.166.155.56 #1: responding to Main Mode from unknown peer 89.166.155.56
> Jul 24 23:29:09 com pluto[20391]: "test"[1] 89.166.155.56 #1: only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported.  Attribute OAKLEY_GROUP_DESCRIPTION
> Jul 24 23:29:09 com pluto[20391]: "test"[1] 89.166.155.56 #1: only OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported.  Attribute OAKLEY_GROUP_DESCRIPTION
> Jul 24 23:29:09 com pluto[20391]: "test"[1] 89.166.155.56 #1: transition from state (null) to state STATE_MAIN_R1
> Jul 24 23:29:09 com pluto[20391]: "test"[1] 89.166.155.56 #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: both are NATed
> Jul 24 23:29:09 com pluto[20391]: "test"[1] 89.166.155.56 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Jul 24 23:29:10 com pluto[20391]: "test"[1] 89.166.155.56 #1: Peer ID is ID_DER_ASN1_DN: 'C=DE, L=..., O=..., OU=Network, CN=..., E=al at its-lehmann.de'
> Jul 24 23:29:10 com pluto[20391]: "test"[1] 89.166.155.56 #1: no crl from issuer "C=DE, L=..., O=..., OU=Network, CN=XXXXXX VPN" found (strict=no)
> Jul 24 23:29:10 com pluto[20391]: "test"[1] 89.166.155.56 #1: no crl from issuer "C=DE, L=..., O=..., OU=CA, CN=XXXXXX CA, E=xx at xxxxxx.de" found (strict=no)
> Jul 24 23:29:10 com pluto[20391]: "test"[2] 89.166.155.56 #1: deleting connection "test" instance with peer 89.166.155.56 {isakmp=#0/ipsec=#0}
> Jul 24 23:29:10 com pluto[20391]: "test"[2] 89.166.155.56 #1: I am sending my cert
> Jul 24 23:29:10 com pluto[20391]: "test"[2] 89.166.155.56 #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Jul 24 23:29:10 com pluto[20391]: | NAT-T: new mapping 89.166.155.56:500/4500)
> Jul 24 23:29:10 com pluto[20391]: "test"[2] 89.166.155.56:4500 #1: sent MR3, ISAKMP SA established
> Jul 24 23:29:10 com pluto[20391]: "test"[2] 89.166.155.56:4500 #1: cannot respond to IPsec SA request because no connection is known for sta.tic.ipa.ddr/32===172.20.3.100:4500[C=DE, L=..., O=XXXXXX, OU=Network, CN=VPN Gateway, E=xx at xxxxxx.de]:17/1701...dyn.ami.cip.add:4500[C=DE, L=..., O=XXXXXX, OU=Network, CN=..., E=al at its-lehmann.de]:17/1701===192.168.0.88/32
> Jul 24 23:29:10 com pluto[20391]: "test"[2] 89.166.155.56:4500 #1: sending encrypted notification INVALID_ID_INFORMATION to dyn.ami.cip.add:4500
> Jul 24 23:29:12 com pluto[20391]: "test"[2] 89.166.155.56:4500 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)
> Jul 24 23:29:12 com pluto[20391]: "test"[2] 89.166.155.56:4500 #1: sending encrypted notification INVALID_MESSAGE_ID to dyn.ami.cip.add:4500
> Jul 24 23:29:15 com pluto[20391]: "test"[2] 89.166.155.56:4500 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x01000000 (perhaps this is a duplicated packet)

(Names and IPs removed to protect my customer from getting laughed at 
because I can't set up a VPN for him... groan)

Googling brought up some possible cures: Setting leftsubnet, setting 
rightsubnet, checking NAT traversal is on (which it is), setting 
rightca=%same, but all without getting successful connections or even 
different errors.

Somehow the connection is not known, but I don't know how I should 
define it differently. The left side is defined correctly, I assume, 
the right side does send the correct certificate, which should be 
accepted.

I wonder if anybody ever got IPsec working :-(
(And I wonder if I shouldn't engage a consultant... everyone says it's 
simple, the certificates already exist, so it should be a really quick 
task ;-)

Arno

-- 
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de