cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2303
Views
9
Helpful
14
Replies

Site-To-Site with NAT

Michael.Tuggle
Level 1
Level 1

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.

14 Replies 14

palomoj
Level 1
Level 1

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.

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

Try to move the crypto map RA sequence to 65535 and test from the Checkpoint.

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

Post your crypto maps. It appears it is not finding the correct match.

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 *

Try to move the crypto map RA sequence to 65535 and test from the Checkpoint.

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.

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.

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

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

Thanks - that really helps.

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.

Awesome, good job.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: