Multiple Customer NAT IP Overlapping Problems

Unanswered Question
Jul 31st, 2008

I'm been fearing that this issue would arrive and it finally has. I have quite a bit of Frame, MPLS, and ATM connections all from different customers whose network I have no control over. Being able to support these customers means I have to route the IP range(s) that the customer network uses internally, many of which don't have a IT team that understand NAT and how to configure it correctly.

I have started a solution that would take the incoming IP ranges and using the "ip nat inside source list <omitted> overload" be able to NAT the customer into 1 IP address. I would then only need to route that 1 IP into my core/dist network, leaving no overlapping problems.

This has worked, but in a large scale if another customer on the same frame router has the same IP range(s), I can't use 2 different route-maps since it will match the first one only and the translation would become that of another customer. I was hoping someone knew of a way to use policy-map's or another type of route-map configuration to resolve the issue.

Please see diagram for configuration and in more detail of the problem I face.

Thanks for any recommendations!

Clint Simmons

Network Engineer

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.8 (4 ratings)
lamav Fri, 08/01/2008 - 05:25

You shouldnt be NATing all your clients to the same subnet....maybe Im misunderstanding you.

You should assign a subnet to each individual client/customer, perform the NAT on the edge, and route their network and be done with it.

Am I missing something?

[EDIT] I read your diagram and I think I understand a bit better now.

How about not NATing such huge blocks of addresses at once? Get more specific by increasing the prefix length of the source subnet you want to NAT....

You could also create more soecific ACLs that differentiate source applicationa and destination ports...

VL

csimmons@appros... Fri, 08/01/2008 - 05:31

You are correct, that's what I need to do but the problem is that if 2 individual clients have the same source network (ie: 172.23.240.x/24) then the NAT takes place on the first route-map (nat pool) that matches that access-list for customer CUSTA or CUSTB, whichever comes first.

How can I determine which subnet the individual clients will be NAT'd to if they are sourcing from the same IP range and terminating on the same router?

Is there a way to match the incoming interface as well? I haven't been successful in doing this, and since I'm in a production network it's very hard to have downtime to test.

Thanks,

Clint

Marwan ALshawi Fri, 08/01/2008 - 06:20

i think the better way for u is to use VRF for each customer in this case u will not be in trouble even they have overlaping IP addresing

gonna make a separate routing table for each customer

u can do nating or not up to ur design

but VRFs will help u alot

see the following link read it and understand it carefully then u might redesign ur network to get around the overlaping issue

by the way with vrf it is not must to use mpls

easy

if u need config and redsignd let me know for help

again this link very useful

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008084994e.pdf

good luck

please, Rate if helpful

csimmons@appros... Fri, 08/01/2008 - 07:43

Would you be able to post a sample configuration between the 3660/3745 and my 6509's? Simplex is fine, I can look-up the rest.

Remember that the clients end routers/firewalls cannot be modified or changed in any way. All changes must only exist in my network.

Thanks Again,

Clint

csimmons@appros... Fri, 08/01/2008 - 05:42

"How about not NATing such huge blocks of addresses at once? Get more specific by increasing the prefix length of the source subnet you want to NAT....

"

If I NAT in huge blocks then multiple clients will source into my core network with the same NAT source address, in which I cannot differentiate between the clients within logs, netflow, etc..

Any suggestions?

Thanks,

Clint

lamav Fri, 08/01/2008 - 06:51

"If I NAT in huge blocks then multiple clients will source into my core network with the same NAT source address, in which I cannot differentiate between the clients within logs, netflow, etc.."

Thats why I said not NATing huge blocks...

VRF is an excellent solution....Marwan is right.

Marwan ALshawi Fri, 08/01/2008 - 16:58

i just wanna know cuple of things befor i do the config to avoid any misconfig

first what is the service u provide

i mean do u connect customers sites together? or u give them a shred service? especiallt what is the role of CAT6509 in ur network

also if posible send me copy of the 6509 config

thank you

csimmons@appros... Tue, 08/05/2008 - 13:34

I have attached another Diagram with the exact layout information.

We are an ASP that provides Citrix and Web Applications. No internet access unless there is an emergency; ie: DR situation

All customers own their own circuits. We do not connect customer sites, we are merely the last termination point for our customer applications.

My 6509 config is very basic, Rack Switch trunking and Server VLAN's, nothing fancy. The 6509 acts as a default route. The 3750's and PIX take over the routing. The 3750's will be replaced with 6504's very soon.

Thanks again,

Clint

Marwan ALshawi Fri, 08/01/2008 - 19:41

what i have don for u simple lab to send u sample config

PE iin the config mean the router edg u have and i applied config only for cutstomer A but withing the same manner u can do it for all customers and they all can have the same IP range becasue their routing table will be saparte from the global routing table which is the router routing table withing ur own network

u can control the comunication between VRFs through the route-target import and exaport

import mean what other a exporting and vis versa

the 6500 i used router here

but u can use the same config

only the deffrence is u need to put the interface config on a vlan interface

or u could make a routed interface then gonna be the same

check the attached file for sample config

good luck

Please, if helpful Rate

Attachment: 
csimmons@appros... Tue, 08/05/2008 - 13:03

Thanks for the example documentation. I understand the layout better after reading it.

I may have another problem I have to face. Between the PE and P there is a PIX 525 in the middle.

PE --> (int4) PIX (int2) --> P

How will the PIX be able to route the IP ranges without having the overlapping IP ranges?

I'm assuming that I would just route the 172.16.0.0/16 to ROUTER-A and let the VRF determine the Customer it should route to. However lets say ROUTER-A has 172.16.0.0/16 and ROUTER-B has 172.16.24.0/24. The only way to get around this would be to route 172.16.24.0/24 to ROUTER-B only. The problem would then be that ROUTER-A wouldn't be able to use 172.16.24.0/24 on CUST-A's network.

Any ideas?

Thanks,

Clint

Marwan ALshawi Tue, 08/05/2008 - 18:15

cool now the view is deffrent to me

waht i would sugest here

VRF will be used but defrently

u have deffrent customers, not connected between each other so that mean each with it own routing and maybe each need diffrent security policies maybe not must

to achive full network virtualization for ur case do the following

the edge Router will be configured with VRF for each customer

in this case we gonna keep a saparate routing table for each customer at that router so in ur case u can use overlaped address

but heree because u have datacenter and deffrent customers not connected and there is a firewall in the path

we will not use BGP and also we will not Extend the use of VRFs in other words the VRFs will be kepts on the edge router only

now u wondring how we gonna route these addresses on ur network

the answer is

the edge router now has VRF for each customer and this edge router connected to a PIX firewall

what we need to do now is to make another stage of virtualization but this time on the PIX

we will achive this with miltipule context mode

in this case u have to create for each customer (VRF) a saparate context (vertual Firewall) with its own interfaces (if u dont have enogh interfaces u could achive it through subinterfaces) and in the edge router each VRF will have a default route or a route for the datacenter pointing to the PIX

BUT

each VRF will point to deffrent IP

in the case

EACh VRF will point its static route the corsponding context

so the view will be from vertual perespective like :

customerA--EdgeRouterVRF A---PIX contextA--gateway

customerB--EdgeRouterVRF B---PIX contextB--gateway

i have sent a bove a link

i will put it here again which explain this idea with details and config

go to the following section in the following link

Shared Internet Access-Virtualized Internet Edge Design

instead of the internet in the example u can consider it ur ciritx server for exampl

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008084994e.pdf

good luck

and if u have any more questions just post it here

please, if helpful Rate

csimmons@appros... Wed, 08/06/2008 - 06:13

Somehow I knew you were going to suggest multiple contexts. As of right now I'm not using multiple context mode, I have 10 interfaces in which I'm using 8 of them with 2 spares.

It's not possible at this time to enable multiple context mode, it would require some reconfiguration on my end and prep work with a maintenance window.

If there anyway just to use the single context mode and use sub-interfaces only as you suggested?

csimmons@appros... Fri, 01/02/2009 - 08:43

Does anyone have an answer to the question above?

The reason why I may not be able to use multiple contexts for each client is due to having 30+ clients that I would have to do this for.

Is there an alternative method as I stated above as well?

Thanks,

Clint

Actions

Login or Register to take actions

This Discussion

Posted July 31, 2008 at 1:55 PM
Stats:
Replies:13 Avg. Rating:4.75
Views:260 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 15,007
2 8,155
3 7,745
4 7,088
5 6,747
Rank Username Points
140
80
78
69
40