VPN between ASA5520 and Checkpoint r55

[adriatikb]

Hello all,

i hope that you will help me on this strange issue .

we are trying to configure the vpn with our provider we are on Asa and the use Checkpoint , vpn seem to be established on phase 1 and phase 2 too.

bur when i send ping packets seem to los on tunnel and other side do not see them.

Asa is after a onother firewall and outside interface of this asa is nated on this perimeter firewall

when we send ping i see that there are encapsulated but no packed back to be decapsulated.

is there any known issue to consider in my case.

regards

[david.tran]

we are trying to configure the vpn with our provider we are on Asa and they use Checkpoint , vpn seem to be established on phase 1 and phase 2 too.

If your provider still uses Checkpoint R55, you need to change provider immediately.  This is 2013, not 2003

Either that you made a typo, do you mean R75 and not R55?

[adriatikb]

no is not typo i mean R55.

it is predending that even this version will work with ASA.

any information is approciated.

regards

[david.tran]

R55 will work with ASA without any issues.  I have a R55 SPLAT in my lab working with Pix 8.0(4) code without any issues on site-2-site VPN. 

Please elaborate further on your issues.

[adriatikb]

hello,

phase 1 of VPN is established normaly and i see tunnel normaly as other tunnels when sh crypto isakmp Sa writen

als o phase 2 is established , encapsulation is in place but decapsulation has no count, it seems that packet is loss in tulen and is not delivered in other end. see below sh crypto ipsec sa comand output

please let me know what you else will need.

regards

access-list TOFORTINET-DMZ_3_cryptomap extended permit ip host 192.168.7.5 host X.X.x.x

      local ident (addr/mask/prot/port): (192.168.7.5/255.255.255.255/0/0)

      remote ident (addr/mask/prot/port): (x.x.x.x/255.255.255.255/0/0)

      current_peer: y.y.y.y

      #pkts encaps: 12, #pkts encrypt: 12, #pkts digest: 12

      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

      #pkts compressed: 0, #pkts decompressed: 0

      #pkts not compressed: 12, #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.: 192.168.2.1, remote crypto endpt.: x.x.x.x.

      path mtu 1500, ipsec overhead 58, media mtu 1500

      current outbound spi: 48DCB726

      current inbound spi : D418BB15

    inbound esp sas:

      spi: 0xD418BB15 (3558390549)

         transform: esp-3des esp-md5-hmac no compression

         in use settings ={L2L, Tunnel, PFS Group 2, }

         slot: 0, conn_id: 5906432, crypto-map: TOFORTINET-DMZ_map

         sa timing: remaining key lifetime (kB/sec): (4374000/28738)

         IV size: 8 bytes

         replay detection support: Y

         Anti replay bitmap:

          0x00000000 0x00000001

    outbound esp sas:

      spi: 0x48DCB726 (1222424358)

         transform: esp-3des esp-md5-hmac no compression

         in use settings ={L2L, Tunnel, PFS Group 2, }

         slot: 0, conn_id: 5906432, crypto-map: TOFORTINET-DMZ_map

         sa timing: remaining key lifetime (kB/sec): (4373999/28733)

         IV size: 8 bytes

         replay detection support: Y

         Anti replay bitmap:

[david.tran]

Ask the provider to run "tcpdump" on both the external and internal  of the R55 gateway.  If they see ESP traffics hitting the Checkpoint R55  external interface, it means that the ESP traffics make to the R55  gateway.  Check the tcpdump of the internal interface of the R55 gateway  to see if the traffic is going toward the target and come back to the  internal interface.

tcpdump is a wonderful tool for troubleshooting