[strongSwan] OpenSwan to StrongSwan migration (with CA): VPN not working

Wed Oct 17 20:17:27 CEST 2012

OK, I fixed left=216.130.102.66 and set keyexchange=ikev1.  Now I get
ISAKMP SA established.  But it doesn't go further.

Oct 17 14:01:20 cw1 pluto[5800]: "sslvpn"[232] 66.127.20.234 #120: sent MR3, ISAKMP SA established
Oct 17 14:01:20 cw1 pluto[5800]: "sslvpn"[232] 66.127.20.234 #120: ignoring informational payload, type INVALID_CERT_AUTHORITY

On the netgear, I see
1970 Jan  2 22:33:25 [FVS336GV2] [IKE] Phase 1 negotiation failed due to time
up for 216.130.102.66[500]. c35fe100eb0245fa:c72190af9640c381_
...
1970 Jan  2 22:34:11 [FVS336GV2] [IKE] the peer's certificate is not
verified._

So now my original CA / cert questions may apply.  I'm pretty sure my
CA is correct (it worked last week, but that was openswan).  Could it
be an encoding issue?  The IKE policy on the Netgear is configured for
3DES SHA-1 with DH Group 2 (1024 bit).  Can I make strongswan do that?

On Wed, Oct 17, 2012 at 07:16:22PM +0200, Andreas Steffen wrote:
> Hi,
> 
> you define
> 
>  left=192.168.101.254
> 
> but the IKE messages arrive on an interface with
> IP address 216.130.102.66:
> 
>   packet from 123.123.123.123:500:
>   initial Main Mode message received on 216.130.102.66:500
>   but no connection has been authorized with policy=PUBKEY
> 
> no wonder that no match can be achieved!
> 
> Andreas
> 
> On 10/17/2012 04:11 PM, CJ Fearnley wrote:
> > After a T1 outage left OpenSwan useless (again), I decided it was time
> > to try StrongSwan.  The system uses a local CA on the server.  Keys and
> > certs are in /etc/ipsec.d where we created them for OpenSwan.  Nice that
> > no change seems to be necessary there.  It is a Debian Squeeze system,
> > so I'm using the 4.4.1-5.2 version of the strongswan package.
> > 
> > I'm testing this ipsec.onf (loosely based on
> > http://www.strongswan.org/uml/testresults/ikev2/net2net-cert):
> > 
> > config setup
> >     charonstart=yes
> >     plutostart=yes
> >     virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.101.0/24
> >     # nat_traversal=yes
> > 
> > conn %default
> >     ikelifetime=60m
> >     keylife=20m
> >     rekeymargin=3m
> >     keyingtries=1
> >     mobike=no
> >     keyexchange=ikev2
> > 
> > conn sslvpn
> >     left=192.168.101.254
> >     leftid="C=US, ST=IL, L=Glenwood, O=PRIVACY, CN=PRIVACY.PRIVACY.com, E=priv at privacy.com"
> >     leftsendcert=always
> >     leftsubnet=192.168.101.0/24
> >     leftcert=PRIVACY.crt
> >     right=%any
> >     rekey=yes
> >     auto=add
> > 
> > The other end is a NETGEAR ProSafe VPN Firewall FVS336GV2 configured for
> > 3DES encryption and SHA-1 authentication.  auth.log reports (IP changed
> > for privacy):
> > 
> > Oct 17 09:48:34 cw1 pluto[13499]: added connection description "sslvpn"
> > Oct 17 09:48:38 cw1 pluto[13499]: packet from 123.123.123.123:500: ignoring Vendor ID payload [810fa565f8ab14369105d706fbd57279]
> > Oct 17 09:48:38 cw1 pluto[13499]: packet from 123.123.123.123:500: received Vendor ID payload [Dead Peer Detection]
> > Oct 17 09:48:38 cw1 pluto[13499]: packet from 123.123.123.123:500: initial Main Mode message received on 216.130.102.66:500 but no connection has been authorized with policy=PUBKEY
> > 
> > ipsec status
> > Security Associations:
> >   none
> > 
> > I tried keyexchange=ike with nat_traversal with similar failures.
> > 
> > How can I test that the client keys are OK?
> > 
> > I tried
> > 
> > lfcjf at cw1:~$ cat /etc/lfrr/ssl/keys/grandrapids2 at PRIVACY.com.crt|sudo ipsec pki --print
> > plugin 'test-vectors' failed to load: /usr/lib/ipsec/plugins/libstrongswan-test-vectors.so: cannot open shared object file: No such file or directory
> > plugin 'revocation' failed to load: /usr/lib/ipsec/plugins/libstrongswan-revocation.so: cannot open shared object file: No such file or directory
> > cert:      X509
> > subject:  "CN=PRIVACY"
> > issuer:   "C=US, ST=IL, L=Glenwood, O=PRIVACY, CN=PRIVACY VPN Services CA, E=priv at privacy.com"
> > validity:  not before Apr 13 16:19:21 2012, ok
> >            not after  Apr 11 16:19:21 2022, ok (expires in 3463 days)
> > serial:    37
> > flags:     clientAuth 
> > authkeyId: 4f:6d:db:66:40:aa:53:93:c8:e0:0b:dd:21:d3:79:c8:9f:c0:10:52
> > subjkeyId: a9:fb:5e:c5:b5:7a:5a:3e:0d:24:1c:81:41:25:8c:1d:06:d3:e0:4e
> > pubkey:    RSA 1024 bits
> > keyid:     87:3f:a3:23:c2:c2:ea:1f:e3:de:11:97:b2:b2:d0:f3:15:fc:7b:59
> > subjkey:   a9:fb:5e:c5:b5:7a:5a:3e:0d:24:1c:81:41:25:8c:1d:06:d3:e0:4e
> > 
> > Does that mean the client key is correctly signed and valid?  If so why
> > isn't the tunnel working?
> > 
> > Again, the Netgear and certs worked last week.  But a T1 outage, random
> > other confounding factors, and a sophisticated but error prone admin
> > (me) mean that something dumb is as likely as something subtle.
> > 
> > What should I try next?

-- 
CJ Fearnley                 |   LinuxForce Inc.
cjf at LinuxForce.net          |   IT Projects & Systems Maintenance
http://www.LinuxForce.net   |   http://blog.remoteresponder.net