05-06-2019 09:47 AM
Hi all,
I think most of you experienced it: you have a S2S VPN tunnel with a customer, and during the weeks/months/years the encryption domain keeps expanding with all kind of new subnets here and there.
Consider the following topology:
Ofcourse i can "control" my own subnets, but sometimes you just can't control your customers subnets. In this case, let's say our customer has 3 "splintered" /24 subnets. What would be the easiest/best way for me to NAT those destination subnets?
Let's say i want to NAT them to 10.0.0.0/24, 10.0.1.0/24 and 10.0.2.0/24 without interaction with the customer. Is that possible? If it's possible, would i also be able to simplify my crypto maps?
Solved! Go to Solution.
05-07-2019 11:51 AM
Are you doing this because of a duplicate between your subnet and remote? Or is it just for ease of management? IF there is a duplicate subnet on both sides, doing changes on your side alone may not help the situation as the traffic might still route locally on the remote end. This is more in a situation where both sides had the same subnet and mask (say 192.168.10.0/24 for eg.).
IF this is just for ease of management, you can definitely do a destination NAT on your end. The NAT rule looks like this:
nat (outside, inside) source static obj_192.168.10.0_24 obj_10.0.0.0_24 destination static local_subnet local_subnet no-proxy-arp route-lookup
This means that you would have to access 192.168.10.0 with the 10.0.0.0 from your side. The crypto map ACL does not change since NAT takes place before crypto, hence no change in config at all on the remote end.
05-07-2019 11:51 AM
Are you doing this because of a duplicate between your subnet and remote? Or is it just for ease of management? IF there is a duplicate subnet on both sides, doing changes on your side alone may not help the situation as the traffic might still route locally on the remote end. This is more in a situation where both sides had the same subnet and mask (say 192.168.10.0/24 for eg.).
IF this is just for ease of management, you can definitely do a destination NAT on your end. The NAT rule looks like this:
nat (outside, inside) source static obj_192.168.10.0_24 obj_10.0.0.0_24 destination static local_subnet local_subnet no-proxy-arp route-lookup
This means that you would have to access 192.168.10.0 with the 10.0.0.0 from your side. The crypto map ACL does not change since NAT takes place before crypto, hence no change in config at all on the remote end.
05-07-2019 11:02 PM
05-08-2019 05:30 AM
No specific reason, just easier to understand [for me :)]. You can reverse the rule in the other direction if you want. NAT identity rules are bidirectional in nature, so the effect is the same. A reversed rule would look like this:
nat (inside, outside) source static local_subnet local_subnet destination static obj_10.0.0.0_24 obj_192.168.10.0_24 no-proxy-arp route-lookup
05-08-2019 06:05 AM
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