11-29-2007 06:49 AM - edited 03-05-2019 07:42 PM
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
11-29-2007 07:01 AM
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
11-29-2007 08:43 AM
Inverse manner is done with the ip nat outside command.
A functional configuration ? How about this URL
11-30-2007 07:37 AM
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
11-30-2007 10:20 AM
Post your config along with the show ip nat trans output.
11-30-2007 09:04 AM
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
11-30-2007 09:11 AM
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
11-30-2007 09:21 AM
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.
11-30-2007 09:24 AM
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
11-30-2007 10:28 AM
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
11-30-2007 10:28 AM
Angel,
What's the SR # on your TAC case ?
11-30-2007 10:36 AM
607291159
11-30-2007 11:12 AM
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
11-30-2007 11:25 AM
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
11-30-2007 01:57 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide