PDA

View Full Version : Checkpoint behind Cisco ASA..issue?



opers13
2014-07-04, 18:33
823823I just deployed a 2200 gateway at a remote office, I only have control of the gateway, the infrastructure is handled by another group. The 2200 has a public IP assigned to the external interface and it's on the DMZ behind a Cisco ASA. TCP 500, 443, CPMI and ESP 50 are open on the ASA.

Here's the issue, initially I had the VPN tunnel between the 2200 and a Cisco ASA, tunnel comes up(phase1 & 2) no issues there. However, I can't reach anything on the other side and vice versa. I worked with Checkpoint TAC, tracker showing packets being encrypted, rule was getting hits. TCPDUMP was showing traffic hitting the inside interface and being encrypted.
We also determined that packets were not being dropped. TCPDUMP on the 2200 was empty nothing coming up at all.

So I decided to terminate the tunnel on a 4600 cluster instead of the ASA. To my surprise I was having the same exact issue...called TAC again and pretty much ran through the same steps and we were seeing traffic hitting the inside interface getting encrypted but nothing on the other side and vice versa.

Then I decided to use another 4600 cluster on another datacenter and same issue. Is it possible that the ASA in front of the 2200 at the remote location be causing the issue? Both TAC engineers I worked with said that's most likely the issue. Now I was under the impression that all the ASA would "see" is an IPSec tunnel and nothing else since it's an end to end connection between the gateways.

I'm not sure what else do to..any input is appreciated. Thanks

ShadowPeak.com
2014-07-04, 23:35
823823I just deployed a 2200 gateway at a remote office, I only have control of the gateway, the infrastructure is handled by another group. The 2200 has a public IP assigned to the external interface and it's on the DMZ behind a Cisco ASA. TCP 500, 443, CPMI and ESP 50 are open on the ASA.

Here's the issue, initially I had the VPN tunnel between the 2200 and a Cisco ASA, tunnel comes up(phase1 & 2) no issues there. However, I can't reach anything on the other side and vice versa. I worked with Checkpoint TAC, tracker showing packets being encrypted, rule was getting hits. TCPDUMP was showing traffic hitting the inside interface and being encrypted.
We also determined that packets were not being dropped. TCPDUMP on the 2200 was empty nothing coming up at all.

So I decided to terminate the tunnel on a 4600 cluster instead of the ASA. To my surprise I was having the same exact issue...called TAC again and pretty much ran through the same steps and we were seeing traffic hitting the inside interface getting encrypted but nothing on the other side and vice versa.

Then I decided to use another 4600 cluster on another datacenter and same issue. Is it possible that the ASA in front of the 2200 at the remote location be causing the issue? Both TAC engineers I worked with said that's most likely the issue. Now I was under the impression that all the ASA would "see" is an IPSec tunnel and nothing else since it's an end to end connection between the gateways.

I'm not sure what else do to..any input is appreciated. Thanks

First off make sure the Cisco is allowing UDP 500 (not TCP 500 as you stated) but if you are clearing Phase 1 and Phase 2 I doubt that is an issue.

Sounds like IKE traffic is passing just fine but you are hitting the wall with IPSEC traffic. Try permitting UDP 4500 and UDP 2746 on the Cisco to the 2200 Check Point to permit NAT traversal to work, even though it sounds like you shouldn't need it but there may be NAT present somewhere else. If you can decode IKE packets 3 and 4 you will be able to see the two endpoints attempting to determine if NAT is present between them.

This may be insultingly rudimentary but also make sure that the actual ESP protocol number 50 is being allowed on the Cisco, not tcp/udp port 50.

Are there any VPNs configured on the ASA? Does the 2200 have his own real public address or is it using the outside address of the ASA with the needed ports being forwarded in to the 2200? That situation could cause the ASA to eat the ESP Traffic and it should log something like "IPSEC packet has invalid spi" to indicate that is occurring.

cciesec2006
2014-07-05, 07:25
First off make sure the Cisco is allowing UDP 500 (not TCP 500 as you stated) but if you are clearing Phase 1 and Phase 2 I doubt that is an issue.

Sounds like IKE traffic is passing just fine but you are hitting the wall with IPSEC traffic. Try permitting UDP 4500 and UDP 2746 on the Cisco to the 2200 Check Point to permit NAT traversal to work, even though it sounds like you shouldn't need it but there may be NAT present somewhere else. If you can decode IKE packets 3 and 4 you will be able to see the two endpoints attempting to determine if NAT is present between them.

This may be insultingly rudimentary but also make sure that the actual ESP protocol number 50 is being allowed on the Cisco, not tcp/udp port 50.

Are there any VPNs configured on the ASA? Does the 2200 have his own real public address or is it using the outside address of the ASA with the needed ports being forwarded in to the 2200? That situation could cause the ASA to eat the ESP Traffic and it should log something like "IPSEC packet has invalid spi" to indicate that is occurring.

I am going to assume the followings:
- The 2200 is getting public IP address and NOT private address so that ASA is NOT doing any NAT translation. More often than not,
the ASA is doing some static/dynamic NAT without you knowing it. NAT on the ASA is very tricky because of the stupid security level.
NAT may not happen on the DMZ where your 2200 is residing but it may happen between internal/external, internal/dmz, etc...
The minute you use "static" or "nat" command on the ASA, the "no nat-control" becomes useless.

- on both the DMZ/external of the ASA ACL, do this:

permit external ip external_VPN_host_IP_address host 2200_IP_address log
permit dmz ip 2200_IP_address external_VPN_host_IP_address

These ACLs will allow external VPN host and the 2200 to communicate on ALL protocols. This will rule out if the ASA on your side is blocking IPSec protocols.

Another possibility is that the remote ASA that the 2200 is doing IPSec with is not allowing IPSec to traverse the VPN tunnel. Askthe other guys to perform "sysopt connection permit-vpn" on his end and see if it works.

ShadowPeak.com
2014-07-14, 11:22
Any updates opers13? You've received some pretty good advice...