PIX to Endian VPN Tunnel

Unanswered Question

I have a L2L VPN tunnel setup to a supplier running an Endian FW, it is very basic, on our side we have a Cisco PIX 515E running

Cisco PIX Security Appliance Software Version 8.0(4) 
Device Manager Version 6.1(5)5

The tunnel works, however it only stays up for one minute or so, then drops and the tunnel is re established, here is the tunnel config from the Cisco PIX:

crypto ipsec transform-set cl-vpn esp-aes-256 esp-sha-hmac 
crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac 
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac 
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac 
crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac 
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac 
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac 
crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac 
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac 
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac 
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map dynamic1 10 set transform-set cl-vpn
crypto dynamic-map dynamic1 10 set security-association lifetime seconds 28800
crypto dynamic-map dynamic1 10 set security-association lifetime kilobytes 4608000
crypto map ky-map 30 set security-association lifetime seconds 28800
crypto map ky-map 30 set security-association lifetime kilobytes 4608000

<--This is the tunnel to the endian FW-->
crypto map ky-2xt1 1 match address outside-2xt1_1_cryptomap
crypto map ky-2xt1 1 set pfs 
crypto map ky-2xt1 1 set peer 72.240.12.145
crypto map ky-2xt1 1 set transform-set ESP-3DES-SHA
crypto map ky-2xt1 1 set security-association lifetime seconds 28800
crypto map ky-2xt1 1 set security-association lifetime kilobytes 4608000

crypto map ky-2xt1 30 ipsec-isakmp dynamic dynamic1
crypto map ky-2xt1 interface outside-2xt1
crypto isakmp identity address 
crypto isakmp enable outside-2xt1

crypto isakmp policy 20
authentication pre-share
encryption aes-256

hash sha
group 2
lifetime 86400

crypto isakmp policy 40
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400

Here is the ACL for the crypto map:

access-list outside-2xt1_1_cryptomap extended permit ip 137.168.234.0 255.255.255.0 172.16.1.0 255.255.255.0

Here is the output from the debug when the traffic drops and the tunnel is re established:

PIX(config)# Aug 05 16:42:46 [IKEv1]: IP = 72.240.12.145, IKE Initiator: New Phase 1, Intf inside, IKE Peer 72.240.12.145  local Proxy Address 137.168.234.0, remote Proxy Address 172.16.1.0,  Crypto map (ky-2xt1)

Aug 05 16:42:46 [IKEv1]: IP = 72.240.12.145, Connection landed on tunnel_group 72.240.12.145

Aug 05 16:42:47 [IKEv1]: IP = 72.240.12.145, Connection landed on tunnel_group 72.240.12.145

Aug 05 16:42:47 [IKEv1]: Group = 72.240.12.145, IP = 72.240.12.145, Freeing previously allocated memory for authorization-dn-attributes

Aug 05 16:42:47 [IKEv1]: Group = 72.240.12.145, IP = 72.240.12.145, PHASE 1 COMPLETED

Aug 05 16:42:47 [IKEv1]: Group = 72.240.12.145, IP = 72.240.12.145, Security negotiation complete for LAN-to-LAN Group (72.240.12.145)  Initiator, Inbound SPI = 0xa19e76b3, Outbound SPI = 0x17c25306

Aug 05 16:42:47 [IKEv1]: Group = 72.240.12.145, IP = 72.240.12.145, PHASE 2 COMPLETED (msgid=ca7d058e)

IX(config)# sh Aug 05 16:43:21 [IKEv1]: Group = 72.240.12.145, IP = 72.240.12.145, All IPSec SA proposals found unacceptable!

Aug 05 16:43:21 [IKEv1]: Group = 72.240.12.145, IP = 72.240.12.145, QM FSM error (P2 struct &0x47aa0b0, mess id 0xab166508)!

From the specific peer tunnel:

PIX(config)# sh cry ipsec sa peer 72.240.12.124  45
peer address: 72.240.12.145
    Crypto map tag: ky-2xt1, seq num: 1, local addr: 12.16.22.66

      access-list outside-2xt1_1_cryptomap permit ip 137.168.234.0 255.255.255.0 172.16.1.0 255.255.255.0 
      local ident (addr/mask/prot/port): (137.168.234.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (172.16.1.0/255.255.255.0/0/0)
      current_peer: 72.240.12.145

      #pkts encaps: 3, #pkts encrypt: 3, #pkts digest: 3
      #pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 3, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 12.16.22.66  , remote crypto endpt.: 72.240.12.145

      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: 17C25318

    inbound esp sas:
      spi: 0x2FDF4A65 (803162725)
         transform: esp-3des esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 2, }
                    slot: 0, conn_id: 5840896, crypto-map: ky-2xt1
         sa timing: remaining key lifetime (kB/sec): (3914999/28792)
         IV size: 8 bytes
         replay detection support: Y
Anti replay bitmap: 
        0x00000000 0x0000001F
    outbound esp sas:
      spi: 0x17C25318 (398611224)
         transform: esp-3des esp-sha-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 5840896, crypto-map: ky-2xt1
         sa timing: remaining key lifetime (kB/sec): (3914999/28792)
         IV size: 8 bytes
         replay detection support: Y
Anti replay bitmap: 
        0x00000000 0x00000001

Like I said, the tunnel works fine for a minute or so, if you run a constant ping, it will send between 50-60 packets, then drop 2, and pick right up again, it's fine for icmp, but its hell on other protocols.

Any help would be appreciated.

Thanks,

Tim

[email protected]

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jason Gervia Fri, 08/06/2010 - 06:00

Tim,


The VPN configuration looks correct - I would check the following things:

1)  make sure the other side doesn't have any 'health monitoring' for our tunnel, that has caused issues in the past

2)  Make sure the other side is encrypting the same traffic (and not restricting ports/protocols) as that has caused issues in the past.

After that, I would get a 'debug crypto ipsec 255' from when the issue occurs (you're getting a 'no proposal chosen' - but we don't know what they're proposing'.  This may generate quite a bit of output, so be prepared to capture it.

--Jason

Actions

This Discussion