If you have a NAT translation between two addresses configured on a router, you don’t require any of those addresses to have a routing table entry in that specific router. These addresses are considered directly connected because they are associated with specific interfaces. For this reason, you don’t have to explicitly configure them for routing. However, other routers on the outside must have some routing information to be able to reach the 22.214.171.124 IP address but this is independent of NAT.
In general, when a packet arrives on an interface from outside to inside, it will translate NAT first and then route. More information about the order of operations in routers can be found at the following Cisco documentation.
I have just done an INE task with the following line:
ip nat inside destination list LOAD_BALANCE pool ROTARY
But on this task, traffic arriving on the outside interface (not inside) is destination NATed to the pool on the inside, which seems to be inverse of the “source” command. There is also the IP ALIAS command but I believe this is just to respond to ARPs for 126.96.36.199.
ip nat outside
ip nat inside
ip nat pool ROTARY prefix-length 24 type rotary
address 188.8.131.52 184.108.40.206
address 220.127.116.11 18.104.22.168
address 22.214.171.124 126.96.36.199
ip access-list extended LOAD_BALANCE
permit tcp any host 188.8.131.52 eq telnet
ip nat inside destination list LOAD_BALANCE pool ROTARY
ip alias 184.108.40.206 23
When you input the following with the context sensitive help you get:
IP nat inside destination ?
list Specify access list describing global addresses
The global address is the inside global. This is the address that a host on the outside will see when communicating with the inside host. This means that it is the outside IP(s) that must be specified first.
The ip nat inside source and ip nat outside source commands and their keywords and parameters are used to translate particular IP address ranges from networks that we define as “inside” and “outside”. These commands are issued in global configuration mode.
The commands ip nat inside and ip nat outside that are applied on an interface level are used to simply define which interfaces (and their networks) are considered inside and which are considered outside, so that the NAT operation “knows” from which network to which network the translation should be applied.
The address 192.168.2.200 is the IP address used on the outside interface for communication with the inside host of 192.168.1.1. It doesn’t have to be configured in any other place to function for NAT translation. Take a look at the diagram of the lesson:
The “ip nat inside source static” NAT configuration will cause the Gi0/2 interface of R1 to receive and accept any packet with a destination address of 192.168.2.200, and will translate the address appropriately. The outside IP address for NAT does not have to be the same as the configured IP address on the outside interface. It can actually be anything. But, in order for it to work, the outside IP NAT address must be reachable, that is, routing to reach that particular address must be in place. For this reason, it is most often the case that the outside IP address in the NAT command be within the same subnet as the actual configured IP address. In this case, we have 192.168.2.200 which is within the 192.168.2.0/24 subnet that corresponds to the Gi0/2 interface of R1.
If I change my ip nat outside source static 220.127.116.11 18.104.22.168 to source static 22.214.171.124 10.1.15.100, then I won’t be able to ping VPC10. So my question is do I have to change the outside local IP to the same subset of the outside global? The second question is how does routing fit into the different scenarios, i.e. inside - outside vs outside - inside? From the documents i read, from inside - outside, routing happens before NAT while for outside to access inside, then NAT happens before routing. Would you please elaborate on that?
Short answer is “yes”. When you ping VPC10, you will find that the ping reaches the destination, but on the way back, it uses a destination IP address of 10.1.15.100. Based on the configured routing, this would be routed to R9’s 10.1.15.0/24 directly connected subnet, which will then simply be dropped, since no host on that subnet would respond to that destination IP. E0/2 is the outside NAT interface of R2, but because its subnet is different than that of the translated NAT address, the return packet will never come back in on the required outside interface, because it would be routed elsewhere, thus the return translation would not occur. For this reason, the outside local address should be on the same subnet as the IP address of the outside interface.
Remember that routing depends solely based on the destination IP address. In a typical NAT scenario, when an internal device communicates with a device on the outside, the destination address does not get translated, so the order of operations doesn’t affect routing.
For return traffic, from outside to in, it makes sense to have routing take place after the NAT translation. This is because the destination address of the packet before translation, is the outside local address, which actually resides on the outside interface itself. If routing were to take place first, it would have nowhere to send the packet, since the destination address is in essence, on the outside interface. So translation must take place before the packet can be routed to get to its eventual inside destination.
So in the real enterprise environment, if we use ip nat outside source command, we are just translating a public IP address (outside global) to a different public IP address (outside local) which share the same subnet, correct?
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 126.96.36.199 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 188.8.131.52 and then sent to the internet. Obviously to reply from pining the 192.168.1.12 address would come from 184.108.40.206