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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=50192&t=50144 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
