Hello Nguyen
For IOS 15.x you can’t solve the problem created in this particular situation using legacy NAT because of the host routes created in the routing table. The solution is to use the NAT virtual interface, which is the “new” way of implementation.
I hope this has been helpful!
Laz
Hello.
For the translations, I am unclear on the scenario:
For R1 Pinging 192.168.23.3:
At R1 Source:192.168.12.1 Destination:192.168.23.3
At R2 Source:192.168.23.1 (NAT) Destination:192.168.23.1
At R3 Reply with Source: 192.168.23.3 Destination 192.168.23.1
!! At R2 Source 192.168.23.3 Destination 192.168.12.1 (NAT)
(It seems there is only one NAT)
For R1 Pinging 192.168.12.3 (with “add-route”)
At R1 Source:192.168.12.1 Destination:192.168.12.3
At R2 Source: 192.168.23.1 (NAT) Destination:192.168.23.3 (NAT)
At R3 Reply Source:192.168.23.3 Destination:192.168.23.1
At R2 Source:192.168.12.3 (NAT) Destination: 192.168.12.1 (NAT)
(There are 2 NAT involved)
It seems to me for
Inside Source command:
the NAT router will “listen” at the outside interface for the translated IP
the NAT router will translate Source IP for every packet originating from inside
the NAT router will translate Destination IP for every packet originating from outside
Outside Source command
the NAT router will “listen” at the inside interface for the translated IP
the NAT router will translate Source IP for every packet originating from outside
the NAT router will translate Destination IP for every packet originating from inside
However, I am wondering why for the 1st example (marked with !!), why R2 won’t also translate 192.168.23.3 to 192.168.12.3?
I am quite new to the networking scene so I hope this question is not a stupid one, many thanks for your help in advance! 
Hello Matthew
If what you are describing here are the same results as those seen in the debugs of the lesson, then the reason why we don’t see a translation on the return trip of the ping is because at this point in the lesson, only the ip nat inside source static command is issued. So NAT will only take place for traffic going from inside to outside. Return traffic (outside to inside) remains untranslated.
Only once the ip nat outside source static command (along with the add-route keyword) is added will there be translation in the opposite direction. Does that make sense?
As for the rest of your descriptions, they look good. Only one small typo, in your description of the first case, you state:
where it should read
At R2 Source:192.168.23.1 (NAT) Destination:192.168.23.3
I hope this has been helpful!
Laz
Hello Laz,
Many thanks for your reply. However, when I lab it up at Packet Tracer or EVE-NG, it seems odd because even if I add “inside source” and “outside source”, there is still no “Double NAT translation” for my ping:
I have:
ip nat inside source static 192.168.12.1 192.168.23.1
ip nat outside source static 192.168.23.3 192.168.12.3
For Example:
For R1 Pinging 192.168.23.3
At R2
seems normal as the:
ip nat inside source static 192.168.12.1 192.168.23.1
kicked in for the translation of source IP
However, when R3 reply again goes through R2, it became:
I was thinking how come it doesn’t translate the source IP as well? Shouldn’t
ip nat outside source static 192.168.23.3 192.168.12.3
also kick in to translate the source IP at the outside interface?
----
I can not get my head around the scenario of having ‘inside source’ and ‘outside source’ both effective and in what scenario will have 4 NAT translations, and when will there be only 2 translations.
Many thanks for your help in advance!
Matthew
Hello Matthew
Because you pinged 192.168.23.1, which is the IP address on the Gi0/1 interface of R3, only the “inside” NAT translation took place. On the return trip, this is an established session, so the translation will take place accordingly. If the “outside” NAT translation kicked in, then R1 would receive a reply from 192.168.12.3, which is not the IP address from which it expects a response. If you originally pinged 192.168.12.3, then the return traffic would be translated on its way in as well.
Even so, I did try labbing this up in packet tracer and found that you cannot actually perform that part of the lab there because the add-route keyword is unavailable.
I hope this has been helpful!
Laz
I have the following doubt about this excerpt :
"Above we see that R2 receives the IP packet from 192.168.23.3 destined to 192.168.23.1. Since this IP packet is received on the outside interface, we do NAT first and routing second. You can see that source address 192.168.23.3 is translated to 192.168.12.3.
When pinging 192.168.23.1 from R3 , R2 will receive the icmp paquete from outside to inside, so NAT is performed first for the SRC ADD (applying the "ip nat outside static source 192.168.23.3 to 192.168.12.3) but also will NAT the DST ADD from 192.168.23.1 to 192.168.12.1 so the packet before routing will be SRC 192.168.12.3 DST 192.168.12.1 and now R2 will the the FiB check for DST ADD and forward that packet towards R1 192.168.12.1 . R1 will reply the icmp to the 192.168.12.3 towards R2 but now because the NAT is from inside to outside, routing is performed before nat, so R2 will receive this icmp reply in behalf R3 192.168.23.3 .
Is that statement right ? adding the “add-route” keyword is a kind of proxy ?
Hello Juan
Yes, you description is correct. In the process of pinging 192.168.23.1 from R3, both the source and the destination IP addresses are NAT’ed. However, remember that it is always the destination address that is involved in the routing process. The translation of the source address does not affect the routing process.
So since NAT translation takes place first, the destination becomes 192.168.12.1 so the ping reaches R1. R1 responds to the echo request with an echo reply destined for 192.168.12.3. At R2, routing takes place first and because the destination network hangs off of Gi0/1, it never gets NAT translated. So your statement is correct.
The add-route parameter on the NAT command essentially adds a static route for the outside local address, thus resolving the issue.
I hope this has been helpful!
Laz
