Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Weird NAT Concerns


Consolidate the connectivity into one single MPLS IPVPN service provider


1. HQ, Customer_A and Customer_B don't wish to change their LAN IP (172.16.x.x)

2. Customer_A and Customer_B access to HQ for applications offered


1. The MPLS backbone already has the 172.16.x.x network


1. From the scenario above, I believe we'll require to do NAT in order to avoid conflict of IP range. But if I use NAT, all the 172.16.x.x range will be converted to a whole new range. For example now Customer_A is accessing to a FTP server ( located at HQ. Now customer_A need to access to the FTP server at HQ with the new converted range of IP aint it? Is there anyway that Customer_A still can directly access to 172.16.1.x range after we implemented NAT?

2. Since they're consolidating more and more branch into the MPLS network, will that be any problem if there's another Customer (Customer_C) that came in which their LAN clash with one of the existing customer? Scenario like Customer_A (172.16.2.x) and Customer_C (172.16.2.x) accessing to headquarter at once, since their LAN is of the same segment, even though after NAT, will the traffic know how to reach back to Customer_A and Customer_C properly?

3. I thought of doing GRE tunnelling, any suggestion?

It has bugging me for quite a few days and I can't find the right and best approach to tackle it, my technical team keep on telling me there won't be any problem but i just can't get some satisfy answers from them to convince me.

Really appreciate if you guys could tell me whether it can be done and what is the best approach? Thanks a million.


Re: Weird NAT Concerns


forget about the MPLS VPN for a Moment. This is basically a pure IP problem.

1) If a Customer has in the LAN the same IP addresses as used in the HQ, an IP packet will not be sent to the HQ, but routed into the LAN.

2) Which route should be in the HQ IP routing table, if you have two customers with identical IP addresses?

So the basic problem is: IPv4 needs unique addresses to work properly.

Assume C1 - R1 - HQ - R2 - C2

C1,C2 clients in customer networks (both

HQ server in the head quarter (

R1,R2 routers inbetween

C1 will not send a packet to the server because it is it?s own address. So the server IP needs to be Nated to solve this.

C2 will not send a packet to the server because it is it?s own address. So the server IP needs to be Nated to solve this.

HQ will not send a packet to the clients because it is it?s own address. So the client IPs need to be Nated to solve this

Summary: source ADN destination NAT is needed in the router networks R1 and R2 to get communication going.

The finaly solution is to give separate IP address pools to C1,C2 (f.e. and from a HQ perspective and a unique Address to HQ from the client perspective (f.e.

Hope this helps! Please rate all posts.

Regards, Martin

New Member

Re: Weird NAT Concerns

Assume the follows:

i. HQ (

ii. C1 (

iii. C2 (

The LAN IP get natted once exit the router, the natted range is 192.168.x.x

so if they still want to maintain the IP address, and I do all the necessary NAT, can the C1 directly access to HQ segment ( What i worry is, the C1 LAN ( has been natted once the traffic exit from the C1 router. The same goes to the HQ and C2. Can they still able to access directly into the LAN (10.1.x.x)?

Or the access way need to change to the natted IP range which is 192.168.x.x?

I'm quite confused and hope what i trying to explain understood by u guys.


Re: Weird NAT Concerns

How are you doing the NATTING?

You can statically NAT the whole subnet using

ip nat inside source static network

This changes the network part of the address alone. Using this method, the branch will be seen as 192.168.x.x to the rest of the network. Hence, the branch will not have any problem communicating with the HQ. However, you will still have problems communicating with the other branch which has the same LAN IP. The problem here will be that the hosts on the LAN will think that they are on the same LAN with the other branch, which is not so.

The fact that the MPLS core network uses the same address does not matter. The core addresses are hidden from the VPNs

New Member

Re: Weird NAT Concerns

Assume as follows:

Branch1 (10.1.1.x)

Branch2 (10.1.2.x)

Branch1 access to Branch2's FTP at

After I use the static NAT (NAT Pool) all the range already natted to 192.168.x.x range, last time when Branch1 access to Branch2's FTP, they use the, can they remain the same way they access the FTP server after NAT implemented?

Actually the Branches and the HQ are connect in a Hub-and-Spoke design, whereby only branches access to HQ, there is no inter-branch communication...what I concern is, even though there's no inter-branch traffic, but if two branches of the same LAN, even though after NAT implemented, does the HQ know how to get back to the right branch since their LAN ip is of the same range...

For example..Branch_A and Branch_B is at address of 10.1.10.x, after NAT Branch_A is 192.168.2.x while Branch_B is u guys foresee any problem?

What I want to achieve is, the implementation is totally transparent to the user, if Branch_A (10.1.10.x) can access to HQ (10.1.1.x) for services, after the NAT implemented, I want them to be able to access the services at HQ with the same IP range (10.1.1.x) as well, without the need to change their access IP to the new natted range...

I hope i get my question right...I'm really confuse about how an ISP should do when they migrate existing customer's network....sigh


Re: Weird NAT Concerns

The purpose of NAT is to make it look to the outside world that the IP address has changed. Therefore, if you NAT to the 192.168.x.x addresses, you do not need to change address of the branches. Also, they can still access the resources at the HQ the same way they were accessing it before. What to note is that the HQ beleives the branch has a LAN address of 192.168.x.x. Hence, it should have the right routes for 192.168.x.x. Also, for the HQ to access resources at the branch, it will need to use the 192.168.x.x also.

In summary

The branch PCs see their LAN as 10.1.x.x and they are accssing resources at 10.1.x.x

The HQ has her resources at 10.1.x.x and sees connection coming from 192.168.x.x.

Hope this helps

CreatePlease login to create content