1. Home
  2. Cisco Systems
  3. Ipsec VPN between Cisco IOS and Zywall

Ipsec VPN between Cisco IOS and Zywall

I'll try to establish a S2S-VPN between a Cisco IOS and a ZyWall While debuging they are negotiating but then I got a "Main mode failed error"

Anybody some idea or suggestions ?

tom dot lauwereins add ardatis dot com

Jun 29 11:56:28: ISAKMP (0:0): received packet from x.y.252.33 (N) NEW SA Jun 29 11:56:28: ISAKMP: local port 500, remote port 500 Jun 29 11:56:28: ISAKMP (0:108): processing SA payload. message ID = 0 Jun 29 11:56:28: ISAKMP (0:108): found peer pre-shared key matching

81.241.252.33 Jun 29 11:56:28: ISAKMP (0:108): Checking ISAKMP transform 1 against priority 10 policy Jun 29 11:56:28: ISAKMP: encryption 3DES-CBC Jun 29 11:56:28: ISAKMP: hash MD5 Jun 29 11:56:28: ISAKMP: auth pre-share Jun 29 11:56:28: ISAKMP: default group 2 Jun 29 11:56:28: ISAKMP: life type in seconds Jun 29 11:56:28: ISAKMP: life duration (VPI) of 0x0 0x0 0x1C 0x20 Jun 29 11:56:28: ISAKMP (0:108): Encryption algorithm offered does not match policy! Jun 29 11:56:28: ISAKMP (0:108): atts are not acceptable. Next payload is 0 Jun 29 11:56:28: ISAKMP (0:108): Checking ISAKMP transform 1 against priority 20 policy Jun 29 11:56:28: ISAKMP: encryption 3DES-CBC Jun 29 11:56:28: ISAKMP: hash MD5 Jun 29 11:56:28: ISAKMP: auth pre-share Jun 29 11:56:28: ISAKMP: default group 2 Jun 29 11:56:28: ISAKMP: life type in seconds Jun 29 11:56:28: ISAKMP: life duration (VPI) of 0x0 0x0 0x1C 0x20 Jun 29 11:56:28: ISAKMP (0:108): Diffie-Hellman group offered does not match policy! Jun 29 11:56:28: ISAKMP (0:108): atts are not acceptable. Next payload is 0 Jun 29 11:56:28: ISAKMP (0:108): Checking ISAKMP transform 1 against priority 25 policy Jun 29 11:56:28: ISAKMP: encryption 3DES-CBC Jun 29 11:56:28: ISAKMP: hash MD5 Jun 29 11:56:28: ISAKMP: auth pre-share Jun 29 11:56:28: ISAKMP: default group 2 Jun 29 11:56:28: ISAKMP: life type in seconds Jun 29 11:56:28: ISAKMP: life duration (VPI) of 0x0 0x0 0x1C 0x20 Jun 29 11:56:28: ISAKMP (0:108): atts are acceptable. Next payload is 0 Jun 29 11:56:29: ISAKMP (0:108): processing vendor id payload Jun 29 11:56:29: ISAKMP (0:108): processing vendor id payload Jun 29 11:56:29: ISAKMP (0:108): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR Jun 29 11:56:29: ISAKMP (0:108): sending packet to x.y.252.33 (R) MM_SA_SETUP Jun 29 11:56:31: ISAKMP (0:108): received packet from x.y.252.33 (R) MM_SA_SETUP Jun 29 11:56:31: ISAKMP (0:108): processing KE payload. message ID = 0 Jun 29 11:56:31: ISAKMP (0:108): processing NONCE payload. message ID = 0 Jun 29 11:56:31: ISAKMP (0:108): found peer pre-shared key matching 81.241.252.33 Jun 29 11:56:31: ISAKMP (0:108): SKEYID state generated Jun 29 11:56:31: ISAKMP:received payload type 0 Jun 29 11:56:31: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Main mode failed with peer at x.y.252.33 Jun 29 11:56:31: ISAKMP (0:108): incrementing error counter on sa: reset_retransmission Jun 29 11:56:32: ISAKMP (0:108): retransmitting phase 1 MM_SA_SETUP... Jun 29 11:56:32: ISAKMP (0:108): incrementing error counter on sa: retransmit phase 1 Jun 29 11:56:32: ISAKMP (0:108): retransmitting phase 1 MM_SA_SETUP Jun 29 11:56:32: ISAKMP (0:108): sending packet to x.y.252.33 (R) MM_SA_SETUP Jun 29 11:56:35: ISAKMP (0:108): received packet from x.y.252.33 (R) MM_SA_SETUP Jun 29 11:56:35: ISAKMP (0:108): processing KE payload. message ID = 0
Reply to
Tom Pouce
Loading thread data ...

In article , Tom Pouce wrote: :I'll try to establish a S2S-VPN between a Cisco IOS and a ZyWall

:Jun 29 11:56:31: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Main mode failed with peer at x.y.252.33

According to

formatting link
that message "suggests" that the phase 1 policies do not match between the two ends.

In my experience, a policy mismatch can happen if the policies are in a different order between the two machines. Each side chooses the first policy offered by the other that is acceptable to the local side. If there are two policies which are acceptable to both, but the order is different between them, then the two might choose different policies.

Reply to
Walter Roberson

Hi Walter,

could what you told cause one direction tunnels? For all of this NG users I'm talking about thread named "PIX VPNs timeouts" posted on June 21st.

Thanks,

Alex.

Reply to
AM

In article , AM wrote: :> In my experience, a policy mismatch can happen if the policies are in :> a different order between the two machines.

:could what you told cause one direction tunnels? :For all of this NG users I'm talking about thread named "PIX VPNs timeouts" posted on June 21st.

Hmmm, I'm not sure, but I don't think so -- I don't think the devices will attempt to negotiate Phase 2 until they have agreed on Phase 1.

I would tend to suspect the unidirectional tunnel problem you are encountering is a problem with routing or filtering, but the debugs and log messages would be needed to get further on that.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.