IP NAT inside source vs IP NAT outside source

Hi Rene

For NAT is it reuired for Router to have route for the NAtted IP

If i doing inside NAT 10.10.10.10 -> 20.20.20.20 on my R1 do my R1 required to have route for 20.20.20.20 ?

how will it handle the response traffic for 10.10.10.10 -> 20.20.20.2 , will it check rout table first or NAT first ?

Hello Devaprem

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 20.20.20.20 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 hope this has been helpful!

Laz

Thank you Laz , it clearly explains

1 Like

Does the same apply to “destination”?

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 155.1.58.55.

conf t

interface e1/1.45
shutdown
!
interface e1/1.58
ip nat outside
!
interface Tunnel0
ip nat inside
!
ip nat pool ROTARY prefix-length 24 type rotary
address 155.1.0.1 155.1.0.1
address 155.1.0.2 155.1.0.2
address 155.1.0.3 155.1.0.3
!
ip access-list extended LOAD_BALANCE
permit tcp any host 155.1.58.55 eq telnet
!
ip nat inside destination list LOAD_BALANCE pool ROTARY
!
ip alias 155.1.58.55 23

end

Hello Chris

If we look at the description of the ip nat inside source command and modify it to conform to the ip nat inside destination command, we can see the following:

ip nat inside destination will:

  • translate the destination IP address of packets that travel from inside to outside
  • translate the source IP address of packets that travel from outside to inside

This is not the inverse of the source command, but it simply changes the address upon which translation is applied, specifically, the destination and not the source address of the packets.

I hope this has been helpful!

Laz

Hi Laz

I guess I was referring more to the syntax of the command.

ip nat inside source static/list [specify inside IPs] [specify outside IPs]

ip nat inside dest static/list [specify outside ip] pool [specify inside IPs]

Do you see what I mean? It does seem to be reversed for the “destination” command.

Hello Chris

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.

I hope this has been helpful!

Laz

Having gained further experience with this, I believe this statement is not actually correct:

The ip nat inside destination is actually very similar to ip nat inside source, it doesn’t perform a different action.

ip nat inside destination will:

  • translate the destination IP address of packets that travel from OUTSIDE to INSIDE
  • translate the destination IP address of packets that travel from INSIDE to INSIDE
  • translate the source IP address of packets that travel from INSIDE to OUTSIDE

It is just used for packets travelling from outside to inside, or even inside to inside. A common use is using a “VIP” for load balancing to several inside IPs.

More explanation here: https://community.cisco.com/t5/switching/quot-ip-nat-inside-destination-quot-use-case/td-p/2800865

Hello Chris

Thanks for that post, and yes I stand corrected. The Cisco community post clarifies the distinction. This Cisco documentation also shows additional examples of its implementation.

Thanks again!

Laz

Thank you for the great article. I’ve also seen ip nat inside/outside on the interface level. Could you tell me the differences between this command compare to ip nat inside/outside source?

For example,

int s0/0
 ip address 10.1.1.1 255.255.255.0
 ip nat inside

int s0/1
 ip address 10.1.1.2 255.255.255.0
 ip nat outside

Hello Po

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.

I hope this has been helpful!

Laz

Hi Rene!
I have a question on these commands from the topology you used on the NAT lesson:

R1(config)#ip nat inside source static 192.168.1.1 192.168.2.200
R1(config)#R1(config)#ip nat outside source static 192.168.2.2 192.168.2.200

I do not know where the 192.168.2.200 host address is configured on your topology to better understand how the NAT works.

I checked configurations on H1, H2, and R1 and I do not see where that IP address is configured.
Thank you.

Hello Ayong

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.

I hope this has been helpful!

Laz

Ah! Thank you so much Laz. Well explained and well understood.

Hi,


I built a diagram like this to test outside static NAT. So I want VPC as outside PC on the top to access inside PC VPC10. Related configuration listed below:
Capture4

If I change my ip nat outside source static 22.22.22.25 22.22.22.100 to source static 22.22.22.25 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?

Thank you very much.

Hello Helen

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.

I hope this has been helpful!

Laz

Hi Laz,

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?

Hello Helen

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.

Just another use of the specific feature.

I hope this has been helpful!

Laz

1 Like

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

Hello Kevin

It looks like you will be needing the ip nat outside source command. Take a look at the following lesson which describes this feature in detail.

If you have further questions concerning your implementation, let us know!

Laz