From owner-freebsd-net@FreeBSD.ORG Fri Dec 11 21:43:53 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C10FE106566B for ; Fri, 11 Dec 2009 21:43:53 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 5631C8FC0A for ; Fri, 11 Dec 2009 21:43:52 +0000 (UTC) Received: from 192.168.98.96 ([192.168.98.96]) by edusrv05.edu.irc.local ([192.168.44.14]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Dec 2009 21:44:12 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 11 Dec 2009 22:43:50 +0100 From: Jon Otterholm To: Mike Tancsa , Message-ID: Thread-Topic: Racoon site-to site Thread-Index: Acp6qwZ34SnkiTViAkOKWl1/eAMsIQ== In-Reply-To: <200912111923.nBBJNLk3072715@lava.sentex.ca> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Subject: Re: Racoon site-to site X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 21:43:53 -0000 On 2009-12-11 20.23, "Mike Tancsa" wrote: > At 11:33 AM 12/11/2009, David DeSimone wrote: >> Jon Otterholm wrote: >>>=20 >>> If I restart racoon or wait approximately 30 min the connection is >>> re-established. >>=20 >> Since this is approximately =C2=BDof the phase 2 lifetime, you are probably >> running into lifetime negotiation issues, or PFS issues. >>=20 >>> What would be the obvious way to debug this? Any suggestions on what >>> to tweak appreciated. >>=20 >> I would turn up the debugging on racoon to get more information around >> the time that the tunnel fails. >>=20 >>> sainfo (address 192.168.1.0/24 any address 192.168.100.0/24 any) >>> { >>> pfs_group 1; >>> lifetime time 3600 sec; >>> encryption_algorithm des; >>> authentication_algorithm hmac_md5,hmac_sha1; >>> compression_algorithm deflate; >>> } >>=20 >> My hunch is that you have a PFS mismatch, so that the first tunnel >> negotiates, but the second SA negotiation fails, then the third >> succeeds, etc. >=20 >=20 > You might also want to turn on DPD (dead peer > detection) in ipsectools if you dont already have > it on both sides. Are you really using des for > the crypto ? Also, when the session is > negotiated, take a look at the output of > setkey -D > and see what was actually negotiated and post it > here (just make sure you get rid of the info on the E and A lines. >=20 > e.g. > 1.1.1.2 2.2.2.2 > esp mode=3Dtunnel spi=3D125444787(0x077a22b3) reqid=3D16416(0x00004020= ) > E: 3des-cbc 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd7b 770cdd= 7b > A: hmac-sha1 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb 5cfdbabb >=20 > ie. mask out the 5cfdbabb and 770cdd7b values > before posting as thats your crypto :) >=20 >=20 >=20 > Also, when things "jam up", try instead, >=20 > racoonctl vpn-disconnect >=20 > and you wont have to restart things. >=20 > Also, what does > sysctl net.key.preferred_oldsa >=20 > show ? It has not jamed up yet but here is output from sysctl: net.key.preferred_oldsa: 1 Would it help setting it to 0 to force renewal of keys at reconnection? //Jon