Introduction to Cisco NAT

I have recently been teaching Cisco Networking Academy classes at a local college.  One topic my students seem to struggle with is NAT and PAT.  To help them, I wrote up a “Introduction to NAT” document for them.  I decided to post this up for the world to find as well.

Keep in mind, the audience here is beginners so please, all you security experts keep that in mind before slamming this post for being not thorough enough : )

Introduction to NAT

In networking, it is common to have a network or networks connected to both an inside “private” network and an outside “public” network, such as the internet.  On the inside private side of the network, we typically use private IP address space as defined in RFC1918

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

This is done for a few main different reasons.

  • Depletion of the public IPv4 address space (Not enough IPv4 addresses to assign to all devices)
  • Hiding the real IP address from outside networks / security reasons

By definition, RFC1918 private IP addresses can never be routed on the public internet.  If we use private IP addressing inside our private enterprise networks, but we also want those devices to have access to the internet, and the IP addresses of those devices can’t be routed on the internet, that presents a problem.  The fact that we can’t assign everything its own public IP address (there aren’t enough) is another problem.  NAT helps us solve both these problems. Additionally, it can be used in advanced situations to solve complex network issues involving IP address overlap.  NAT is a term that gets sort of thrown around as a very general term, but in reality there are many different “flavors”.  My goal is to discuss  and help explain all those flavors.  We will cover

  • Static NAT
  • Dynamic NAT
  • Dynamic PAT
  • Static PAT

The inside and outside of NAT

When discussing NAT in IOS, there is always an “inside” interface and an “outside” interface.  We define these on the interface with the ip nat inside or ip nat outside commands. Generally speaking, the real IP address of devices on the inside of the network are translated to mapped IP addresses on the outside of the network. Cisco uses various terms to describe the inside host being translated and the outside host it is communicating with.

Inside Local – Device on the inside network as viewed by the inside network. This is the actual real IP address assigned to the device

Inside Global – Device on the inside network as viewed by the outside network. This is the mapped IP address the device on the inside is being NAT’d to on the outside of the network

Outside Local – Device on the outside network as viewed by the inside network. This is often the real IP address of the device on the outside internet the device on the inside is communicating with

Outside Global – Device on the outside network as viewed by the outside network. This is always the real IP address of the device on the outside, and is often the same as the outside local address.  There are advanced situations where the outside local and outside global could be different things.

Consider the following simple example:

nat

 

Here we have a host on the inside network, 10.10.10.100 that wants to communicate with a web server on the public internet at 112.10.10.32.  To do that, when the router receives the packet from 10.10.10.100 destined to 112.10.10.32, it has to translate the source IP address to a public address.  Let’s say we will translate 10.10.10.100 to the public address 12.3.4.100.  In that case we would have

Inside Local: 10.10.10.100

Inside Global: 12.3.4.100

Outside Local: 112.10.10.32

Outside Global: 112.10.10.32

Static NAT

Static NAT is a way to make a 1 to 1 mapping between a real IP address on the inside of our network and a mapped IP on the outside of the network. Static NAT works bidirectionally, meaning the inside host can initiate communication outbound, or hosts on the outside network can initiate a connection inbound to the mapped IP address.  This is typically done for things like servers that are on the inside of the network, but that we want accessible from a public network like the public internet. We will use the same diagram as before to describe static NAT.  Say the machine 10.10.10.100 on the inside network is a server we want to be publically accessible from the internet.  Anytime 10.10.10.100 sends something to the internet, we want the source IP address changed to 12.3.4.100.  Conversely, anytime something on the internet sends something to 12.3.4.100, we want the destination changed back to 10.10.10.100.  We don’t care about the protocol or port at this point.  All we care about is that when 10.10.10.100 sends something to the internet, it is mapped to 12.3.4.100 and when something on the internet sends data to 12.3.4.100, the destination is mapped to 10.10.10.100.  Static NAT would accomplish this.

Static NAT Configuration

Static NAT is relatively simple to configure in IOS.  Let’s go with the same example here where we want 10.10.10.100 on the inside network translated to 12.3.4.100 on the outside network.  We do:

interface FastEthernet0/0
 description inside interface
 ip nat inside
!
interface FastEthernet0/1
 Description Internet facing interface
 ip nat outside
!
ip nat inside source static 10.10.10.100 12.3.4.100

Note that static NATs are ALWAYS in the NAT table.  By their nature, they never “time out” or go away unless you remove the static NAT configuration.  That means you always see static NATs in the output of show ip nat translation

 Let’s look over the logic of the ip nat command above here for static NAT.  The logic of this command says two different things: First, it says “if packets from 10.10.10.100 enter the inside interface, and those packets are routed out the outside interface, translate the source IP to 12.3.4.100.”  That way when the server on the outside internet receives the packet, it is sourced from 12.3.4.100, and that is the IP the remote server responds to.  Secondly, it also says “If packets arrive on the outside interface destined to 12.3.4.100, translate the destination back to 10.10.10.100”  When you configure the static NAT, this information is essentially added to a table that the router can later consult to help it make the right forwarding decisions

Dynamic NAT

Take our little example network now, and imagine that instead of just the one host, 10.10.10.100 on the inside, we have 10 hosts, call them 10.10.10.100 – 10.10.10.110, and they all need access to the internet. They are all just user workstations, so they don’t necessarily need to be reached from the public internet, just be able to initiate a connection outbound.  Let’s also say that we purchased a /28 from our service provider, so we have 14 public IP addresses to use.  We could configure 10 different static NAT’s here… 10.10.10.100 mapped to 12.3.4.100, 10.10.10.102 mapped to 12.3.4.101 ..etc but that is a lot of work.  Also, remember static NAT is bi-directional.  If we did all static NAT’s not only could the inside hosts initiate to the outside internet, but anybody on the outside internet that communicated with the mapped 12.3.4.x public addresses would be mapped right to the inside network.  Like I said, that is great for servers but not necessarily hosts.  This is where dynamic NAT comes into play

Dynamic NAT is a “many to many” type of NAT.  The idea is we take a whole RANGE of hosts on the inside network, and we map them dynamically on an as needed basis to a public IP address in a pool of public IP addresses we setup.  When the user on the inside needs to access the internet, he gets translated dynamically to a public address from the pool.  When the second user accesses the internet, he is dynamically NAT’d to another address in the pool, and so on.  The neat thing with dynamic NAT is that the NAT entries only get added to the NAT table as needed.  After a certain amount of time, the dynamic translation times out, and the public IP they were using goes back into the pool.  Dynamic NAT is also a unidirectional type of NAT.  What I mean by that is that the inside user can initiate a connection to the outside, but something on the internet cannot initiate a connection to that user.  Why?  Because the translation from the private to public IP address is triggered by the inside user.  As I explained above, when the inside host initiates the connection to the outside, its address is changed to a public address from the pool.  At that moment in time, the router allocates the address.  Think about it the other way around though.  Say something on the internet initiates a connection to 12.3.4.100 out of nowhere.  When that packet gets to the router here, the router does not have any record whatsoever of 12.3.4.100 in its NAT table.  What this means in short is that when we use dynamic NAT, only the inside user can initiate. One major downside to dynamic NAT is that everything is still 1-1.  We can translate a bunch of internal IP addresses to a bunch of outside IP addresses, but it still means we can only have as many concurrent connections / translations as we do public IP addresses.  So back to our example…the day we get host #15 on the network we may have problems.  If all 15 people wish to access the internet at the same time, we can’t accommodate that with dynamic NAT.  The first 14 people to use the connection would each be dynamically NAT’d to a public address, but when the 15th person tries, there are no more addresses in the public pool to grab.  It might work on and off if everybody is not using it at the same time, but it is not a scalable solution to that problem.  Because of limitations like that, you don’t often see straight up dynamic NAT used for internet purposes much.  It is typically used today more as a security mechanism where you might “hide” an entire private inside network from the final destination

Dynamic NAT configuration

With dynamic NAT, we still configure our interfaces as either inside or outside.  Additionally, we write an ACL that defines the source traffic we wish to dynamically NAT, and we configure a pool of public IP addresses to NAT those sources to.

interface FastEthernet0/0
 description inside interface
 ip nat inside
!
interface FastEthernet0/1
 Description Internet facing interface
 ip nat outside
!
access-list 100 permit ip 10.10.10.0 0.0.0.255 any
ip nat pool MYPOOL 12.3.4.97 12.3.4.111 netmask 255.255.255.240
ip nat inside source list 100 pool MYPOOL

The ACL 100 here defines the sources we want to NAT on the inside network… 10.10.10.0/24. Then we define a pool of public IP addresses called MYPOOL.  Finally, we tie everything together with the final command.  This says “If a packet arrives on the inside interface sourced from 10.10.10.x and we route it out to the internet, change the source IP address to a free one in the pool MYPOOL and add the information to the NAT table dynamically.”  Now, when the return traffic comes back from the remote destination to the router destined to 12.3.4.x, the router consults it’s NAT table.  It sees the dynamic entry that mapped 10.10.10.x to 12.3.4.x and knows how to translate the destination back to the private IP.

Dynamic PAT

Let’s keep rolling with our example, but shift the scene a little bit.  Say the diagram is now depicting your house.  You have a route connected to Comcast, and Comcast gives your WAN side interface a single public IP address.  However, on your inside network you have 2 desktop computers, 2 iPad’s, 2 iPhones, a PS3, an XBOX , etc … i.e. you have MANY inside devices that want internet access, but you only have ONE public IP address.  Enter dynamic PAT.  Before we talk about how dynamic PAT works, think about what would happen just based on what we have covered so far. Consider that we configure dynamic NAT, but the pool we configure only has a single IP address J  … Now device #1, say 10.10.10.100 tries to access the internet.  The router gives it the one and only public IP in the pool, say 12.3.4.254, the IP assigned to our Comcast facing interface.  It adds the translation dynamically to the table and sends the packet along its way.  Now, device #2 on the inside, say 10.10.10.101 wants access to the internet. The packet gets to the router, and the router has no more public address to assign…the only one we had is already in use.  Epic fail. If our inside devices had a way to “tag” their packets with some sort of unique identifier that the router could remember…then we could use that “tag” to uniquely identify different flows.  Bear with me.  Say host 1 sends the data with a tag of “red” and gets translated to the one public IP 12.3.4.254.  host 2 sends their data with a tag of “green” and also gets translated to the one public IP.  Now, data coming back to both host 1 and host 2 will be destined to 12.3.4.254, but as long as the data that is for host 1 still has the “red” tag, and the data going back to host 2 still has the “green” tag, the router would be able to figure things out.  That is basically what dynamic PAT does, but instead of “tags” we use the TCP or UDP port numbers to do our bidding.  This allows us to have many inside IP addresses map to a single public IP (many to one) dynamically.  The translation is still dynamic, just like dynamic NAT.  This means only the inside user can initiate a connection.  The return flow will be allowed back based on that dynamic NAT table entry, but something on the outside will not be able to just initiate a flow to the inside device.

Let’s look at an example, and map out how dynamic PAT works.  Host 1 at 10.10.10.100 wants to talk HTTP to www.astorinonetworks.com which resolves to the public IP of 192.185.16.166. We know that HTTP utilizes TCP at layer 4 for transport. Here is what happens – 10.10.10.100 initiates a connection to 192.185.16.166.  The source TCP port will be completely random and > 1024.  We will call it port 49150.  The destination TCP port will be 80 (http).  The flow looks like this:

10.10.10.100:49150 –> 192.185.16.166:80

Now, the router gets this packet and does a dynamic NAT to the single public IP we have.  But THIS time, when it writes the information in the NAT table, it adds in the TCP port information as our sort of “ID tag”, and it sends the packet off to internet land towards 192.185.16.166.  When the packet leaves our router it looks like this: 12.3.4.254:49150 –> 192.185.16.166:80.  The NAT table now looks like this:

Inside Local         Inside Global        Outside Local        Outside Global

10.10.10.100:49150   12.3.4.254:49150     192.185.16.166:80    192.185.16.166:80

Notice that the PORT information is now included.  Before we look at the return traffic, consider now that host 2 at 10.10.10.101 fires up a connection off to google’s DNS server at 8.8.8.8.  The flow looks like 10.10.10.101:52111 –> 8.8.8.8:53. The source port there, 52111 was randomly chosen by the client. UDP 53 is the destination because that is the port DNS uses on the server. The router receives the packet, does another dynamic NAT, changing 10.10.10.101 to the SAME single public IP we had before, 12.3.4.254.  However, it ALSO adds the UDP port information to the NAT table. Now the NAT table looks like this

Inside Local         Inside Global        Outside Local        Outside Global

10.10.10.100:49150   12.3.4.254:49150     192.185.16.166:80    192.185.16.166:80
10.10.10.101:52111   12.3.4.254:52111     8.8.8.8:53           8.8.8.8:53

 

Now, here is where things all start to fit together.  Consider the return packets.  www.astorinonetworks.com has received our packet, so it sends a reply back to 12.2.3.254.  The flow looks like this – 192.185.16.166:80 –> 12.3.4.254:49150.  Google’s DNS has also received the packet from host 2 and sends a reply.  That flow looks like this: 8.8.8.8:53 –> 12.2.3.254:52111.  Now the router has 2 packets destined to the same public IP address (12.2.3.254) and has to figure out how to deal with those.  How does it know which packet goes to host 1 and which goes to host 2?  It knows this based on the port numbers.  It sees the packet to 12.3.4.254:49150 and looks it up in the NAT table.  The NAT table reveals that should map back to 10.10.10.100:49150 so that is exactly what the router does. It translates the destination IP address back to 10.10.10.100 and sends the packet to host 1.  It sees the packet to 12.3.4.254:52111 and sees a mapping in the NAT table as well.  It translates the destination back to 10.10.10.101 and forwards the packet to host 2. Because there are 65,536 port numbers for both UDP and TCP it means we could potentially support over 130,000 different unique flows from the inside to the outside with a single public IP address.  Dynamic PAT is a serious reason why IPv4 on the internet has lasted as long as it has with so few available public addresses.  Many large organizations will map all their inside network users to just a single or a few public IP addresses.

 

Dynamic PAT configuration

The good news is that dynamic PAT is configured basically the same as dynamic NAT but with an extra keyword, “overload”.  Note that dynamic PAT is also referred to as NAT overload

interface FastEthernet0/0
 description inside interface
 ip nat inside
!
interface FastEthernet0/1
 Description Internet facing interface
 ip nat outside
!
access-list 100 permit ip 10.10.10.0 0.0.0.255 any
ip nat inside source list 100 interface fa0/1 overload

So, what changed? Well, we didn’t define a pool for starters because we don’t need one.  We only have a single public IP remember?  So again, we define what is inside and what is outside.  Then, we still have our ACL identifying the sources.  Then the NAT command there is saying “if packets come into the inside interface sourced from 10.10.10.x, translate them to the public IP address assigned to fa0/1 (the WAN interface).  Also, please track the port information so we know what to do with the return packets!” The overload keyword here is vitally important.  The overload keyword is what turns on the PAT capability.

Now, technically instead of saying “interface fa0/1” in the nat command, we could have defined a pool, and referenced the pool instead.  Like this: ip nat inside source list 100 pool MYPOOL overload.  That pool could have 1 address or it could have 100 addresses…whatever we want.  If it had more than 1 address, the router would PAT all connections out the first IP until it HAD to go to the next one because all the ports used for PAT were full or unavailable.  That would be a very rare case.

 Static PAT

Static PAT is a lot like Static NAT, but it also takes into account port information.  It is a 1-1 mapping of an IP and port on the inside to a particular IP and port on the outside.  It also called “port forwarding”, and it is good for when you want a server on the inside network accessible from the outside public internet, but ONLY on a certain port number.  For example, say you run a little FTP server inside your house that you want to give your buddies access to from the internet.  Say it is 10.10.10.200.  At the same time, we still have our 5 or 6 other devices in our house that just want internet access.  So, for the internet access we are doing dynamic PAT as discussed above.  That makes sure all the devices, including the FTP server can initiate outbound flows to the internet.  However, it doesn’t solve our problem of wanting to give our buddies access to the FTP server.  Remember, our dynamic PAT only allows the inside host to initiate.  If we had more than a single public IP address to work with, we could just static NAT the FTP server 10.10.10.200 to another public address, but we don’t have that luxury here.  Additionally, static NAT maps ALL ports and protocols…doesn’t matter because it works at the IP layer and doesn’t care about ports.  We want JUST FTP connections coming from the internet to be forwarded to the FTP server on the inside.    Static PAT would essentially say “If we receive packets from the internet to 12.2.3.254 (our one public IP) on TCP port 21, change the destination to 10.10.10.200 (the FTP server) on TCP port 21.  Conversely, if we receive data from 10.10.10.200 source from port 21, change the source to 12.2.3.254 before sending it to the public internet.  The port mapping does not have to use the same numbers.  For example, we could say “if we get traffic to 12.2.3.254 port 43122, forward it to 10.10.10.200 port 21.” So, when your buddy points his FTP client to 12.2.3.254 port 43122 he is in reality talking to 10.10.10.200 on port 21 (FTP).

Static PAT configuration

Let’s roll with the second example there.  In IOS, it would look like this:

interface FastEthernet0/0
 description inside interface
 ip nat inside
!
interface FastEthernet0/1
 Description Internet facing interface
 ip nat outside
!
ip nat inside source static tcp 10.10.10.200 21 12.3.4.254 43122

Very similar to static NAT, except not surprisingly we are including port information.  So the NAT command here in English says “If we get TCP packets from 10.10.10.200:21 on the inside interface, change the source IP address to 12.3.4.254 and change the source TCP port to 43122 before sending it out to the internet.”  At the same time it ALSO says “If we receive TCP packets on the outside interface destined to 12.3.4.254:43122, change the destination IP address to 10.10.10.200 and the destination TCP port to 21.”

I hope this paper has helped you in your understanding of NAT/PAT!

10 Comments

  • alexis says:

    very nice article, simple and clear explanation

    thanks big help

  • Joe says:

    NUBE question. I’m working with a 1:1 NAT system on a cisco platform. How can I configure the NAT assignment rules so that when a public IP address from the NAT pool is released back to the NAT pool, that particular recently released IP address is NOT the first one that is assigned by the NAT algorithm to the next NAT request? Rotating through the pool would be fine, or a pseudo-random assignment would be fine, but I just can’t have the most recently used public IP addresses be the first ones in line for new NAT assignments. Can you point me to where I can learn what this randomization or rotation process would be called in industry jargon? Or can you let me know how to ask cisco or another vendor for the behavior that I am looking for? If the answer is as simple as “turn on feature xxxxx”, then could you let me know?

    The private IP addresses on the inside of my LAN are assigned when a device accesses the network and the TTL fo the private IP is simply the duration of his connection. So the local IPs could be being used and release on teh order of 15 seconds or alive for 5 days at a time. The public IP, assigned via 1:1 NAT is dynamically assigned whenever a packet hits the router, destined for the internet. The TTL of the public IP (from the NAT pool) is simply until the device either disconnects from the LAN or till there is no internet traffic from that local IP for a defined timeout period. I need the assignment of public IP addresses to be constantly moving across the available public IP address NAT pool. In other words, if a public IP NAT-pool address has been used for internet traffic by a device and later gets returned to the pool, I don’t want that public address to be the next one that is used by the NAT assignment algorithm. For example, if user_1 connects to the LAN, sends stuff to the internet and disconnects from the LAN, there may be some traffic that is sent back to user_1 from the internet AFTER user_1 has already disconnected. I want that traffic to get lost in a black hole. However, if the public IP has already been re-assigned to user_2, who happens to have the same local IP as user_1 had been using, then the user_2 will get traffic that isn’t intended for him. This is at least an annoyance, but can create other problems or be a security risk..

    • Joe Astorino says:

      Hi Joe,

      In short, I do not know of any way to select the algorithm used. However, I also do not believe your concern is valid. User 1 connects to the internet, is dynamically NAT’d to public IP 1 then disconnects. After a fixed timeout, the dynamic NAT translation is flushed from the NAT table. Now, say user 2 connects and is again dynamically NATd to public IP 1. The NAT table entry that is dynamically entered into the table is connection specific. The inside local, inside global, outside local and outside global will be noted per flow. At this point if the outside server user 1 was talking to is still talking back to public IP 1 it will not match anything in the current translation table. The only potential problem I see is if user 1 and user 2 were talking to the exact same outside server…but even then, if it is TCP traffic it wouldnt work out anyway. Also, any kind of stateful firewall worth anything would not allow it

      • Joe says:

        Thanks for responding so quickly. I guess i need to re-read your original post and come to a better understanding of the whole 1:1 NAT process. I thought the inbound routing was based on IPs only. if user_2 has exactly the same private_LAN_IP which is NAT-ed to the exact same public IP as user_1 had been using 30 seconds earlier, it seemed that any “leftover” TCP retries or other responses from one of user_1’s communication sessions would end up getting routed to user_2, because the incoming packet would have a valid correlation of public_IP and private_LAN_IP.

        I thought that the router would interpret any leftover incoming traffic from user_1’s session as simply unsolicited traffic destined for user_2 since the NAT translation would be an exact match with the user_2 session. What other aspects of the packet content (or traffic, etc) would trigger the router to NOT deliver the packets to user_2? Is the answer in the term “connection specific” such that user_1 and user_2 would have different “connection IDs” even if the IP translations for the two sessions matched? But when the router flushed the user_1 NAT entry and established the user_2 NAT entry, the NAT table would contain the same pair of IPs along with the user_2’s connection ID, and no record of what the user_1 entry had been. Do incoming packets sometimes have more routing info than just the public IP such as, e.g., destination private IP or connection session ID?

        • Joe Astorino says:

          One assumption here is that user 1 and user 2 are not to going to have the same internal private IP address. There would be no reason to do that, and if you did have two devices on the same network with the same IP at the same time you would have much more serious issues.

          Now, having established user 1 and 2 have different real ip addresses on the inside network, also consider this – the default timeout for dynamic NAT in IOS is 24 hours. So, once user 1 is dynamically translated to public IP 1, it is locked in until there is no traffic for 24 hours by default and user 2 could not be dynamically assigned to that same IP. User 1 could talk to outside server 1 and immediately disconnect, but that dynamic NAT entry that is specific for the user 1 to server 1 flow is going to be there for 24 hours unless you change the timeout value or delete the translation manually. Technically, any time server 1 sends any traffic back to public ip 1 within 24 hours, it is going to be NATd back to user 1’s IP. If your NAT device is also acting as a stateful firewall, return traffic would be allowed, but unsolicited traffic would just be dropped anyway.

          From a NAT perspective, it is technically feasible that the user 1 to server 1 dynamic NAT entry times out after 24 hours, user 2 then initiates to the SAME outside server, thereby creating a new dynamic NAT entry, and then the outside server just starts sending unsolicited traffic it thinks is destined for the original user , user 1, or even return traffic…but even then, no stateful firewall would allow it. From a layer 4 firewall perspective, it would not be allowed. Also, let’s say for sake of argument it was allowed because you are doing NO firewalling at all. If this is TCP traffic, it is going to fail anyway because you will have sequence numbers and such all out of order.

          Now, if user 1 and user 2 both have the same internal IP, but say were never on at the same time, I suppose you could in theory have some sort of perfect storm where…

          – user 1 is dynamically NAT to public ip 1 while talking to server 1. The dynamic translation is good for 24 hours
          – user 1 shuts down sometime before the 24 hour timeout expires
          – user 2 comes on and uses the same internal ip user 1 had previously
          – server 1 sends some unsolicited traffic or reply traffic back to what it thinks is user 1, but what is actually now user2

          – You have NO stateful firewall capability in place so it allows the traffic

          As you can see though, that is insanely unlikely event.

          Routing BTW for all practical purposes is based on destination IP address alone, with rare advanced situation exceptions

          HTH

          • Joe says:

            Thank you. Your comments have really helped me to better understand and describe the situation.

            Also, your article is exceptionally well written. It is very clear an deasy to understand, and I will definitely refer people to your site.

            With respect to my question …
            Yes, I’ve probably got a more “perfect storm” than you depicted.

            1. Modem Pool
            i) hosts use PPP to connect to a pool of modems
            ii) modems are assigned on first-available basis
            ==> not on a round-robin basis or random basis
            2. Local IP address assignment:
            There is a static 1:1 correlation between the modem pool and the Local IP addresses that are used for sessions:
            ==> Modem 1 always gets x.y.z.101
            ==> Modem 2 always gets x.y.z.102, etc.
            i) Local IP is assigned based on the modem being used.
            ii) Basically, the lowest available IP in the local IP pool
            3. Local IP de-assignment
            i) Local IP released when modem connection is terminated
            ==> Could happen in 20 seconds. Could be 5 days.
            4. NAT assignment
            i) NAT entry creation:
            ==> Created when local host (Host_1) sends traffic to internet
            AND no entry for Local IP currently exists
            ====> could be because this is the first traffic
            OR the NAT entry was flushed (no activity for 60s)
            ii) NAT entry is created using first available (lowest) public IP
            5. Rules for flushing NAT table entry:
            a) Time-based Flush ==> hasn’t been implemented in this router
            ==> The current rules never flush an entry based purely on time
            b) Activity-based Flush: Flush based on lack of activity for 60s:
            1) Timeout is 60 seconds of no inbound or outbound traffic to/from the Local IP
            2) “Flush NAT entry if it hasn’t been referenced in 60 sec”
            c) Session Termination Flush:
            1) When a modem connection is terminated
            ==> Modem hangs up and is released to modem pool
            ==> Local IP for that modem is released back to Local IP pool
            ==> NAT entry for that Local IP is flushed
            EVEN if 60s no-activity threshold hasn’t been reached
            6. Firewall ==> minimal ==> fully open internet connection
            — designed to accommodate broadest range of users and servers
            a) unsolicited traffic is allowed
            b) network protection engines protect against known spam, known attacks and detect/protect against DoS and suspected threats
            c) all non-Spam is allowed in both directions

            =========
            Scenario:
            =========
            1) Host_1 connects to modem pool and sets up PPP
            a) Local IP “101” is assigned to host_1 session
            b) Host_1 sends traffic to Server_1 on internet
            c) Router NATs Local IP “101” to first available Public IP
            ==> (e.g., Public IP “21”)
            ==> NAT Entry: Local IP “101” – to – Public IP “21”
            d) Host_1 continues his session with internet Server_1 for e.g., 15 minutes and hangs up modem
            e) Router flushes the NAT entry
            ==> No more entry for Local IP “101” – to – Public IP “21”
            2) Host_2 dials into the modem bank
            a) Host_2 is assigned the first available modem
            ==> which is the same modem that Host_1 had been using
            b) Host_2 now has Local IP “101”
            c) Host_2 sends traffic to Server_X on internet
            d) Router NATs Local IP “101” to first available Public IP
            ==> e.g., Public IP “21”
            ==> New NAT Entry: Local IP “101” – to – Public IP “21”
            e) Server_1 sends a packet to Host_1, not knowing that Host_1 is no longer there.
            ==> This could be a response packet or an unsolicited packet
            f) Router receives packet destined for Public IP “21”
            g) Router changes packet destination to Local IP “101” based on the current NAT entry
            h) Host_2 receives the packet from Server_1 that had been intended for Host_1
            ==> Host_2 connection bandwidth is being wasted on receiving unintended packets, so his data session is stretched out.

            =========
            Solutions that I can think of:
            =========
            1) Reprogram the NAT assignment algorithm
            ==> Either use a round-robin IP assignment of Public IPs
            ==> OR assign a default aging timeout to NAT entries. Perhaps the 60-minute timer that you described.
            ==> If a fixed-time timeout was used, the router would have to have the ability to override the timeout, so that it could reuse a Public IP if the public IP pool is depleted and an IP address needs to be used before the aging timeout has expired
            2) Reprogram the modem pool assignment so that it uses a round-robin approach for how the modems will be assigned to incoming calls.

            Given all the advances in routing, I was hoping to solve the problem by adjusting the NAT rules.

          • Joe Astorino says:

            I labbed up something like your perfect storm here and that is correct. In that very specific circumstance, that is how it would work. Once the dynamic NAT entry is added for the host_2 –> server_x flow it means ANYTHING on the outside (including server_1) that sends a packet destined to public IP 21 will be NAT’d back to the private IP of host_2.

            A practical way to solve this problem would be implementing a stateful firewall. In IOS you could do it with CBAC or ZBFW. In that case, the stateful firewall would drop the return or unsolicited traffic from server_1 going to host 2. The NAT piece alone would technically NAT the unwanted traffic to host_2, but a stateful firewall would prevent this. The stateful firewall would only allow in return traffic from an already existing flow, and that is all tied to more than an IP address (protocol, source/dest IP , source/dest port)

  • Joe says:

    I think there may be an error on the tables in the section “Dynamic PAT”. I think that you may have wanted the Inside Global IPs to be 12.3.4.254

  • Awesome article on NAT; by far on of the best. Interesting analysis by JoePublic; but I get the nagging feeling that this is an attempt at the re-invention of the wheel;

Leave a Reply