cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6264
Views
0
Helpful
10
Replies

Destination NAT !

illusion_rox
Level 1
Level 1

Hi all, i have a server that is on ip 10.2.2.20/24. This server is being migrated to new ip 192.168.1.10/24. Now the number of clients is 100+. Requirement is that if a client hits on 10.2.2.20, it should be TRANSLATED to 192.168.1.10. But if it hits 192.168.1.10 then nothing should happen ( i mean no nat). I may have not been able to completely describe the issue since its bit complex but i know my requirement which is, if a packet comes in with destination ip 10.2.2.20, it should be translated to 192.168.1.10 !! i am trying my best but couldnt achieve it. I want it to be conditional means, some clients may hit the server on its new ip, but many clients right now will be hitting the server on its old ip (10.2.2.20), so i have to define an access-list that when traffic sourced from 10.1.1.0/24 is hitting 10.2.2.20 then 10.2.2.20 should be translated to 192.168.1.10 !!.

Kindly tell me how to achieve this through nat

1 Accepted Solution

Accepted Solutions

Ovais,

Is there any restriction on not doing natting on R4? As doing NATing closer to the source i.e. on R4 will be more simpler than on R2. So when your traffic reached at head office-R2, you dont need to segregate based on their source addresses as it is already natted. So on R4 you can use:

ip nat outside source static

so in your case this will be:

ip nat outside source static 192.168.1.10 10.2.2.20.

Note that even though destination 10.2.2.20 is natted to 192.168.1.10 using above command, you will require to have route for 10.2.2.20 on R4 considering NAT oder of operation.

Or else if you want to do natting on Head office - R2/R1 then you can use this setup.

ip nat inside source static < inside local IP > route-map R2XLATE

ip access-list extended R2XLATE

route-map R2XLATE permit 10

match ip address R2XLATE

Hope this help.

View solution in original post

10 Replies 10

illusion_rox
Level 1
Level 1

hi all, is my requirement confusing ? kindly let me know since i am very confused as how to achieve this task..

Pls guide me

Jon Marshall
Hall of Fame
Hall of Fame

It's not entirely clear what you are trying to do.

Is it traffic that is sourced purely from 10.1.1.0/24 going to 10.2.2.20 that you want to NAT 10.2.2.20 to 192.168.1.10 ?

What device are you working on ie. a router/firewall etc.

Whichever device you are using where are the interfaces on that device in relation to the IP addressing ie. 10.2.2.x. 10.1.1.x and 192.168.1.x.

Is the 10.2.2.x network still in use ?

Jon

Dear Jon, thanks alot for feedback, i have attached the diagram. Now my requirement is

1) Packet from 10.1.9.0/24 will be destined to 192.168.1.10. It shouldnt be natted.

2) PAcket from 10.1.8.0/24 will be destined to 10.2.2.20, this packet will reach R2, R2 has 10.2.2.0/24 as directly connected but i have given host route towards R1. Now i want the destination 10.2.2.20 to be changed to 192.168.1.10 if packet is sourced from 10.1.8.0.

As you can see, i want to KINDA run both ip 10.2.2.20 and 192.168.1.10 in parallel . I have almost 50 branches with distinct networks like 10.1.11.0/24, 10.1.12.0/24 and so on, this migration is slow so i want to have such a policy that when packet is destined for 10.2.2.20 then 10.2.2.20 should be natted to 192.168.1.10.

I hope its clear pls guide me in this

Ovais,

Is there any restriction on not doing natting on R4? As doing NATing closer to the source i.e. on R4 will be more simpler than on R2. So when your traffic reached at head office-R2, you dont need to segregate based on their source addresses as it is already natted. So on R4 you can use:

ip nat outside source static

so in your case this will be:

ip nat outside source static 192.168.1.10 10.2.2.20.

Note that even though destination 10.2.2.20 is natted to 192.168.1.10 using above command, you will require to have route for 10.2.2.20 on R4 considering NAT oder of operation.

Or else if you want to do natting on Head office - R2/R1 then you can use this setup.

ip nat inside source static < inside local IP > route-map R2XLATE

ip access-list extended R2XLATE

route-map R2XLATE permit 10

match ip address R2XLATE

Hope this help.

Dear Sir, IT WORKED !!! but everything just went above my head, what just happened ?

See this is my confgiuration

access-list 111 per ip host 10.1.9.1 host 10.2.2.20

route-map test

mat ip add 111

ip nat inside source static 192.168.1.10 10.2.2.20 route-map test

Now, clients can access either IPs, which is exactly what i wanted but why ? i mean i just gave one entry that is when a packet is sourced from 10.1.9.1 then do the translation only, but in my case, all the clients are being natted !!! i.e. 10.1.8.1, 10.1.11.1 etc, why is this so ? i really dont see any significant role of access-list here but no doubt is working, i am totally confused.

Pls guide me

Could you make sure your configuration on R2 is something like this.

interfaces x

ip address 13.0.0.1

ip nat outside

interface y

ip address 11.0.0.2

ip nat inside

access-lists 111

permit ip host 192.168.1.10 host 10.1.9.1

Also have you thought about using other option(doing natting on R4)? It is more safer and simple way for your requirement.

Dear Sir, i cant actually do it on R4, because R4 is a client and i have like 100+ clients like this, so natting on all of them will be a lot of overhead. Right now i am doing as per you say but access-list doesnt seem to work, its allowing all the traffic destined to 10.2.2.20 to translate to 192.168.1.10, where as any traffic destined to 192.168.1.10 is going without natting. So i am totally confused as what is the purpose of this acl then ?

I tried emulating your scenario in lab environment and found expected result. When packets match communication identified by ACL, they were natted whereas remaining packets were unaffected. I verified this behavior using 'sh ip nat tr' command.

Please note that I was not able to emulate your scenario completely and not sure if any software glitch is affecting your setup. In any case one confirmed thing which you also noted that traffic destined to 10.2.2.20 is getting translated to 192.168.1.10, where as any traffic destined to 192.168.1.10 is unaffected. So basically you are getting response for both IPs while there is a compromise in your setup where you are losing your ability to translate packets based on their source addresses.

Please rate all helpful responses.

Dear Sir, i am using 3845 12.4(20)T. Sir no doubt my issue is resolved but i have just given only one ip in my access-list, so how come any ip that is hitting 10.2.2.20 is being translated to 192.168.1.10 ? its confusing all my concepts sir, kindly guide me in this

I dont see any logical reason behind this. Also my simulation of this issue in lab did not show up any such behavior. Could you try adding specific deny statement(above current permit statement) for particular host and test from that host to see if it appears in NAT table or not?

Review Cisco Networking products for a $25 gift card