cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1051
Views
0
Helpful
4
Replies

[S2S Tunnel]How to NAT remote subnets?

Eric Snijders
Level 1
Level 1

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:

clDCvIAOfcourse 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?

1 Accepted Solution

Accepted Solutions

Rahul Govindan
VIP Alumni
VIP Alumni

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.  

View solution in original post

4 Replies 4

Rahul Govindan
VIP Alumni
VIP Alumni

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.  

Hi Rahul,
Thanks for the info! In this case it's indeed for ease of management. Just to make sure:
Is there any specific reason why, in this case, you would make the NAT rule from OUTSIDE to INSIDE and not the other way around. If you look from my perspective (local subnets) you would say the traffic is flowing from inside to outside, hence i would think you would create the NAT rule exact the other way like you say.

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

 

 

Thanks Rahul, really appreciate it!