IP NAT outside.

Unanswered Question
Nov 29th, 2007

Hi all,

Id like to ask someone for help with a NAT

configuration. Id like to publish source

PC in a reverse manner but I dont know how. Reverse manner means next:

source-->router1--->(ip nat outside)router2(ip nat inside)--->router3--->destination

--> means some IP range

Communication should flow from source to destination.

What I want to see is a communication from source translated to IP range of router R2 on inside.

Is over there any solution? Pls. could someone send me a functional configuration?

Any idea?

jl

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Kevin Dorrell Thu, 11/29/2007 - 07:01

That is right, but normally you would have your inside and outside the other way round on R2. Then you simple do an inside source translation.

Kevin Dorrell

Luxembourg

johnleeee Fri, 11/30/2007 - 07:37

Hi Edison,

I have a problem that when I do

ip nat outside source static in R2 router

I see translated source IP in destination properly and reverse traffic is going back.

But problem is that I can see it only on inside

side of R2 router and I cannot see it on outside.

And this is really mystery.

Any idea?

JL

insccisco Fri, 11/30/2007 - 09:04

Hi Edison, I have a similar problem which has been worked on by as many as 8 Cisco Engineers, including team leaders, escalation team, and the backbone team.

It's an IPSec tunnel, between 1841 & ASA. ASA is ready, but the 1841 must fake its 192.168.1.0/24 internal address to 10.12.0.0/24 so it can reach the ASA side as such. Everything else on the 1841 side must stay the same. This faking only applies to packets destined to 10.10.30.0 (the LAN-to-LAN tunnel) so everything else must continue to behave as it is.

The network behind the ASA is 10.10.30.0/24

Cisco guys talk a lot about NAT, I guess NAT is the feature that will do the trick.

I will greatly appreciate any help.

thanks

Jon Marshall Fri, 11/30/2007 - 09:11

Hi

ip nat pool IPSECNAT 10.12.0.1 10.12.0.254 netmask 255.255.255.0

access-list 101 permit ip 192.168.1.0 255.255.255.0 10.10.30.0 255.255.255.0

ip nat inside source list 101 pool IPSECNAT

You will need to ensure that your crypto map access-lists refer to 10.12.0.0/24 and not 192.168.1.0/24 at both ends of the IPSEC tunnel.

HTH

Jon

insccisco Fri, 11/30/2007 - 09:21

Jon, don't get my hopes up!!! :) too good to be true after continuos nightmares with TAC.

Ok, question before I make your code into production: the statement "ip nat inside source list 101 pool IPSECNAT" - would it cause the entire inside traffic to be NATTed to 10.12.0.0/24?

Or would it NATed ONLY for traffic destined to 10.10.30.0 and everything else will stay the same?

Reason I asked is because TAC has made so many tries, and so many network outages because of it, that I remember seeing something like this and it made the config loose ALL its IP NAT INSIDE SOURCE... statements and thus blocked ALL access to the internet.

I will attach the current running config for you to check.

Jon Marshall Fri, 11/30/2007 - 09:24

Hi

The nat is tied to the access-list 101.

So if the packet is coming from a 192.168.1.x address and is going to a 10.10.30.x address then it will be get natted to a 10.12.0.x address from the IPSECNAT pool.

If the destination is not 10.10.30.x then it will not get Natted from that pool.

I hope i have understood your requirements because there are some good guys in TAC and this is not a particularly complicated config.

Obviously test outside of key hours, let me know how you get on.

Jon

insccisco Fri, 11/30/2007 - 10:28

I also do believe that TAC guys are very good. But this is what surprises me as, with only the notion that I have about cisco technology, I know it is a very simple and straight forward configuration.

My ASA has been waiting for this tunnel for the longest and it does point to 10.12.0.0 instead of the real address. When it sends packets to that 192.168.1.0/24, it is already going to a different tunnel, thus the reason for this "faking"

To be honest, I can't wait to implement your suggestion. It's 1:20pm for me, EST time, and my remote office work with the market schedule, so as soon as 4:00pm ticks, I will get this going.

Meanwhile, would you have an answer why, in one of the many tries cisco has done, ALL my "ip nat inside source... " statements got lost, and the router found itself on an "island". The only 2 IP NAT statements that stayed were 2 that NAT the entire office to each ISP. I know cisco didn't do this on purpose.

I think it was when they were trying to implement a line like "ip nat inside source static network 192.168.1.0 10.12.0.0 /24 no-alias".... I still remember. And so again, this brought the entire network down.

thanks

Edison Ortiz Fri, 11/30/2007 - 11:12

Angel,

I see what I can dig up. Also, would be best if you open a new thread and stick on that thread. I see your postings in different sections of this forum. This may dilute information sent/received to/from you since I don't know if you are making changes someone else may be suggesting.

I saw your router config and I will try to duplicate it. Give me until EOB, thanks.

Thanks

insccisco Fri, 11/30/2007 - 11:25

I think I am finding the right players here. It seems to be that here I find people doing it for the passion whereas TAC do it for the number... your case is a number :( But again, I have talked to great people there

Edison, thank you very much for the help, I look forward for the fix which I will implement at 4:30pm today.

Meanwhile, I just had a call from a cisco manager apologizing for the time is has taken and the frustration on the case.

ap

Edison Ortiz Fri, 11/30/2007 - 13:57

The problem I'm encountering is when having the

ip nat pool NET10 10.12.0.0 10.12.0.254 prefix-length 24 type match-host

!

ip nat inside source list NET192-TO-NET10 pool NET10

!

ip access-list extended NET192-TO-NET10

permit ip 192.168.1.0 0.0.0.255 10.21.30.0 0.0.0.255

along with:

ip nat inside source route-map ISP1 interface FastEthernet0/0 overload

ip nat inside source route-map ISP2 interface FastEthernet0/1 overload

per your config.

It doesn't work as expected.

Let me show you

______________________

Rack1R2#clear ip nat tr *

Rack1R2#sh ip nat tr

If I ping a host other than 10.21.30.0/24 (your ASA network) it works fine the first time

Rack1SW2#ping 10.0.3.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:

!!!!!

Rack1R2#sh ip nat tr

Pro Inside global Inside local Outside local Outside global

icmp 66.11.203.209:42 192.168.1.254:42 10.0.3.1:42 10.0.3.1:42

If I ping the network behind the ASA

Rack1SW2#ping 10.21.30.254

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.21.30.254, timeout is 2 seconds:

!!!!!

Rack1R2#sh ip nat tr

Pro Inside global Inside local Outside local Outside global

icmp 10.12.0.254:43 192.168.1.254:43 10.21.30.254:43 10.21.30.254:43

--- 10.12.0.254 192.168.1.254 --- ---

If I get to ping the first network again

Rack1SW2#ping 10.0.3.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:

!!!!!

Rack1R2#sh ip nat tr

Pro Inside global Inside local Outside local Outside global

icmp 10.12.0.254:43 192.168.1.254:43 10.21.30.254:43 10.21.30.254:43

icmp 10.12.0.254:44 192.168.1.254:44 10.0.3.1:44 10.0.3.1:44

--- 10.12.0.254 192.168.1.254 --- ---

_____________

It does not go back to the overload but remains with the pool list. This is very strange and I will need more time on this.

insccisco Fri, 11/30/2007 - 14:14

:( ------------:((((((

So it does seem to be more complicated than anyone would think ah?

Edison, by any means, if you have to redo this 1841 configuration from scratch, please go ahead.

Main things we want are:

1)internet connectivity via ISP1

2)if ISP1 fails, router will re-route to ISP2

3)LAN-to-LAN tunnel with the 10.21.30.0 up.

As you already saw on the config, ip sla work, internet connectivity works, so again, it is the tunnel

If when in failover mode tunnel does not failover to ISP2, that is no problem. It is already a big issue to get it fixed via ISP1, so we dont want to have more nightmares specially when is not even working via ISP1 to begin with.

I was on-site and waiting :( but np. please let me know once we get it. You have my info.

Thank you very much again for your help. I really appreciate it

Edison Ortiz Fri, 11/30/2007 - 14:20

Angel,

Please remain working with TAC since I'm working with other projects and I do this as volunteer in my spare time.

If this is a bug, TAC has the ability to contact the right people to address this issue.

I was trying to see if something was missing but based on your requirements, it's not a simple configuration and it will take some time on a proper design.

insccisco Fri, 11/30/2007 - 14:26

np again.

But I still think is simple. There isn't really any requirements outside of a very simple configuration: LAN to LAN tunnel with overlapping networks.

If anyone can shed some light on this, that wil be more than helpfull.

The thing that kills me is that I have this implementation between a pix and an ASA and it took 2 lines on the pix. I thought routers would be easier.

ap

Edison Ortiz Fri, 11/30/2007 - 14:43

Ok,

I got working by decreasing the NAT timers:

_____________

Here is what the host receives when the destination is a network other than 10.21.30/24

The source represents the overload F0/0 address

*Mar 1 01:50:34.187: IP: tableid=0, s=66.11.203.209 (Vlan1), d=10.0.2.1 (Loopback2), routed via RIB

*Mar 1 01:50:34.191: IP: s=66.11.203.209 (Vlan1), d=10.0.2.1, len 100, rcvd 4

*Mar 1 01:50:34.195: IP: tableid=0, s=10.0.2.1 (local), d=66.11.203.209 (Vlan1), routed via FIB

*Mar 1 01:50:34.199: IP: s=10.0.2.1 (local), d=66.11.203.209 (Vlan1), len 100, sending

*Mar 1 01:50:34.547: IP: tableid=0, s=66.11.203.209 (Vlan1), d=10.0.2.1 (Loopback2), routed via RIB

Now, it shows the NAT'd address as the source with destination 10.21.30.254

*Mar 1 01:50:36.763: IP: tableid=0, s=10.12.0.254 (Vlan1), d=10.21.30.254 (Vlan1), routed via RIB

*Mar 1 01:50:36.767: IP: s=10.12.0.254 (Vlan1), d=10.21.30.254 (Vlan1), len 100, rcvd 3

*Mar 1 01:50:36.771: IP: tableid=0, s=10.21.30.254 (local), d=10.12.0.254 (Vlan1), routed via FIB

*Mar 1 01:50:36.775: IP: s=10.21.30.254 (local), d=10.12.0.254 (Vlan1), len 100, sending

*Mar 1 01:50:37.251: IP: tableid=0, s=10.12.0.254 (Vlan1), d=10.21.30.254 (Vlan1), routed via RIB

*Mar 1 01:50:37.255: IP: s=10.12.0.254 (Vlan1), d=10.21.30.254 (Vlan1), len 100, rcvd 3

*Mar 1 01:50:37.259: IP: tableid=0, s=10.21.30.254 (local), d=10.12.0.254 (Vlan1), routed via FIB

________________________

These are the changes in your config:

ip nat pool NET10 10.12.0.0 10.12.0.254 prefix-length 24 type match-host

ip nat inside source list NET192-TO-NET10 pool NET10

ip access-list extended NET192-TO-NET10

permit ip 192.168.1.0 0.0.0.255 10.21.30.0 0.0.0.255

ip nat translation timeout 2

ip nat translation tcp-timeout 2

ip nat translation udp-timeout 2

ip nat translation icmp-timeout 2

insccisco Fri, 11/30/2007 - 15:02

impossible.... too good to be true. :) ---

I will go ahead and implement it right away.

I happen to just be reading something about NAT time-outs when I read your post.

With theses changes, we are 100% sure that everything else will continue to work as it is, right? I mean inside (192.168.1.0/24 properly going to the internet and also the email server on the inside properly getting its traffic on port 25)?

just want to make sure.

Edison, thank you again.

Edison Ortiz Fri, 11/30/2007 - 15:09

I don't see any static nat for port 25 in your config. NAT timeout at 2 second will create a problem with translation for email.

The only 2 static translation I see are for port 20 and 21.

insccisco Fri, 11/30/2007 - 15:12

there is a line "ip nat inside source static tcp 192.168.1.3 25 66.11.203.210 25 route-map ISP1 extendable" and another one "access-list 100 permit tcp any host x.x.x.x eq smtp" that are taking care of the email server.

I guess you dont call it static nat, but rather port forwarding, right? please confirm if I am correct

insccisco Fri, 11/30/2007 - 15:14

forgot to ask you if I should continue with the implementation... will the email server still be able to act normally after these codes?

Edison Ortiz Fri, 11/30/2007 - 15:26

I did an implementation recently where the client had problems with email with the NAT timeout being too low.

Changing the timeout back to 60 seconds fixed it.

The problem with having a timeout so high is that the traffic will continue to use the pool list instead of the overload.

I suggest you try it and see if your email server is susceptible to this change.

If you really want to do this the right way. Place a device before the 1841 just doing the NAT for network 10.21.30.0/24 and let the 1841 do the NAT for overload.

insccisco Fri, 11/30/2007 - 15:45

Edison, I just finished and it works but only in one direction: from the 1841 to the ASA.

These are the lines I added to the config that I just sent you:

ip nat pool NET-10 10.12.0.0 10.12.0.254 prefix-length 24 type match-host

ip access-list extended NET192-TO-NET10

permit ip 192.168.1.0 0.0.0.255 10.21.30.0 0.0.0.255

ip nat translation timeout 2

ip nat translation tcp-timeout 2

ip nat translation udp-timeout 2

ip nat translation icmp-timeout 2

ip nat inside source list NET192-TO-NET10 pool NET-10

Again, I added these lines to the current running config (the one I just updated you with).

Do I need to add other lines or modify some? Like the ones for the interesting traffic, they currently show as "access-list 190 deny ip 192.168.1.0 0.0.0.255 10.21.30.0 0.0.0.255" and the other which is applied to the crypto map "permit ip 192.168.1.0 0.0.0.255 10.21.30.0 0.0.0.255"

let me know

insccisco Fri, 11/30/2007 - 16:56

It didn't work. Every time a pc from the 192.168.1.0 side made a connection to the 10.21.30.0 side (by a simple ping for example), "ip sh nat tr" showed that the 192.168.1.3 device had a one to one translation to 10.12.0.3. The ping was successfull.

So all good. However, when that same 192.168.1.3 host tried to communicate to the outside world, this is what was happenning: it was timing out, it never really made a connection.

Also, when the ping was established from the 1841 side, the host was indeed pingable from the ASA side, but again, the 192.68.1.3 host couldnt communicate to anything else but the tunnel.

Bottom line is that it doesn't work :(

Any idea why this behavior?

Edison Ortiz Sat, 12/01/2007 - 06:59

Angel,

You are bringing a new set of requirements along with a different configuration.

Sorry, I don't have the equipment to duplicate your scenario anymore, it was a loaner.

I will step out of this thread and let someone else help you or continue working with TAC.

insccisco Sat, 12/01/2007 - 10:08

Edison I got it working. I remember an old dirty trick one cisco guy had suggested. Last night we went ahead and tried it and it worked.

all good.

thank you for the help

ap

insccisco Tue, 12/04/2007 - 08:40

Certainly... my apologies for the delay though as I quickly engaged into more cisco headaches :)

Here is the rundown.. I remember few cisco engineers mentioning something about a limitation on the router to accomplish this; others mentioned a bug.

The solution didn't seduce me at first, because it is not very scalable, especially if you have a network bigger than a /24 one, but it worked :) We were already close to buying a pix or a router to put behind the 1841 just for the purpose of doing this "NAT faking" as one cisco tac had suggested.

Let me know if this config can perhaps get any better..

here is the code

crypto map outsidemap1 10 ipsec-isakmp

match address insc_acl1

ip nat inside source route-map ISP1 interface FastEthernet0/0 overload

ip nat inside source route-map ISP2 interface FastEthernet0/1 overload

ip nat inside source static 192.168.1.1 10.12.0.1 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.3 10.12.0.3 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.49 10.12.0.49 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.50 10.12.0.50 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.51 10.12.0.51 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.52 10.12.0.52 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.53 10.12.0.53 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.54 10.12.0.54 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.55 10.12.0.55 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.56 10.12.0.56 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.57 10.12.0.57 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.58 10.12.0.58 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.59 10.12.0.59 route-map 192_168_to_10_21 reversible

ip nat inside source static 192.168.1.60 10.12.0.60 route-map 192_168_to_10_21 reversible

ip nat inside source static tcp 192.168.1.223 20 66.11.203.210 20 extendable

ip nat inside source static tcp 192.168.1.3 25 66.11.203.210 25 route-map ISP1 extendable

ip nat inside source static tcp 192.168.1.3 80 66.11.203.210 80 route-map ISP1 extendable

ip nat inside source static tcp 192.168.1.3 110 66.11.203.210 110 route-map ISP1 extendable

ip nat inside source static tcp 192.168.1.3 443 66.11.203.210 443 route-map ISP1 extendable

ip nat inside source static tcp 192.168.1.3 3389 66.11.203.210 3389 route-map ISP2 extendable

ip nat inside source static tcp 192.168.1.223 20 68.195.222.42 20 extendable

ip nat inside source static tcp 192.168.1.3 25 68.195.222.42 25 route-map ISP2 extendable

ip nat inside source static tcp 192.168.1.3 80 68.195.222.42 80 route-map ISP2 extendable

ip nat inside source static tcp 192.168.1.3 110 68.195.222.42 110 route-map ISP2 extendable

ip nat inside source static tcp 192.168.1.3 443 68.195.222.42 443 route-map ISP2 extendable

ip nat inside source static tcp 192.168.1.3 3389 68.195.222.42 3389 route-map ISP2 extendable

access-list 125 permit ip 192.168.1.0 0.0.0.255 10.21.30.0 0.0.0.255

route-map 192_168_to_10_21 permit 10

match ip address 125

route-map USE_ISP2 permit 10

match ip address 125

set ip next-hop 68.195.222.41

So, to Tunnel the entire 254 hosts, we'll need to code the rest of the lines... dirty like the last engineer said, but it works smoothly both ways (meaning tunnel can be initiated at any end of the Tunnel)

Actions

This Discussion