Cisco RTR <-> PIX L2L issue, what I'm I missing?

Unanswered Question
Oct 10th, 2008

I've upgraded our 6.3(5) pix to 7.2 and lost one VPN to our branch office.

They have a 2600 IOS router. And I cant find the issue and need some help please.

2600 config:

Protection suite of priority 20

encryption algorithm: Three key triple DES

hash algorithm: Secure Hash Standard

authentication method: Pre-Shared Key

Diffie-Hellman group: #2 (1024 bit)

lifetime: 86400 seconds, no volume limit

crypto isakmp key xxxx address 6x.x.x.x no-xauth

crypto ipsec transform-set TRSET esp-3des esp-sha-hmac

crypto map MAP 30 ipsec-isakmp

set peer 6x.x.x.x

set transform-set TRSET

match address VPN

Cisco PIX 7.2 config

crypto map outside_map 80 match address outside_cryptomap_80

crypto map outside_map 80 set peer 1x.x.x.x

crypto map outside_map 80 set transform-set ESP-3DES-SHA

crypto isakmp policy 50

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

tunnel-group 1x.x.x.x type ipsec-l2l

tunnel-group 1x.x.x.x ipsec-attributes

pre-shared-key *

The 2600 has another VPN l2l connection running towards another 6.3(5) pix that I havent upgraded, and that one works great...

Error logs from the 2600

ISAKMP (0:11): Encryption algorithm offered does not match policy!

ISAKMP (0:11): atts are not acceptable. Next payload is 3

ISAKMP (0:11): Hash algorithm offered does not match policy!

ISAKMP (0:11): atts are not acceptable. Next payload is 3

Can I ignore the isakmp keepalives settings meanwhiles since its complaining about mismatchning encryption settings.

Any hints would be very appreciated

Thank you

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.5 (2 ratings)
Loading.
ajagadee Fri, 10/10/2008 - 09:34

Hi,

Make sure that the transform sets are matching on both the sides.

crypto map outside_map 80 set transform-set ESP-3DES-SHA

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

If the above is already configured correctly on the ASA, can you post ISAKMP and IPSEC Debugs from both the ASA and Router.

Regards,

Arul

** Please rate all helpful posts **

singhsaju Fri, 10/10/2008 - 11:58

From the above debugs it seems that it is not passing Phase 1.

Can you define following isakmp policy on PIX and router with hash as md5 and then check?

crypto isakmp policy 60

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

azore2007 Sat, 10/11/2008 - 01:19

Hi, thanks for the help

I've added your policy but still got the errors in the cisco 2600

ISAKMP (0:12): Encryption algorithm offered does not match policy!

ISAKMP (0:12): atts are not acceptable. Next payload is 3

ISAKMP (0:12): Hash algorithm offered does not match policy!

ISAKMP (0:12): atts are not acceptable. Next payload is 3

The tunnels comes up and traffic goes both ways... (see both TX/RX counters adding packets)

Debugging from the pix

[IKEv1]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, PHASE 1 COMPLETED

[IKEv1]: IP = 1xx.xx.xxx.x, Keep-alive type for this connection: DPD

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Starting P1 rekey timer: 82080 seconds.

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, IKE got SPI from key engine: SPI = 0x873794ba

[IKEv1]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Responder forcing change of IPSec rekeying duration from 28800 to 3600 seconds

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, loading all IPSEC SAs

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Generating Quick Mode Key!

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Generating Quick Mode Key!

[IKEv1]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Security negotiation complete for LAN-to-LAN Group (1xx.xx.xxx.x) Initiator, Inbound SPI = 0x873794ba, Outbound SPI =

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, oakley constructing final quick mode

[IKEv1 DECODE]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, IKE Initiator sending 3rd QM pkt: msg id = 7e299a99

[IKEv1]: IP = 1xx.xx.xxx.x, IKE_DECODE SENDING Message (msgid=7e299a99) with payloads : HDR + HASH (8) + NONE (0) total length : 76

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, IKE got a KEY_ADD msg for SA: SPI = 0xbb1da897

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Pitcher: received KEY_UPDATE, spi 0x873794ba

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Starting P2 rekey timer: 3060 seconds.

[IKEv1]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, PHASE 2 COMPLETED (msgid=7e299a99)

So that looks good..

[IKEv1]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Connection terminated for peer 1xx.xx.xxx.x. Reason: Peer Terminate Remote Proxy N/A, Local Proxy N/A

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, sending delete/delete with reason message

[IKEv1]: IP = 1xx.xx.xxx.x, IKE_DECODE SENDING Message (msgid=36413cd) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 68

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Active unit receives a delete event for remote peer 1xx.xx.xxx.x.

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, sending delete/delete with reason message

[IKEv1]: IP = 1xx.xx.xxx.x, IKE_DECODE SENDING Message (msgid=3f8c4579) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 68

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, Active unit receives a delete event for remote peer 1xx.xx.xxx.x.

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, IKE Deleting SA: Remote Proxy 1xx.xx.xxx.x, Local Proxy 6x.x.x.x

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, IKE Deleting SA: Remote Proxy 1xx.xx.xxx.x, Local Proxy 6x.x.x.x

[IKEv1 DEBUG]: Group = 1xx.xx.xxx.x, IP = 1xx.xx.xxx.x, IKE SA MM:5b905e64 terminating: flags 0x0120c822, refcnt 0, tuncnt 0

I see TX/RX counter tick upwards on the PIX, but the tunnel goes up and down really fast

Only error I can find when debugging in the pix is this

Oct 11 11:11:39 [IKEv1]: Group = 1xx.xxx.x.x, IP = 1x.x.x.x, Could not find centry for IPSec SA delete with reason message

And the 2600 keeps giving errors

ISAKMP (0:42): Encryption algorithm offered does not match policy!

ISAKMP (0:42): atts are not acceptable. Next payload is 3

ISAKMP (0:42): Hash algorithm offered does not match policy!

ISAKMP (0:42): atts are not acceptable. Next payload is 3

azore2007 Mon, 10/13/2008 - 02:53

My VPN tunnels seems to have switched isakmp policies with each other :)

The "working" l2TP towards my pix 6.3 used

3des sha, now its using 3des md5

The non-working L2tp is now using 3des sha and has been up for 1d 13h..

Both seems to have gone up/down until they reach con-id 365/366...

Should i worry about that? Last error msg in the 2600 is frm about 20 hours ago

errors like these:

ISAKMP (0:42): Encryption algorithm offered does not match policy!

ISAKMP (0:42): atts are not acceptable. Next payload is 3

ISAKMP (0:42): Hash algorithm offered does not match policy!

ISAKMP (0:42): atts are not acceptable. Next payload is 3

Thanks for the advice/help

Appreciate it

Actions

This Discussion