Hi James,

thank you for your quick reply.

> This looks to be a enrcyption domain issue, which is common with Checkpoints. The only way to gaurentee the encryption domain behaviour is predictable then please read the Checkpoint "VPN-1 VPN Interoperablity" pdf and use the "subnet_for_range_and_peer" parameter in your user.def file. Match this up with your ACL on the cisco side.

I've already see this doc: _all_ subnet defined in Checkpoint VPN Domain are interesting for this tunnel, I don't have to define ranges.

Could be Cisco Router and Checkpoint VPN config details useful?

""subnet_for_range_and_peer" parameter in your user.def file"

- This is NOT necessarily in Checkpoint NGx.

- Instead "exchange key per subnets", use

"exchange key per hosts",

- Use "vpn debug ikeon" to findout what

going on. Use can use IKEView.exe to

view the debug. It will tell you EXACTLY

what goes wrong.

> Instead "exchange key per subnets", use

"exchange key per hosts",

I did that.

> Use "vpn debug ikeon" to findout what

going on. Use can use IKEView.exe to

view the debug. It will tell you EXACTLY

what goes wrong.

Ok, I attach debug in post (file called ike.elg)

VPN seems not-balanced: when I try to reach host behind Checkpoint from Cisco LAN ping is unsuccesful, but when I do the same thing from Checkpoint LAN to Cisco host, host in LAN B became reachable.

I cannot find useful information in IKE debug: is there any interesting info about the traffic?!

I looked at the ike.elg file and I am seeing this, assuming that 195.234.232.30 is the

Cisco VPN Peer:

1- The checkpoint sends encryption domain host 192.168.18.176 to encryption domain host 192.168.235.15,

2- The checkpoint receives encryption domain of host 192.168.235.15 to a encryption domain network of 192.168.19.0/24

3- The checkpoint receives encryption domain of host 192.168.235.15 to a encryption domain network of 192.168.18.0/24

4- The checkpoint receives encryption domain of host 192.168.235.15 to a encryption domain network of 10.0.1.0/24

5- Checkpoint sends encryption domain host 192.168.18.3 to encryption domain host 192.168.235.15,

6 - Checkpoint sends encryption domain host 192.168.18.8 to encryption domain host 192.168.235.15,

7- Checkpoint sends encryption domain host 192.168.18.8 to encryption domain host 192.168.235.15,

This is where you have the mis-match in the encryption domain.

> This is where you have the mis-match in the encryption domain.

Yep, you're right.

Follow ACL on Router Cisco:

ip access-list extended Checkpoint

permit ip host 192.168.235.15 192.168.19.0 0.0.0.255

permit ip host 192.168.235.15 10.0.1.0 0.0.0.255

permit ip host 192.168.235.15 172.16.100.0 0.0.0.255

permit ip host 192.168.235.15 172.30.10.0 0.0.0.255

permit ip host 192.168.235.15 172.20.20.0 0.0.0.255

permit ip host 192.168.235.15 192.168.18.0 0.0.0.255

Why 5-6-7 SAs are created 'by host'?

Are you sure you have the encryption domain

match on both sides? From the debug, I can

clearly that they are NOT.

Checkpoint VPN Domain include 6 subnet, but only 3 of these are listened in Security Tab.

We're updated cryptomap access-list on Cisco sides (now there are only these 3 subnets defined in CP 'Security Tab'), and actually all hosts became reachable.

Is this config up to you?

"but only 3 of these are listened in Security Tab."

that's just the access rules. Got

nothing with the Encryption domain.

The problem wit Checkpoint VPN is that

the encryption domain is not a flexible

as Cisco IOS devices. in Cisco IOS, the

encryption domain is defined as

"interesting" traffics and that you can

have different "interesting" traffics

ACL for different tunnels.

Not so in Checkpoint. it's a bit harder

to get it right in Checkpoint.

Anyway, your config looks good, unless

one of the 3 subnets on the CP side

decide to talk to your network behind

the routers which is not part of the

encryption domain and you will be in

trouble, again.