Hi,
We have a problem with an excisting L2L VPN connection.
The connection has to this day served only connections originating in one direction. Meaning only one end initiates the connections. This has worked normally so far. Now the third party behind the L2L VPN also wants to access some recourses trough the L2L VPN and because of that also initiates the connections.
This is where we face our problem.
For some reason the remote end cant bring up the L2L VPN where as we can (and the second party in our end ofcourse)
The connection was originally on a Cisco 6509 WS-SVC-IPSEC-1 module
For the tests in new equipment we moved the connection to a Cisco 7609 with SPA-IPSEC-2G module
The remote end uses Checkpoint FW1 R70 (or something like that. I'm not familiar with Checkpoints)
With both equipment the problem remains.
We did the tests today and i took some debug messages on our end with "debug crypto isakmp" and "debug crypto isakmp error" enabled. I also enable the "debug crypto condition peer ipv4 x.x.x.x" for the debugs as there are several other connections on the same device.
This is what the debug shows (Remote end IP replaced with x.x.x.x):
Jun 1 2011 07:20:58.062 UTC: ISAKMP: local port 500, remote port 500
Jun 1 2011 07:20:58.062 UTC: insert sa successfully sa = 207E7B00
Jun 1 2011 07:20:58.062 UTC: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Jun 1 2011 07:20:58.062 UTC: ISAKMP:(0):Old State = IKE_READY New State = IKE_R_MM1
Jun 1 2011 07:20:58.062 UTC: ISAKMP:(0): processing SA payload. message ID = 0
Jun 1 2011 07:20:58.062 UTC: ISAKMP:(0): processing vendor id payload
Jun 1 2011 07:20:58.062 UTC: ISAKMP:(0): vendor ID seems Unity/DPD but major 175 mismatch
Jun 1 2011 07:20:58.062 UTC: ISAKMP:(0):found peer pre-shared key matching x.x.x.x
Jun 1 2011 07:20:58.062 UTC: ISAKMP:(0): local preshared key found
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0): Authentication by xauth preshared
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0):Checking ISAKMP transform 1 against priority 1 policy
Jun 1 2011 07:20:58.066 UTC: ISAKMP: encryption 3DES-CBC
Jun 1 2011 07:20:58.066 UTC: ISAKMP: hash SHA
Jun 1 2011 07:20:58.066 UTC: ISAKMP: auth pre-share
Jun 1 2011 07:20:58.066 UTC: ISAKMP: default group 2
Jun 1 2011 07:20:58.066 UTC: ISAKMP: life type in seconds
Jun 1 2011 07:20:58.066 UTC: ISAKMP: life duration (VPI) of 0x0 0x0 0x70 0x80
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0):Encryption algorithm offered does not match policy!
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0):atts are not acceptable. Next payload is 0
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0):Checking ISAKMP transform 1 against priority 2 policy
Jun 1 2011 07:20:58.066 UTC: ISAKMP: encryption 3DES-CBC
Jun 1 2011 07:20:58.066 UTC: ISAKMP: hash SHA
Jun 1 2011 07:20:58.066 UTC: ISAKMP: auth pre-share
Jun 1 2011 07:20:58.066 UTC: ISAKMP: default group 2
Jun 1 2011 07:20:58.066 UTC: ISAKMP: life type in seconds
Jun 1 2011 07:20:58.066 UTC: ISAKMP: life duration (VPI) of 0x0 0x0 0x70 0x80
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0):atts are acceptable. Next payload is 0
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0): processing vendor id payload
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0): vendor ID seems Unity/DPD but major 175 mismatch
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM1
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_SA_SETUP
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Jun 1 2011 07:20:58.066 UTC: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM2
Jun 1 2011 07:20:58.082 UTC: ISAKMP (0): received packet from x.x.x.x dport 500 sport 500 Global (R) MM_SA_SETUP
Jun 1 2011 07:20:58.082 UTC: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Jun 1 2011 07:20:58.082 UTC: ISAKMP:(0):Old State = IKE_R_MM2 New State = IKE_R_MM3
Jun 1 2011 07:20:58.082 UTC: ISAKMP:(0): processing KE payload. message ID = 0
Jun 1 2011 07:20:58.082 UTC: ISAKMP:(0): processing NONCE payload. message ID = 0
Jun 1 2011 07:20:58.082 UTC: ISAKMP:(0):found peer pre-shared key matching x.x.x.x
Jun 1 2011 07:20:58.082 UTC: ISAKMP:(78418):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Jun 1 2011 07:20:58.082 UTC: ISAKMP:(78418):Old State = IKE_R_MM3 New State = IKE_R_MM3
Jun 1 2011 07:20:58.086 UTC: ISAKMP:(78418): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_KEY_EXCH
Jun 1 2011 07:20:58.086 UTC: ISAKMP:(78418):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Jun 1 2011 07:20:58.086 UTC: ISAKMP:(78418):Old State = IKE_R_MM3 New State = IKE_R_MM4
Jun 1 2011 07:20:58.102 UTC: ISAKMP (78418): received packet from x.x.x.x dport 500 sport 500 Global (R) MM_KEY_EXCH
Jun 1 2011 07:20:58.102 UTC: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from x.x.x.x failed its sanity check or is malformed
Jun 1 2011 07:20:58.102 UTC: ISAKMP (0:78418): incrementing error counter on sa, attempt 1 of 5: PAYLOAD_MALFORMED
Jun 1 2011 07:20:58.102 UTC: ISAKMP:(78418): sending packet to x.x.x.x my_port 500 peer_port 500 (R) MM_KEY_EXCH
Jun 1 2011 07:20:58.102 UTC: ISAKMP (0:78418): incrementing error counter on sa, attempt 2 of 5: reset_retransmission
Jun 1 2011 07:20:59.118 UTC: ISAKMP:(78418): retransmitting phase 1 MM_KEY_EXCH...
Jun 1 2011 07:20:59.118 UTC: ISAKMP (0:78418): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
Jun 1 2011 07:20:59.118 UTC: ISAKMP:(78418): no outgoing phase 1 packet to retransmit. MM_KEY_EXCH
Jun 1 2011 07:20:59.118 UTC: ISAKMP:(78418):peer does not do paranoid keepalives.
Jun 1 2011 07:20:59.118 UTC: ISAKMP:(78418):deleting SA reason "Death by retransmission P1" state (R) MM_KEY_EXCH (peer x.x.x.x)
Jun 1 2011 07:20:59.118 UTC: ISAKMP:(78418):deleting SA reason "Death by retransmission P1" state (R) MM_KEY_EXCH (peer x.x.x.x)
Jun 1 2011 07:20:59.118 UTC: ISAKMP:(78418):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
Jun 1 2011 07:20:59.118 UTC: ISAKMP:(78418):Old State = IKE_R_MM4 New State = IKE_DEST_SA
To my eye it seems that the attributes/parameters for Phase 1 are ok on both ends (have to be since the connection forms normally when the traffic is initiated from our side) but somewhere along the way the negotiations stop because our end gets a malformed packet during the negotiations? Does this mean the remote end is somehow faulty? Is there some compatibility problem with the VPN devices in question? or its the sign of some known problem with VPN connections?
So far I have not found any explanation to what is causing this.
Any help would be greatly appriciated. If you need any additional information, please ask.
- Jouni
