Re: Remote NAT issues on site to site VPN

leathem123 · ‎12-19-2018

Hi,

We have a site to site VPN and when we source a ping from the local LAN the ping to the remote site it works fine.

10.20.3.50(local) pinging 10.14.1.89 (remote side of VPN )pings ok, it hits the local firewall and 10.20.3.50 is nat'd to 10.17.7.25 and 10.14.1.89 replies. So all good when traffic is initiated on the local site.

If 10.14.1.89 (remote) tries to ping 10.17.7.25(10.20.3.50 local) we get a response from the local core switch saying "TTL expired in transit".

I believe the packet is not being un-nat'd on the local firewall from 10.17.7.25 to 10.20.3.50 and is in a routing loop. I don't know why the packet is not being u-nat'd. This is the config;

crypto map OUTSIDE-MAP 22 match address XXX-VPN
crypto map OUTSIDE-MAP 22 set pfs
crypto map OUTSIDE-MAP 22 set peer x.x.x.x
crypto map OUTSIDE-MAP 22 set ikev1 transform-set ESP-AES-256-SHA
crypto map OUTSIDE-MAP 22 set security-association lifetime seconds 28800
crypto map OUTSIDE-MAP 22 set security-association lifetime kilobytes 4608000
crypto map OUTSIDE-MAP 22 set nat-t-disable

access-list XXX-VPN extended permit ip object-group INTERNAL-XXX-NAT-GROUP object-group XXX-SUBNETS

object-group network INTERNAL-XXX-NAT-GROUP
description Internal INTERNAL to XXX NAT'd summary
network-object 10.17.7.24 255.255.255.248

object-group network XXX-SUBNETS
network-object 10.14.1.0 255.255.255.0
network-object 10.14.2.0 255.255.255.0
network-object 10.14.8.0 255.255.255.0

nat (INSIDE-TRANSIT,OUTSIDE) source static INTERNAL-XXX INTERNAL-XXX-NAT destination static XXX-SUBNETS XXX-SUBNETS description VPN Traffic

object-group network INTERNAL-XXX
network-object host 10.20.3.50
network-object host 10.20.3.51
network-object host 10.101.110.50
network-object host 10.101.108.11
network-object host 10.20.3.120

object-group network INTERNAL-XXX-NAT
network-object host 10.17.7.25
network-object host 10.17.7.26
network-object host 10.17.7.27
network-object host 10.17.7.29
network-object host 10.17.7.28

object-group network XXX-SUBNETS
network-object 10.14.1.0 255.255.255.0
network-object 10.14.2.0 255.255.255.0
network-object 10.14.8.0 255.255.255.0

Any ideas?

Thanks,

John

luis_cordova · ‎12-19-2018

Hi @leathem123,

https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/14144-static.html

Check this link, maybe I can help you. Look at this subtitle:

What about the static NAT though, why can I not get to that address over the IPsec tunnel?

Regards

leathem123 · ‎12-20-2018

Hi,

I would have thought this would have NAT'd traffic returning from the other side?

nat (INSIDE-TRANSIT,OUTSIDE) source static INTERNAL-XXX INTERNAL-XXX-NAT destination static XXX-SUBNETS XXX-SUBNETS description VPN Traffic

Thanks,
John

erwindebrouwer · ‎12-19-2018

Hi leathem123,

I believe the ASA can not interpret these groups of host-addresses to map to your NAT table. So, I'm curious about your "show xlate" output in this situation and I expect this to work correctly when you create 5 separate NAT statements... so one for each translation.

I would like to hear the result.

leathem123 · ‎12-20-2018

Hi,

show xlate
NAT from INSIDE-XXX:10.20.3.50, 10.20.3.51, 10.101.110.50,
10.101.108.11, 10.20.3.120 to OUTSIDE:10.17.7.25,
10.17.7.26, 10.17.7.27, 10.17.7.29,
10.17.7.28
flags sT idle 0:00:00 timeout 0:00:00

I think the issue may be because the interesting traffic ACL is a Summary and not /32s like the NAT statements. Im going to get this changed.