Date: Fri, 11 Dec 2009 22:43:50 +0100 From: Jon Otterholm <jon.otterholm@ide.resurscentrum.se> To: Mike Tancsa <mike@sentex.net>, <freebsd-net@freebsd.org> Subject: Re: Racoon site-to site Message-ID: <C7487BA6.31D78%jon.otterholm@ide.resurscentrum.se> In-Reply-To: <200912111923.nBBJNLk3072715@lava.sentex.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2009-12-11 20.23, "Mike Tancsa" <mike@sentex.net> wrote:
> At 11:33 AM 12/11/2009, David DeSimone wrote:
>> Jon Otterholm <jon.otterholm@ide.resurscentrum.se> 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 <remote peer's IP>
>=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C7487BA6.31D78%jon.otterholm>