From: George Hansen (HansenG@xxxxxxxxxxxxxxxx)
Date: Fri Mar 01 2002 - 16:22:26 GMT-3
This is my short cut way to figure out if NAT inside/outside is going to work:
The NAT translation will only be successful if you get the packet across the ma
tching interface. 'ip nat inside' must cross the inside interface, 'ip nat outs
ide' must cross the outside interface.
In your case, the static route pointing to r2 forces the packet across the outs
ide interface, causing the translation to occur.
HTH
George
>>> "Ahmed Mamoor Amimi" <mamoor@ieee.org> 02/28/02 08:42PM >>>
Yeap the problem ..... its difficult to explain but i'll try...
IT IS JUST AROUND THAT :
FROM INSIDE TO OUT ROUTING FIRST OCCUR THEN TRANSLATION
FROM OUTSIDE TO INSDIE TRANSLATION OCCUR THEN ROUTING..... this is
the answer but ill explain in example.
Assume :
(inside)r1------------ra---------------r2(outside)
Inside local ip : 10.10.10.1
Inside global ip : 20.20.20.5
Outside local ip : 10.10.10.5
Outside Global ip : 20.20.20.1
When ping from r1 to r2 that is 20.20.20.1 then 10.10.10.1 translated to
20.20.20.5 (this is from the same subnet as of outside global), the ping was
successful as the return was of the ICMP packet..... in this scenerio ra
will first check if the route exist if Ok then translate it.... and it
surely have.
When ping from r2 to r1 that is 10.10.10.1 then 20.20.20.1 translated to
10.10.10.5 , when the packet comes to ra it first translated the check the
router and route to r1...... so far so good.... now the problem part is that
when r1 is returning the ICMP packets and that comes to ra it will check
that source is 10.10.10.1 and destination is 10.10.10.5 ..... ooohhh !! its
on the same subnet why translate.... so it return to the ethernet again....
as FROM INSIDE TO OUT ROUTING FIRST OCCUR THEN TRANSLATION...... this will
occur
01:31:33: IP: s=10.10.10.1 (Ethernet0), d=10.10.10.5 (Ethernet0), len 100,
this is capture from ra ..... u can see that it is sourcing from ethernet 0
and destine to ethernet 0 so why translate.... so the little, old, poor ICMP
dies there on ehternet ground....ooohhh !!! so sad...
This was the whole story.
Solution : Use differenet subnet IP address like.
Inside local ip : 10.10.10.1
Inside global ip : 30.30.30.1
Outside local ip : 40.40.40.1
Outside Global ip : 20.20.20.1
here u also have to make a static route for 40.40.40.1 toward r2.... so when
it is return then ra should know where 40.40.40.1 lies.....
hope this helps u !!
-Mamoor
----- Original Message -----
From: Narvaez, Pablo <Pablo.Narvaez@getronics.com>
To: Ahmed Mamoor Amimi <mamoor@ieee.org>; <ccielab@groupstudy.com>
Sent: Friday, March 01, 2002 8:58 AM
Subject: RE: unexpected behaviour or NAT or i am overlooking
> Mammor, I'm just having the same problem you described below ..... Same
behaviour, same situation, same scenario .... did you figure out how to fix
that? .. did you get to ping from r3 to r1?
>
>
>
> -----Original Message-----
> From: Ahmed Mamoor Amimi [mailto:mamoor@ieee.org]
> Sent: Viernes, 22 de Febrero de 2002 03:10 p.m.
> To: ccielab@groupstudy.com
> Subject: unexpected behaviour or NAT or i am overlooking
>
>
> Hi,
> I have very very simple NAT :
> (inside)R1---------------(e0)R2(NAT)(e1)-----------R3(outside)
> R2 : 192.168.1.1 ---> e0
> 10.10.10.1 -----> e1
> R2 : 192.168.1.2
> R3 : 10.10.10.2
>
> At R2 i have stated :
> ip nat inside static 192.168.1.2 10.10.10.10
> When ever ip add 192.168.1.2 comes translate it to 10.10.10.10
>
> ip nat outside static 10.10.10.2 192.168.1.100
> When ever ip add 10.10.10.2 comes translate it to 192.168.1.100
>
> R1 and R3 are having a default route to R2.
>
> When i ping from R1 it is successful and translation occur.
> As R1 is inside so routing first occur then translation.
>
> When i ping from R3 it is not successful but translation occur
> As R3 is outside translation occur then routing.
>
>
> R3 is sending the packet to R1 and R1 is reciveing it as a source of
> 192.168.1.100, as NAT translate from 10.10.10.2 --> 192.168.1.100
> And R1 is also send the packet to destination of 192.168.1.100 but when
R2
> recive it , it returns the packet to the same ethernet and dont let to
packet
> been return translated to 10.10.10.2 as 192.168.1.100 --> 10.10.10.2
>
> here is the debug of R1 when i ping from R3
> r1#
> 01:23:43: IP: s=192.168.1.100 (Ethernet0), d=192.168.1.2, len 100, rcvd 1
> 01:23:43: ICMP type=8, code=0
> 01:23:43: IP: s=192.168.1.2 (local), d=192.168.1.100 (Ethernet0), len 100,
> sendi
> ng
> 01:23:43: ICMP type=0, code=0
> r1#
> 01:23:45: IP: s=192.168.1.100 (Ethernet0), d=192.168.1.2, len 100, rcvd 1
> 01:23:45: ICMP type=8, code=0
> 01:23:45: IP: s=192.168.1.2 (local), d=192.168.1.100 (Ethernet0), len 100,
> sendi
> ng
> 01:23:45: ICMP type=0, code=0
>
> it is clearing saying that it is reciving the ping from 192.168.1.100 and
then
> sending back to it but when R2 gets it packet it say :
>
> 01:16:12: IP: s=192.168.1.2 (Ethernet0), d=192.168.1.100 (Ethernet0), len
100,
> r
> cvd 3
> 01:16:12: ICMP type=0, code=0
> 01:16:12:
> framer7#
> 01:16:14: IP: s=192.168.1.2 (Ethernet0), d=192.168.1.100 (Ethernet0), len
100,
> r
> cvd 3
> 01:16:14: ICMP type=0, code=0
>
> it is clear that R2 is recives the packet from R1 then it return the
packet to
> ethernet 0 .
>
> ........
> The funny thing is that when i directly ping from R1 to address
192.168.1.100
> then it succeed.
> here is the debug of R2 :
>
> 01:31:32: ICMP type=0, code=0
> 01:31:32:
> 01:31:33: IP: s=192.168.1.2 (Ethernet0), d=192.168.1.100 (Ethernet0), len
100,
> r
> cvd 3
> 01:31:33: ICMP type=8, code=0
> 01:31:33:
> 01:31:33: IP: s=192.168.1.100 (local), d=192.168.1.2 (Ethernet0), len 100,
> sendi
> ng
> 01:31:33: ICMP type=0, code=0
> 01:31:33:
> 01:31:33: IP: s=192.168.1.2 (Ethernet0), d=192.168.1.100 (Ethernet0), len
100,
> r
> cvd 3
> 01:31:33: ICMP type=8, code=0
> 01:31:33:
> 01:31:33: IP: s=192.168.1.100 (local), d=192.168.1.2 (Ethernet0), len 100,
> sendi
> ng
> 01:31:33: ICMP type=0, code=0
>
>
> Summary : from R1 i can ping to R3 translated
> from R3 i cant ping R1 translated
> R1 is in inside
> R3 is in outside
>
>
> -Mamoor
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:50 GMT-3