NATing Branch Site's LAN subnets to something else when received on the Head Site's WAN Port to avoid subnet conflicts

[Dean Romanelli]

Hi All,

I have a site in Brazil about to cut over to my infrastructure that needs to route back to my data center in the US once cut. There are 16 subnets at this Brazil site; All of which conflict with other sites on my network.  I am using a priate local loop oceanic point-to-point connection between Brazil and the US, so no internet or VPN's involved.

My question: When I receive Brazil's LAN traffic on the WAN side of my 1921 router in the US, can I NAT in the WAN-to-LAN direction their incoming LAN traffic to different subnets so that by the time that traffic traverses to the LAN port on my 1921 in the data center, it will be translated to something that doesn't conflict? Or does NATing only work to translate local LAN subnet to local WAN address and vice-versa?

[Julio E. Moisa · Accepted solution]

Hi Dean, 

I have not faced this situation before, but you could NAT the LAN on the Branch and advertise "The translated subnets"for example:

Brazil LAN 

172.16.100.0/24

interface loopback 100

ip address 192.168.100.1 255.255.255.0

ip nat inside source static network 172.16.100.0 192.168.100.0 /24 or 255.255.255.0

interface g0/0

description TO-US-HQ

ip nat outside

interface g0/1

description LAN

ip nat inside

It should be done for each overlaped subnet and the "NATed subnets examples 192.168.100.0/24 must be advertised to be known in US.

Hope it is useful

:-)

[Dean Romanelli]

Hi Julio,

I like that idea. However, let me build upon my scenario. I left out some details for simplicity, but doing this would require me to share them. The Brazil site is actually 4 separate physical sites. 3 of them use Sonicwall VPN's over broadband to the 4th (main) site which receives said VPN's on their own Sonicwall. From there I LAN route all subnets recieved from those VPN's to the Brazil Cisco 1921 (physically at same site that received the VPN's) that will connect to the P2P to the Cisco 1921 at US data center.  See attached drawing for depiction.

If I NAT on the 1921 at the main Brazil site all subnets I received over the VPN's from the other 3 branch sites, will I run into a problem since I learned about those other 3 sites's subnets over VPN's?  Shouldn't matter right, because once they traverse the internet inside the VPN and arrive on the main Brazil site Sonicwall, they get decrypted back to their private subnets when they enter the LAN. SO as long as I LAN route those subnets to the 1921, it will learn about them right?

[Rob Ingram]

Hi Dean, as everyone else on this thread has suggested, NAT is possible, but have you considered the implications in regard to DNS? You'll need to define DNS entries for each US DC server that is to be accessed from Brazil, this might be unmanageable and unfeasible, especially if accessing AD.

[Dean Romanelli]

Hi RJI,

Thanks for your comment. You have a good point.  So for example, the main LAN at the main Brazil site is 192.168.12.0 /24. That is also the SSL intercept/Proxy subnet in US DC that all incoming traffic has to hit before being forwarded to the inside.  So what you're saying is an nslookup done in Brazil for a service on that SSL Intercept/Proxy would return 192.168.12.x, which would then confuse the local network because it's not going to know how to route to the US DC instance of 192.168.12.x because before the NAT point in Brazil, that subnet lives locally.  If so, I suppose I would have to advertise static NAT translations on the US DC side towards Brazil to NAT that subnet into something else as well.  They'd also have to use their own local DNS server and not use our US DC server.  

Hmmm. This is getting quite messy.  Let me take this back to the whiteboard and see what I can do.  Unfortunately there are numerous parties involved and it would be an enormous effort to re-IP these sites prior to cutover. The plan is to remove the NAT's over time, but for the interim, I need a solution where I can just flip the cable from the old MPLS to the new Oceanic Local Loop and have it work.  If I have them re-IP prior to the cutover it will break access to their current data center. And since we have 16 subnets to do, it is not feasible to re-IP all 16 of them in a single maintenance window and make the cut. 

[Pawan Raut]

Hi Dean,
You can do the NAT any direction A to B or B to A depend on your requirements. Make sure that you applied proper direction of NAT inorder to work as per requirement

[paul driver]

Hello

You can use NAT like in a network merger scenario for Brazil traffic coming into US rtr -

Brazil subnet - 192.168.1.0/20

example
access-list 100 deny ip host 192.168.0.1 any
access-list 100 permit ip 192.168.1.0 0.0.15.255 any
ip nat pool Brazil 172.16.16.1 172.16.31.254 prefix-length 20
ip nat inside source list 100 pool Brazil 
ip nat inside source static 192.168.0.1 172.16.31.1 <  static mapping for Brazil's inisde lan address

res
Paul

[Dean Romanelli]

Hi Paul,

I tried testing this and it didn't work.  Did you mean ip nat "outside" source instead?

Also, where would this be implemented? Brazil side or US side router? 

[Georg Pauwen]

Hello,

on a side note, and I agree with RIJ's post, if this is a permanent switchover, I would seriously consider renumbering everything so that it doesn't conflict with existing addresses. I can see a lot of trouble ahead when you want to access any of the remote machines, servers or workstations, which would require static NAT entries, and with multiple sites, that can quickly become unmanageable...

[Dean Romanelli]

Hi Georg,

Yes, I agree. There are definitely some additional things I need to consider regarding that. I've gone back to the whiteboard to see what can be done.

Unfortunately there are numerous parties involved and it would be an enormous effort to re-IP these sites prior to cutover. The plan is to remove the NAT's over time, but for the interim, I need a solution where I can just flip the cable from the old MPLS to the new Oceanic Local Loop and have it work.