cancel
Showing results for 
Search instead for 
Did you mean: 
Post a Question

Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

There is VPN site-to-site with Cisco ASA in Meshed community. Only two gateways paticipating.
We use Checkpoint R77.30, other side uses Cisco ASA.
VPN Domain includes several networks at both sides.

Two newly added networks doesnt works: I can see packets from our networks being successfully encripted, but no return traffic followed. As partner assured me, that he also added network from his side, I suggested that Checkpoint summarize networks and there is a problem with ipsec sa.

I tried to find out how Checkpoint creates ipsec sa via "fw tab" command, but found nothing.

(Looking ahead, partner just forgot add this new networks in Cisco ASA config)))))

At last I fount the discussion of similar problem, there were recommended to change "VPN Tunnel Sharing" option in "Tunnel Management" from "One tunnel per subnet pair" to "One tunnel per each pair of hosts"
This doesn't help and I returned option to "One tunnel per subnet pair".

From that point strange behavior started: some our hosts cannot get access to partner hosts, next time this hosts got access, but other lost it. This doesn't depend on network.
Finally I filtered SmartView tracker by Action = Key Install and Source = VPN Comunity Name and found that there were records:

IKE: Quick Mode completion [UDP (IPv4)].
IKE IDs: subnet: 10.1.0.0 (mask= 255.255.0.0) and subnet: 192.168.0.0 (mask= 255.255.255.0)

IKE: Quick Mode completion [UDP (IPv4)].
IKE IDs: host: 10.1.2.30 and host: 192.168.0.4

That is, there were SA for networks and SA for host inside this networks at the same time.

From Cisco ASA it looks the same:

sh crypto ipsec sa peer X.X.X.X

Crypto map tag: outside_map, seq num: 1160, local addr: Y.Y.Y.Y

access-list VPN extended permit ip 192.168.0.0 255.255.255.0 10.1.0.0 255.255.0.0 
local ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
current_peer: X.X.X.X

access-list VPN extended permit ip 192.168.0.0 255.255.255.0 10.1.0.0 255.255.0.0 
local ident (addr/mask/prot/port): (192.168.0.4/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (10.1.2.30/255.255.255.255/0/0)
current_peer: X.X.X.X

Problem solved after resetting tunnel from Cisco ASA side.


The question is:

1. What exactly do "VPN Tunnel Sharing" option for non Checkpoint peers? Administration Guide says that this options works only in Checkpoint environment.

2. How can I check networks within SA? Is there any cli command similar to Cisco "sh crypto ipsec sa"?

11 Replies

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

There is sk108600 VPN Site-to-Site with 3rd party  that may help...

0 Kudos

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

Hi,

1) The tunel sharing options is not specific to Check Point gateways. It might have an other name with other vendor (Proxy ID in PAN gateways). Depending the choosen option, the gateways will create a couple of SA

  • for each pair of host,
  • per subnet pair (usually the common configuration),
  • or per gateway pair.

2) Usually, I use these commands for IPSEC debuging with Check Point :

  • listing et reseting tunnels : vpn tu (sk33853)
  • debugging phase 1 and 2 :
    • activating ike debug : vpn debug ikeon
    • Opening logs ($FWDIR/log/ike.elg or $FWDIR/log/ikev2.xml) with IKEVIEW to analyse ike messages (see sk30994

Regards,

Benoit

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

Thank you, I should try debug ike and IKEVIEW utility, as vpn tu shows only the number or SA, without any details.

0 Kudos

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

Hi,

I had similar problem like you, and for me setting tunnel sharing 'per host' fixed it. When you set it like that give Cisco device some time to adjust to it. What I notice is that VPN tunnel between Cisco and CheckPoint takes more time to establish, unlike between two CheckPoint's where it is nearly instant.

0 Kudos

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

Thanks for reply,

in my case devices have enough time to establish VPN tunnels (few hours between config changes). Maybe settings on Cisco ASA affected.

0 Kudos

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

This problem continued:

I added networks to VPN (10.202.0.0/16 and 10.203.0.0/16). After that access from networks 10.200.0.0/16 and 10.201.0.0/16 to remote host (via VPN) disappeared. I can see that it disappeared right after installation of policy with new networks (I check it with Management logs in SmartView Tracker). At the same time other networks continued to have access to remote host 

As I understand the reason is subnetting. Checkpoint join /16 networks to one /14 and there is negitoation problem with Cisco ASA.

There is useful sk101219

New VPN features in R77.20 and later 

It says that settings of subnetting stored in database parameters:

ike_use_largest_possible_subnets

ike_enable_supernet

but I cannot see it using commands fw ctl get int ike_use_largest_possible_subnets and fw ctl get int ike_enable_supernet, like it described in sk101219.

The question is:

1. Am I right that default Checkpoint R77.30 behaviour is to joint networks together when possible?

2. Is that normal that there is no supernetting parameters in database and how can I change them? 

 

0 Kudos

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

Please also consult VPN Site-to-Site with 3rd party ! 1. Yes, this is the default behaviour. 2. Did you use GuiDBedit for setting the parameters?

0 Kudos

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

Thank you, I found subnetting parameters in GuiDBedit.

Disabling subnetting for non-Checkpoint devices is described in New VPN features in R77.20 and later

It says: 

When

ike_use_largest_possible_subnets - true/false + 

ike_enable_supernet - false (default on new installations):

"supernetting" is disabled ONLY for 3rd party VPN devices (according to "third_party_devices" table)

Where is third_party_devices table? I cannot find it in GuiDBedit.

0 Kudos

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

You do not need it - only change the parameters, that will also change the behaviour.

0 Kudos

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

Thank you, your suggestion helped solve the problem, I change ike_enable_supernet  to false, leave ike_use_largest_possible_subnets to true, and there are no more joined networks in SA.

This settings have interesting subsequence:

There were small /24 network in VPN Domain (for example 10.219.90.0/24) Larger network was needed (10.219.0.0/16)

I just added /16 network to VPN Domain and forgot delete /24 network.

It worked well, I suppose Checkpoint joined networks and have only /16 network in VPN Domain

After disabling ike_enable_supernet two different SA appears - for /24 and for /16 networks and this cause problems with access.

I remove /24 network, leave only /16, reload VPN tunnel, but two SA still exist and come from Cisco ASA, although there is only /16 network on Cisco ASA too.

I can see Key Install entries in SmartView Tracker:

IKE: Quick Mode completion [UDP (IPv4)].
IKE IDs: subnet: 10.219.90.0 (mask= 255.255.255.0) and subnet: yy.yy.yy.yy (mask= 255.255.255.0)

IKE: Informational Exchange Received Delete IPSEC-SA from Peer: xx.xx.xx.xx
SPIs: 9fbb721f

where yy.yy.yy.yy - network behind Checkpoint, xx.xx.xx.xx - Cisco ASA peer

I suppose VPN tunnel should be reseted on Cisco ASA too.

Why some SA comes from Checkpoint and another from Cisco ASA? Does that depends on IPsec timers?

Cross-platform VPN requires a lot of skill and luck )))

0 Kudos

Re: Strange issue Checkpoint R77.30 site-to-site VPN with Cisco ASA

About question 1. This is exactly the problem here. CheckPoint combines networks in a supernet that becomes the "new " VPN domain that is then advertised to the other gateway. Cisco does not like that, it expects an EXACT match proposal to what is configured. The way to overcome this is to set tunnel sharing "per host" as discussed. This means more tunnels will be opened (instead of one per supernet, one per host) and may affect performance on both sides when a lot of subnets participate in the VPN domain. 

Per host is btw the more secure way to do it.