OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: IPSEC help

From: VANHULLEBUS Yvan (vanhu_bsdzeninc.net)
Date: Mon Nov 19 2007 - 03:38:29 CST


On Sat, Nov 17, 2007 at 01:06:32AM -0800, john decot wrote:
> Hi ,

Hi.

> As per suggestion, The following are the logs generated by racoon :
>
[....]
> 2007-11-17 13:46:22: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
> 2007-11-17 13:46:22: INFO: received Vendor ID: FRAGMENTATION
> 2007-11-17 13:46:22: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

Some people should learn that an RFC has been published for NAT-T :-)

[....]
> 2007-11-17 13:46:22: DEBUG: Compared: DB:Peer
> 2007-11-17 13:46:22: DEBUG: (lifetime = 1800:28800)
> 2007-11-17 13:46:22: DEBUG: (lifebyte = 0:0)
> 2007-11-17 13:46:22: DEBUG: enctype = 3DES-CBC:3DES-CBC
> 2007-11-17 13:46:22: DEBUG: (encklen = 0:0)
> 2007-11-17 13:46:22: DEBUG: hashtype = SHA:SHA
> 2007-11-17 13:46:22: DEBUG: authmethod = RSA signatures:RSA signatures
> 2007-11-17 13:46:22: DEBUG: dh_group = 1024-bit MODP group:1024-bit MODP group
> 2007-11-17 13:46:22: DEBUG: an acceptable proposal found.
> 2007-11-17 13:46:22: DEBUG: hmac(modp1024)

Ok, your racoon found "an acceptable proposal", even if DB's lifetime
is really shorter than peer's one.

That means you're in CLAIN or OBEY checkmode. Those modes are well
known to generate as much problems as they solve, you should really
consider using exact or at least strict checkmode, and fix your
lifetime in your configuration (on the side you want, but have the
same lifetime on both peers).

[....]
> 2007-11-17 13:46:22: DEBUG: 84 bytes message received from 203.91.130.173[500] to 202.70.87.123[500]
[....]
> 2007-11-17 13:46:22: ERROR: ignore information because ISAKMP-SA has not been established yet.

May be an INITIAL-CONTACT sent a bit too early, or may also be a
negociation related INFORMATIONAL message.
Could you do a network capture of a negociation, and have a look at
that message in a tool like wireshark, to have more details ?

[....]
> 2007-11-17 13:46:32: DEBUG: resend phase1 packet a40e0e86c6a792cc:082dacfe812390c3
[....]
> 2007-11-17 13:46:42: DEBUG: resend phase1 packet a40e0e86c6a792cc:082dacfe812390c3
[....]
> 2007-11-17 13:46:52: DEBUG: resend phase1 packet a40e0e86c6a792cc:082dacfe812390c3
[....]
> 2007-11-17 13:47:02: DEBUG: resend phase1 packet a40e0e86c6a792cc:082dacfe812390c3
[....]
> 2007-11-17 13:47:12: DEBUG: resend phase1 packet a40e0e86c6a792cc:082dacfe812390c3
> 2007-11-17 13:47:22: ERROR: phase1 negotiation failed due to time up. a40e0e86c6a792cc:082dacfe812390c3

Really looks like the peer did not like the answer we sent, so did not
respond to it (or sent an informational which has not been handled).

Fix your lifetimes, switch to strict checkmode, fix any other
negociation parameter which may generate an error now you're in strict
checkmode, and if that still don't work, have a look at the
INFORMATIONAL message sent by your peer, and/or have a look at any log
on your peer.

Yvan.

--
NETASQ
http://www.netasq.com
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribefreebsd.org"