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

quoted text
> Hi ,

Hi.
>       As per suggestion,  The following are the logs generated by  racoon :

quoted text
>

[....]

quoted text
> 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 :-)
[....]

quoted text
> 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).
[....]

quoted text
> 2007-11-17 13:46:22: DEBUG: 84 bytes message received from 203.91.130.173[500] to 202.70.87.123[500]

[....]

quoted text
> 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 ?
[....]

quoted text
> 2007-11-17 13:46:32: DEBUG: resend phase1 packet a40e0e86c6a792cc:082dacfe812390c3

[....]

quoted text
> 2007-11-17 13:46:42: DEBUG: resend phase1 packet a40e0e86c6a792cc:082dacfe812390c3

[....]

quoted text
> 2007-11-17 13:46:52: DEBUG: resend phase1 packet a40e0e86c6a792cc:082dacfe812390c3

[....]

quoted text
> 2007-11-17 13:47:02: DEBUG: resend phase1 packet a40e0e86c6a792cc:082dacfe812390c3

[....]

quoted text
> 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-security@freebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-security

To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"