Yes, this is something that can be achieved, as was done in the lesson. There is no restriction to keep the translated address in the same subnet. In the case of the lesson, this had to be done because the device whose address is being translated is directly connected to the outside interface of R1. On the Internet, for example, you could translate to any other public IP address.
Another useful application would be to translate the IP address of say, an external web server, to an internal local address. This is what I mean:
Imagine you are H1 and you want to access the web server. But for some reason, H1 is not allowed to access any external hosts, say for security pruposes. You can create the following:
ip nat outside source static 204.123.123.55 192.168.1.55
This allows H1 to communicate with 192.168.1.55 on its own subnet. R1 will receive such packets, and translate and send them over the Internet to the web server. When they come back, they will be translated again, making H1 think that it is communicating with a device on its own subnet.
I have an ASAv on AWS. I need to be able to nat an internal ip to an external ip. In other words, from the local lan I would ping say 192.168.1.12 which would be translated to 8.8.8.8 and then sent to the internet. Obviously to reply from pining the 192.168.1.12 address would come from 8.8.8.8
The following commands are used to designate which interface is INSIDE and which is OUTSIDE as far as the NAT configuration is concerned. These are just used to define the inside and outside interfaces:
ip nat inside
ip nat outside
The ip nat inside source static command configures your most commonly applied NAT translations, where inside source addresses, say from your PC, are translated to outside (publicly routable) source addresses when communicating on the Internet. Responses from the internet (in the opposite direction) are then translated so that the outside destination address is translated to an inside destination address.
Now IP nat outside source static will do the opposite. That is, for any communication originating on the Internet, when the packet reaches the NAT router, the outside source address (of the initiator) is translated to an inside source address. Responses are translated accordingly, where the inside destination address is translated to the outside destination address.
This can be useful when you have an internal service on your network with an IP address of 10.1.1.1 for example, and it is configured to accept only communication from source IP addresses on the same subnet. By employing ip nat outside source static, a device on the outside can appear to have a source IP address on the same subnet, once NATtāed.
Thanks for the explanation Laz. What differences in behaviour would I expect to see if using .254 (the IP configured on the interface) instead of .200? Iāve done that and have noticed some differences in the ping results as well as debug ip nat output.
My topology is R1āNAT----ISP with the same IPs as per this lesson.
R1-NAT:192.168.1.1/24
NAT-R1: 192.168.1.254/24
NAT-ISP: 192.168.2.254/24
ISP-NAT: 192.168.2.2/24
When pinging from R1 to 192.168.2.254, the ping is successful but I donāt see anything in debug ip nat. Should this not be picked up in the inside to outside translation? When using .200 instead of .254 I see both outside-inside and inside-outside in the debug.
When pinging from R1 to 192.168.2.2 the ping is successful but I only see the NAT debug from the reply from ISP. See below. Should I not see a line in the debug for inside to outside translation as well. This behaviour is the same no matter if Iām using .254 or .200. Why isnāt the outgoing packet from R1 being natted?
When pinging from R2 to 192.168.1.1, the ping is unsuccessful. I see only the outside to inside part of the NAT translation. On R1 it looks like itās replying but there is no translation back from inside to outside. When using .200 instead of .254 I see both the outside-inside and inside-outside debug activity and donāt have any issues pinging.
This is normal behavior. When you ping the 192.168.2.254 address, the outside interface will receive this packet, and must decide what to do with it, based on the destination IP address, in the following manner:
It looks at the destination IP address. If it is its own, then the interface knows that it itself is the destination of the packet. It will not translate it using NAT, but will decapsulate it and process it. In your case, it will respond to the ping using itself as the source IP address, and it will use the routing table to find out the next hop to respond to the ping.
If the destination IP is not that of the interface, only then will it go to the next step of checking NAT translations. In the case of using .200, this is what happens. So in this case, you will see the NAT translations in the debug.
Hmm, thatās interesting. When using .200 you should see both translations, as shown in the lesson. However, when using .254, you will only see one translation. This once again is due to the NAT order of operations. Routing will take place before NAT translation. Since .254 is in the routing table as a directly connected route, no NATting will take place, but only routing. Can you check again the behavior when using .200 in your lab?
This once again has to do with NAT order of operations, and how they are different for inside-to-outside translations, and outside-to-inside translations. Take a look at the NAT order of operations document link above and see if you can figure this one out. If you have further questions, feel free to let us know!
Great tutorial and everything, really well and clear.
Just to avoid confusion/have these examples closer to real-world scenarios, can you input public IPās instead of private IPās where we would expect/see these?
You have a network with strict security policies. The hosts on the 192.168.1.0/24 network are not allowed to communicate with the Internet due to the highly sensitive nature of the information they manage. However, you want H1 to have access to a single web server S1 on the Internet without violating the policy of āinternal onlyā communication.
Using the ip nat outside source feature, you can assign an internal network address, such as 192.138.1.100 to that outside web server, allowing internal devices to reach it as if it was on the same subnet. Thus, from the point of view of H1 for example, the web server is on the same subnet, so no security policies have been violated.
The truth is that these scenarios are rare, but we do see them often enough so that the command can be useful. Also note that you can use public addresses in such a scenario, as you have seen from the above example.
