10-03-2007 04:02 PM - edited 03-09-2019 06:57 PM
I am setting up 4 tunnels between my ASA and 4 Checkpoint remote sites. They just need access to 2 hosts. They will only accept public ip addresses so I am trying to nat the internal hosts to public addresses and force down the tunnel. When my site initiates the tunnel everything works fine (I see encryption/decryption) but when they initiate the tunnel, traffic only comes from them (I only see decryption but never see encryption). If anyone has any ideas I would be grateful. Below is the config example. I do not believe it is the external ACL because I tried the connection with the sysopt connection permit-vpn and still no dice. I ran debugs (debug crytpo ipsec 127 and debug crypto isakmp 127) but I did not seeing anything out of the ordinary. Attached is example of part of the config.
10-07-2007 09:35 PM
I would reenable the sysopt and remove the ACL entry for the VPN traffic. When the remote site Checkpoint initiates the tunnel grab the output from 'show vpn-sessiondb detail l2l' and post it if you can.
Also, I would confirm how the remote site Checkpoints' interesting traffic configuration is setup. I've seen similiar problems with ASA/PIX to Watch Guards and in almost all cases it was how the Watch Guards were setup. The Watch Guard interesting traffic was defined as "host x.x.x.x to entire subnet" while the ASA was configured for host y.y.y.y host x.x.x.x" The tunnel would build fine from ASA to Watch Guard and pings would work but not the other way around.
10-08-2007 05:18 AM
I appreciate your response. I was able to troubleshoot this problem further on Friday and have found that when the checkpoint initiates the tunnel the wrong crypto map is being applied (Dynamic map for RA). I am trying to figure out the Checkpoint to ASA tunnel is not matching. If I initiate the tunnel the correct map is being applied. I would greatly appreciate any suggestions on finding the mismatch. I will definitely take a look at the interesting traffic.
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, checking map = insidemap, seq = 10...
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, map = insidemap, seq = 10, ACL does not match proxy IDs src:205.XX.ZZ.183 dst:64.XX.XX.246
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, checking map = insidemap, seq = 20...
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, map = insidemap, seq = 20, ACL does not match proxy IDs src:205.XX.ZZ.183 dst:64.XX.XX.246
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, checking map = insidemap, seq = 21...
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, map = insidemap, seq = 21, ACL does not match proxy IDs src:205.XX.ZZ.183 dst:64.XX.XX.246
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, checking map = insidemap, seq = 22...
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, map = insidemap, seq = 22, ACL does not match proxy IDs src:205.XX.ZZ.183 dst:64.XX.XX.246
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, checking map = insidemap, seq = 23...
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, Static Crypto Map check, map = insidemap, seq = 23, ACL does not match proxy IDs src:205.XX.ZZ.183 dst:64.XX.XX.246
[IKEv1]: Group = 205.XX.ZZ.177, IP = 205.XX.ZZ.177, IKE Remote Peer configured for crypto map: dynamicmap
10-08-2007 06:19 AM
Try to move the crypto map RA sequence to 65535 and test from the Checkpoint.
10-08-2007 06:30 AM
Sorry for not including this part in the config but the dynamic map currently has the sequence number of 65535.
crypto dynamic-map dynamicmap 65535 set transform-set esp-3des-sha
crypto map insidemap 65535 ipsec-isakmp dynamic dynamicmap
10-08-2007 06:37 AM
Post your crypto maps. It appears it is not finding the correct match.
10-08-2007 06:45 AM
Here it is. I have tried to narrow down the interesting traffic statement from an object group to specific host but no dice.
object-group network inside-host
network-object host 64.XX.XX.247
network-object host 64.XX.XX.246
object-group network remote-host
network-object host 205.XX.WW.247
network-object host 205.XX.XX.247
network-object host 205.XX.YY.247
network-object host 205.XX.ZZ.183
access-list remote-mo extended permit ip object-group inside-host host 205.XX.WW.241
access-list remote-ca extended permit ip object-group inside-host host 205.XX.XX.241
access-list remote-dc extended permit ip object-group inside-host host 205.XX.YY.241
access-list remote-fl extended permit ip object-group inside-host host 205.XX.ZZ.183
crypto ipsec transform-set esp-3des-sha esp-3des esp-sha-hmac
crypto ipsec transform-set esp-aes256-md5 esp-aes-256 esp-md5-hmac
crypto ipsec transform-set esp-aes256-sha esp-aes-256 esp-sha-hmac
crypto dynamic-map dynmap 65535 set transform-set esp-3des-sha
crypto map insidemap 20 match address remote-mo
crypto map insidemap 20 set peer 205.XX.WW.241
crypto map insidemap 20 set transform-set esp-3des-sha
crypto map insidemap 21 match address remote-ca
crypto map insidemap 21 set peer 205.XX.XX.241
crypto map insidemap 21 set transform-set esp-3des-sha
crypto map insidemap 22 match address remote-dc
crypto map insidemap 22 set peer 205.XX.YY.241
crypto map insidemap 22 set transform-set esp-3des-sha
crypto map insidemap 23 match address remote-fl
crypto map insidemap 23 set peer 205.XX.ZZ.177
crypto map insidemap 23 set transform-set esp-3des-sha
crypto map insidemap 65535 ipsec-isakmp dynamic dynmap
crypto map insidemap interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 20
authentication pre-share
encryption aes-256
hash md5
group 2
lifetime 86400
crypto isakmp nat-traversal 20
tunnel-group 205.XX.WW.241 type ipsec-l2l
tunnel-group 205.XX.WW.241 ipsec-attributes
pre-shared-key *
tunnel-group 205.XX.XX.241 type ipsec-l2l
tunnel-group 205.XX.XX.241 ipsec-attributes
pre-shared-key *
tunnel-group 205.XX.YY.241 type ipsec-l2l
tunnel-group 205.XX.YY.241 ipsec-attributes
pre-shared-key *
tunnel-group 205.XX.ZZ.177 type ipsec-l2l
tunnel-group 205.XX.ZZ.177 ipsec-attributes
pre-shared-key *
tunnel-group 204.144.254.3 type ipsec-l2l
tunnel-group 204.144.254.3 ipsec-attributes
pre-shared-key *
10-08-2007 06:20 AM
Try to move the crypto map RA sequence to 65535 and test from the Checkpoint.
10-08-2007 06:51 AM
Can you capture more ISAKMP and IPSEC debug after creating a new crypto map for one of the Checkpoint sites (and nothing else) and binding that to the outside interface? Let's try to simplify and isolate the problem.
10-08-2007 09:10 AM
You sent me down the right path and now it is fixed. Looking at the sh vpn-sessiondb when connected it showed 2 ipsec sessions one where the local address showed up with a subnet mask of 255.255.255.255 and one where it showed up with a 255.255.255.254 mask. I changed my inspect rule to a 255.255.255.254 mask and now I am seeing encryption both ways. Again thanks for your help.
10-15-2007 06:45 AM
Would you please post your good config so I can see what you changed? I am running into something similar and your working config may help me out. - Thanks
10-15-2007 07:10 AM
The only thing that changed is the interesting traffic ACL. I will tell you it makes it easier to have the dynamic map for RA in your map.
It allows the tunnel to come up even if the ACL is not correct, you still have to have your tunnel-group set up correctly to get past Phase 1.
Once the tunnel is up you can do a sh vpn-session detail L2L and see what information the checkpoint is trying to pass. I had to set up 4
more tunnels with checkpoints and I had 2 of them pass the endpoints as the matching traffic rather than the hosts.
crypto dynamic-map dynmap 65535 set transform-set esp-3des-sha
crypto map insidemap 65535 ipsec-isakmp dynamic dynmap
Current
access-list remote-mo extended permit ip 64.XX.XX.246 255.255.255.254 host 205.XX.WW.241
access-list remote-ca extended permit ip 64.XX.XX.246 255.255.255.254 host 205.XX.XX.241
access-list remote-dc extended permit ip 64.XX.XX.246 255.255.255.254 host 205.XX.YY.241
access-list remote-fl extended permit ip 64.XX.XX.246 255.255.255.254 host 205.XX.ZZ.183
Before
access-list remote-mo extended permit ip object-group inside-host host 205.XX.WW.241
access-list remote-ca extended permit ip object-group inside-host host 205.XX.XX.241
access-list remote-dc extended permit ip object-group inside-host host 205.XX.YY.241
access-list remote-fl extended permit ip object-group inside-host host 205.XX.ZZ.183
10-15-2007 07:27 AM
Thanks - that really helps.
10-08-2007 09:23 AM
I found this on the internet and pretty much describes our problem.
The servers which you are accessing are random IP and few of them are
consecutive (e.g if you have added 192.168.1.22/32 and 192.168.1.23/32) it
will take network of 192.168.1.22/255.255.255.254.
This type of problem occurs between Checkpoint and other vendors.
If both the ends are checkpoint then it works fine.
10-08-2007 12:37 PM
Awesome, good job.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide