Cisco IOS NAT Translations

In today’s blog we will be looking at a common way to utilize NAT in order to accomplish a given task we might be asked to do in the lab.  Take a look at the below diagram to get an idea of the topology.

We are going to be hacking away at some very specific tasks.

1) From R5, we should be able to telnet to 10.10.10.10 and get to a login prompt on R2
2) From R5, we should be able to telnet to 10.10.10.10:80 and get a login prompt on R4
3) If we telnet to 10.10.10.10 port 23 or port 80 from R1, R2, or R4 we should not have this behavior

*NOTE* You may add 1 interface and 1 ip address for this task. You may not use static routes. EIGRP is configure on all routers

Clearly the task is looking for a NAT solution. The question is, how do we go about doing this?  The first thing we need to be thinking about is the address 10.10.10.10.  We don’t have it in our topology at all.  However, we are allowed to add in a single interface and a single IP address.  A loopback sounds good to me.

R1(config)#int lo10
R1(config-if)#ip add 10.10.10.10 255.255.255.255

The next thing we need to start thinking about is how we are going to accomplish this task with NAT, and how NAT works.  We have already setup EIGRP on all the routers here.  We are advertising the 10.10.10.10/32 into EIGRP as well.  Without the advertisement R5 would of course have no idea how to get to 10.10.10.10 in the first place.  So let’s get into the NAT configuration on R1

interface FastEthernet0/0
  ip nat outside
!
interface FastEthernet0/1.12
  ip nat inside
!
interface FastEthernet0/1.14
  ip nat inside
!
!
ip nat inside source static tcp 100.100.12.2 23 10.10.10.10 23 extendable
ip nat inside source static tcp 100.100.14.4 23 10.10.10.10 80 extendable

So what’s the logic behind this?  This is the logic that confused me for a long time.  I mean, if I want to translate things DESTINED for 10.10.10.10 you might think to use an outside destination based NAT rule right? The problem is, no such thing exists in IOS…at least on a router.

R1(config)#ip nat outside ?
source  Source address translation

However, what we have to realize is that when we setup a NAT translation, we are actually setting up a bi-directional rule. So, let’s break down the first NAT translation.  We have ip nat outside on our interface facing R5 and we have ip nat inside on the interfaces facing R2 and R4.  OK.  Now take a look at the rule.

ip nat inside source static tcp 100.100.12.2 23 10.10.10.10 23 extendable

So what we are saying here is actually a couple of different things.  First, if we see a packet on an interface marked as “ip nat inside” with a SOURCE ip address of 100.100.12.2 with a SOURCE port of TCP 23, translate that to a SOURCE ip address of 10.10.10.10 with a SOURCE port of 23.  Fair enough.

The other more subtle rule is the reverse!!! We are also saying at the same time if anything comes into an interface marked as “ip nat outside” with a DESTINATION address of 10.10.10.10 DESTINATION port 23 translate that to a DESTINATION address of 100.100.12.2 with a DESTINATION port of 23.  This logic is part of the NAT rule inherently.  The same logic goes for the second rule, except we are using port 80 instead.  So check it out…

Before we do anything…

R1(config)#do sh ip nat trans

Pro Inside global      Inside local       Outside local      Outside global
tcp 10.10.10.10:23     100.100.12.2:23    ---                ---
tcp 10.10.10.10:80     100.100.14.4:23    ---                ---

At this point we only see the inside global and inside local for each rule.  Since we have not translated anything yet, we don’t see anything on the outside side.  Inside global means “what is the address of my inside interface as viewed by the outside (global) domain?”  Inside local says “what is the address of my inside interface as viewed by the inside “local” domain?”  Outside local says “what is the address of my outside interface as viewed from the inside domain?” and finally Outside global says “what is the address of my outside interface as viewed by the outside (global) domain?”  Let’s get some telnet going from R5 to test…Note I have already setup a username of cisco password cisco on R2 and R4 and set the vty lines to login local. To see whats going on here, we will turn on debug ip nat on R1 as well

R1(config)#do debug ip nat
IP NAT debugging is on
R5>telnet 10.10.10.10

Trying 10.10.10.10 ... Open

User Access Verification

Username: cisco
Password:

R2>

Awesome! Our first test worked as planned.  On R1 we see the following part of the debug…

R1#

*Jul 22 08:41:45.307: NAT*: s=100.100.15.5, d=10.10.10.10->100.100.12.2 [43266]
*Jul 22 08:41:45.307: NAT*: s=100.100.12.2->10.10.10.10, d=100.100.15.5 [63913]

What we see here is that a packet came in sourced from 100.100.15.5 (R5 fa0/0) destined to 10.10.10.10.  Our router then translated the DESTINATION address to 100.100.12.2 (R2 Fa0/0).  On the way back, R2 sent data back to R5 sourced from 100.100.12.2 and destined to 100.100.15.5.  Because this matched the NAT rule, we translated the SOURCE address to 10.10.10.10. Let’s test our connection to R4 now.

R5>telnet 10.10.10.10 80

Trying 10.10.10.10, 80 ... Open

User Access Verification

Username: cisco
Password:

R4>

Beautiful!!!  Telnetting to 10.10.10.10 on port 80 fired us right over to R4 port 23 as expected.  And the debug from R1 shows…(drumroll please)

*Jul 22 08:48:56.175: NAT*: TCP s=38201, d=80->23
*Jul 22 08:48:56.175: NAT*: s=100.100.15.5, d=10.10.10.10->100.100.14.4 [38939]
*Jul 22 08:48:56.179: NAT*: TCP s=23->80, d=38201
*Jul 22 08:48:56.179: NAT*: s=100.100.14.4->10.10.10.10, d=100.100.15.5 [59816]

Here we see that as the packet came in to R1 from R5 it had a source TCP port of 38201 (telnet sources things from random TCP ports > 1024 typically) and a destination port of 80.  Our NAT rule translated the destination TCP port to 23.  Furthermore, we translated the destination address of 10.10.10.10 to 100.100.14.4.  Coming back the other way from R4 we see the destination port number was translated from 80 back to 38201 and the destination address was translated from 10.10.10.10 back to 100.100.15.5.

That’s it for this blog.  Until next time, keep studying hard and you will meet your goal!!!

Joe Astorino – CCIE #24347

5 Comments

  • Neil O'Brien says:

    Nice explanation Joe, the logic of NAT and terminology gets me every time.

    Looking forward to more of the same,
    Neil

  • John says:

    “source” is kind of misleading and exists due to a corner case of nat by which you load balance the translation in the inside domain via a rotary group. This is what the ‘destination’ option is for with ‘ip nat inside’. Without that case, the command could have been just ‘ip nat inside .

    When thinking about NAT, don’t get caught up in who’s the “source” or “destination”. What you need to remember is that if you’re ‘ip nat inside’-ing then you’re changing the flow’s source/destination of whatever is in the “inside” nat domain, regardless of where the flow is initiated from. Think of it like search and replace. The first IP argument is the string you want to match on and the second is what to replace it with. The same applies to the use of ‘ip nat outside’

    One important point to make is that NAT is applied in different orders based on whether you’re using outside or inside. INE has a GREAT article on the matter: The Inside and Outside of NAT

  • alef says:

    Hi Joe,
    Could you not just setup a ip nat outside source rule on R5 (or R1) to achieve the same thing ?

    ip nat outside source 100.100.15.5 10.10.10. etc
    Alef

    • Joe Astorino says:

      Good question. Now, I will ask you one in return : ) If you used “ip nat outside source” on R5, how would you differentiate the flows to determine if you wanted packets to go to R2 or R4?

      For example, the task says packets going to 10.10.10.10:23 should end up on R2 but packets going to 10.10.10.10:80 should end up on R4. If you use outside nat on R5, you would be looking to change the source address/port. The problem is that regardless if I want to end up on R2 or R4 the source IP address is going to be the same and the source port number will be dynamic and above 1024.

      I encourage you to lab it up, but I don’t believe you can accomplish the task with outside NAT here given the requirements.

  • Paulson says:

    I struggled a lot with NAT. Cisco complicated it with inside/outside local/global. Your article helped me to understand it well. Thanks a lot

Leave a Reply