May not apply to your case, but good to keep in mind anyway :):
We have had issues creating VPN's between IOS-Routers+3DES and
VPN-Concentrators; the issue came down to a disagreement as to the default
DH group ... IOS defaulted to group 1 while Concentrator defaulted to group
2. Drove us crazy.
IOS
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
another ugly workaround we have used is to switch from esp-md5-hmac to
esp-sha-hmac ... when going from PIXen to VPN Concentrators. I suspect, bu
have never _actually_ verified that the issue would be the same as above;
with the PIXen defaulting to group 1 ... ?
HTH.
Thanks!
TJ
((As always - anything I say may not apply to your environment, in more
recent code releases or I may have mis-read something and this may not even
relate to the conversation ... ))
-----Original Message-----
From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 30, 2002 6:04 PM
To: [EMAIL PROTECTED]
Subject: RE: VPN not connecting [7:50144]
I'm just learning this stuff, so I apoligize if I'm getting in the way, but
see my comments below.
[EMAIL PROTECTED] wrote:
>
> I've gotten both sides of a VPN connected (site to site
> 501/515, static IPs,
> pre-shared keys, truly a basic setup). While trying to ping
> the other
> network, with debug running, I get the following output; but no
> connection.....
>
> VPN Peer: ISAKMP: Added new peer: ip:X.X.X.X Total VPN Peers:1
> VPN Peer: ISAKMP: Peer ip:X.X.X.X Ref cnt incremented to:1
> Total VPN Peers:
> 1
>
> ISAKMP (0): beginning Main Mode exchange
> crypto_isakmp_process_block: src X.X.X.X, dest Y.Y.Y.Y
> OAK_MM exchange
> ISAKMP (0): processing SA payload. message ID = 0
>
> ISAKMP (0): Checking ISAKMP transform 1 against priority 20
> policy
> ISAKMP: encryption 3DES-CBC
> ISAKMP: hash SHA
> ISAKMP: default group 2
> ISAKMP: auth pre-share
> ISAKMP: life type in seconds
> ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
> ISAKMP (0): atts are acceptable. Next payload is 0
> ISAKMP (0): SA is doing pre-shared key authentication using id
> type
> ID_IPV4_ADDR
>
> return status is IKMP_NO_ERROR
That's good news. The peers agree on the hash algorithm, that they are using
preshared keys, etc.
> crypto_isakmp_process_block: src X.X.X.X, dest Y.Y.Y.Y
> OAK_MM exchange
> ISAKMP (0): processing KE payload. message ID = 0
>
> ISAKMP (0): processing NONCE payload. message ID = 0
>
> ISAKMP (0): processing vendor id payload
>
> ISAKMP (0): processing vendor id payload
>
> ISAKMP (0): remote peer supports dead peer detection
>
> ISAKMP (0): processing vendor id payload
>
> ISAKMP (0): speaking to another IOS box!
>
> ISAKMP (0): ID payload
> next-payload : 8
> type : 1
> protocol : 17
> port : 500
> length : 8
> ISAKMP (0): Total payload length: 12
> return status is IKMP_NO_ERROR
Still in good shape at this point...
> ISAKMP (0): retransmitting phase 1...IPSEC(key_engine): request
> timer fired:
This is where it goes haywire. It shouldn't have to restart ISAKMP Phase 1.
The preshared keys must be EXACTLY the same on both peers. Could there be a
typo in one of them? Could you retype them very carefully?
I suspect this is the problem simply because the preshared keys are compared
during Phase 1.
As someone else suggested, also check the IPSec access lists. Be sure not to
be confused by the fact that PIX does access lists with subnet masks, unlike
IOS which uses wildcard masks. Thank-you Cisco.
Once again, sorry if this is way offbase. I'm just learning all this cr*p.
Priscilla
> cou
> nt = 1,
> (identity) local= Y.Y.Y.Y, remote= X.X.X.X,
> local_proxy= Jabbers_VPN/255.255.255.224/0/0 (type=4),
> remote_proxy= 10.10.0.0/255.255.0.0/0/0 (type=4)
>
> ISAKMP (0): retransmitting phase 1...
> ISAKMP (0): deleting SA: src Y.Y.Y.Y, dst X.X.X.X
> ISADB: reaper checking SA 0x80a4c6f0, conn_id = 0 DELETE IT!
>
> VPN Peer: ISAKMP: Peer ip:X.X.X.X Ref cnt decremented to:0
> Total VPN Peers:
> 1
> VPN Peer: ISAKMP: Deleted peer: ip:X.X.X.X Total VPN
> peers:0IPSEC(key_engin
> e): request timer fired: count = 2,
> (identity) local= Y.Y.Y.Y, remote= X.X.X.X,
> local_proxy= Jabbers_VPN/255.255.255.224/0/0 (type=4),
> remote_proxy= 10.10.0.0/255.255.0.0/0/0 (type=4)
>
> Any help/insight is Greatly appreciated.
> Thanx,
> mkj
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Michael Jablonski
> ABN AMRO Asset Management Holdings, Inc.
> 161 North Clark St.
> 9th Flr
> Chicago, IL 60601-2468
> PH: 312.884.2996
> FAX: 312.278.5550
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.
*****************************************************************************
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=50254&t=50144
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
