×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

PIX VPN Negotiation Messages

Unanswered Question
Nov 2nd, 2002
User Badges:

Can anyone help me decipher what these debug crypto isa messages mean, and how to go about correcting the situation?


<dest. ip> = address being contacted

<src. ip> = address initiating contact


The source device is a pix 501 connected to my cable modem at home. The destination is another pix 501 connected off of a dmz port on a cisco 2600 series router.


Thanks,

--Andy


VPN Peer: ISAKMP: Added new peer: ip:<dest. ip> Total VPN Peers:1

VPN Peer: ISAKMP: Peer ip:<dest. ip> Ref cnt incremented to:1 Total VPN Pee1ISAKMP (0): beginning Main Mode exchange


crypto_isakmp_process_block: src <dest. ip>, dest <src. ip>

OAK_MM exchange

ISAKMP (0): processing SA payload. message ID = 0


ISAKMP (0): Checking ISAKMP transform 1 against priority 1 policy

ISAKMP: encryption 3DES-CBC

ISAKMP: hash MD5

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_FQDN

return status is IKMP_NO_ERROR

crypto_isakmp_process_block: src <dest. ip>, dest <src. ip>

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 : 2

protocol : 17

port : 500

length : 26

ISAKMP (0): Total payload length: 30

return status is IKMP_NO_ERROR

ISAKMP (0): retransmitting phase 1...IPSEC(key_engine): request timer fired: co, (identity) local= <src. ip>, remote= <dest. ip>,

local_proxy= <src. ip>.0/255.255.255.0/0/0 (type=4),

remote_proxy= <dest. ip>.0/255.255.255.0/0/0 (type=4)


ISAKMP (0): retransmitting phase 1...

ISAKMP (0): deleting SA: src <src. ip>, dst <dest. ip>

ISADB: reaper checking SA 0x80963dd0, conn_id = 0 DELETE IT!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
gfullage Sun, 11/03/2002 - 16:24
User Badges:
  • Cisco Employee,

Without seeing the configs or the actual src and dst IP addresses, it's a little hard to figure out, but what it looks like is the remote PIX is trying to initiate a tunnel negotiation with this PIX. The first ISAKMP packet comes in, this PIX checks it, agrees on the parameters of the negotiation, then sends an ISAKMP packet back to the remote PIX. Nothing happens after this and a short time later, this PIX retransmits the packet. Again it gets nothing back, and it retransmits again.


What's possibly happening is that the ISAKMP packets from this PIX are not reaching the other one. Is the other one the one behind the 2600? Make sure it is allowing UDP port 500 packets through. Make sure the remote PIX has the "sysopt connection permit-ipsec" command in it. Can you run the debugs on the remote PIX and see if it loks like it's receiving any ISAKMP packets? Are you doing NAT on the 2600, and if so, do you have a static translation set up for the outside address of the PIX?

Actions

This Discussion