how-to block ads
Network Address Translation (NAT) Frequently Asked Questions
NAT is short of Network Address Translation. Its purpose is to change one host IP address within one subnet to another IP address within different subnet. This translation is called one-to-one translation.
WIth NAT, you can also change the entire or at least several host IP addresses within one subnet to another IP addresses within different subnet. This translation is called many-to-many translation. In other word, many-to-many translation can be viewed as a group of one-to-one translation.
Following is an illustration. Let's say you have five different IP addresses within one subnet. There are outbound traffic from these five IP addresses to remote subnet or host. In order to be able to reach the remote host or subnet, let's say the five IP addresses need to change to different IP address within different subnet.
Let's say for the change, there are seven available IP addresses within the different subnet. One way of the IP address change is to take five of them, assign one IP address to the original one IP address, and proceed the outbound traffic with their new IP addresses. This NAT process is 1-to-1 relationship.
Another way of the IP address change is to take only one of them, assign this one IP address to all five original IP addresses, and proceed the outbound traffic with their new IP addresses. This NAT process is 1-to-many relationship.
Most people refer the 1-to-1 relationship as NAT and refer the 1-to-many relationship as PAT (Port Address Translation).
Public and Private Subnet
In IP world, there is a concept of Internet-routable IP addresses. This concept refers to IP addresses that are reachable via the Internet. Those IP addresses are generally the non Private Subnet; or not within the 10.0.0.0/8, 172.16.0.0/12, nor 192.168.0.0/16 per IANA RFC 3330. IP addresses that are not within those subnet are in general considered Public Subnet or Public IP addresses.
For further info on Private Subnet and other Special-Use IP version 4 addresses, check out the RFC 3330 as follows.
RFC 3330 - Special-Use IPv4 Addresses
As you may note, Private Subnet or Private IP addresses are not Internet-routable IP addresses. Any PC or server that are using IP address within the Private Subnet will not be able to reach Internet directly. Similarly, public within the Internet are unable to directly reach those PC and server that are using Private Subnet.
If you need to have Internet access, then you need to have Internet-routable IP address. When there is an ISP that provide you the Internet access, the ISP is usually assigning IP address to you in the form of Public IP address; which is something like 126.96.36.199 IP address.
When Private Subnet is used within local network, there would be a need to bridge the local network to the Internet should the local network need Internet access. The ISP in the case acts as the bridge to provide Internet access for local network and to have public within the Internet able to reach the local network. To make this bridging work, there would be NAT/PAT in place within local network between the Private IP addresses and the ISP Public IP addresses.
Let's review the following situation. Let's say there are multiple hosts within your local network (i.e. multiple PC, servers). There are probably a need to have some kind of file sharing between these hosts. For this file sharing, the activity should be considered local or internal to the local network and should not involve Internet at all. When this is the case, then local network has option to use Private Subnet. When there comes time for local network to access the Internet, or to permit file sharing with public on the Internet; then ISP Public IP address is used by utilizing NAT/PAT.
NAT and Internet Access
Now let's review this situation. Say you have ISP that provide the Internet access. The ISP only provides you with one IP address. When you only have single host within your network (i.e. one PC or one server), then you can then assign the ISP-provided one IP address directly to the host to access the Internet.
When you have multiple hosts within your network that all need Internet access, then you need to have more than one IP address for all hosts. In order to have all hosts able to have Internet access, there are several ways to choose.
One way is to request more IP addresses from your ISP where you can assign each ISP-provided IP address to each of your host respectively. Keep in mind that that this choice might not be financially feasible or might introduce technical limitation.
Another way is to keep using the single ISP-provided IP address for all hosts. Note that in IP world, each host must have its own IP address. To overcome this limitation, the concept of PAT can be applied. By using PAT, basically you can share the single ISP-provided IP address for all hosts where there are needs for Internet access.
Here is some discussion.
»ASA 8.4(1) questions
Further, all local LAN machines are seen as their Public IP address on the Internet and not the Private IP address due to NAT/PAT. When there are more than one hosts that share the single ISP-provided IP address as described previously, then all of those hosts are seen as single host or as single IP address. The traffic coming from all local LAN machines that use PAT are seen on the Internet coming only from one IP address (the Public IP address) and not from multiple IP addresses (not the various Private IP addresses). In other words, the NAT/PAT technique can be seen as "firewall" since users in the Internet cannot directly access any machines within local LAN and vice versa.
Here is the PAT application breakdown
* Assign specific subnet to all hosts
* This subnet should only be meaningful locally to your network
* For each host, assign one IP address off the subnet
* When any host needs Internet access, you will utilize PAT to translate the local IP address to the ISP-provided single IP address
Typically the local subnet is within the Private Subnet (the 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). The ISP-provided IP address is typically coming from the Public Subnet.
As illustration, let's say you have 188.8.131.52 IP address as the ISP-assigned IP address. This IP address is your Public IP address. For local LAN machines, you can use something like 10.10.10.0/24 (which is a subnet of 10.0.0.0/8) as your Private IP subnet. When you use PAT for local LAN machines to go out to the Internet, all of your local LAN machines are seen as 184.108.40.206 IP address on the Internet eventhough each local LAN machines has its own (Private) IP address of (let's say) 10.10.10.2, 10.10.10.242, or 10.10.10.123.
Outbound Traffic, Inbound Traffic, and NAT
The NAT/PAT situation described previously is considered "outbound traffic". In this context, this outbound traffic refers to traffic originating from local (inside) network going out to outside network. The outside network here is the Internet. The local or inside network here is the local users that need to access the Internet.
With similar situation, NAT is applicable to "inbound traffic"; which mean traffic originating from outside network coming into inside network. Following is the illustration.
Let's say the local network is running servers that are accessible from the Internet, such as public web servers for file sharing. The local network is running Private Subnet for internal connectivity. The local network has the ISP Public Subnet for the Internet access. Both public reside on the Internet and local users need access to the public web servers.
To have the servers accessible by both public and local users, there should be NAT in place. For the public access, the server Private Subnet is NAT/PAT-ed to the ISP Public IP Address or Subnet. In other words, all servers or machines in local LAN that are accessible from the Internet are seen on the Internet as a single IP address (which is the single ISP Public IP address) when all of those machines use PAT. When those machines use NAT, then each machine is seen on the Internet as individuals (as their respective ISP Public IP addresses).
For the local user access, there should be no NAT nor PAT occur since both the servers and local users are within the same local/internal network. The local users can and should always access the server using the server Private Subnet directly.
Following is an illustration. Let's say the ISP Public IP address is 220.127.116.11. The objective is to run public-accessible web server that run on standard protocol TCP port 80 (the web port). The local network Private Subnet is 10.0.0.0/24 where the server IP address is 10.0.0.10. For the public access, the 10.0.0.10 will be PAT-ed to the 18.104.22.168 on TCP port 80.
When users on the Internet try to connect to the public web server, those users connect to the 22.214.171.124 IP address and not to the 10.0.0.10 IP address. The reason is that on the Internet, the web server is seen as the 126.96.36.199 IP address. The 10.0.0.10 IP address is only seen within local LAN.
In other words, the 188.8.131.52 IP address is the PAT-ed IP address of 10.0.0.10 IP address. Local users would just access the 10.0.0.10 directly and should never access the PAT-ed IP address.
Note that when users on the local LAN try to connect to the public web server, those users connect to the 10.0.0.10 IP address and not to the 184.108.40.206 IP address since the web server actually uses the Private Subnet. When users on the local LAN try to connect to the public web server using the PAT-ed IP address of the 220.127.116.11, then in most cases it won't work as you later find out.
Let's review similar illustration. The objective is now to run public-accessible web server and mail server which share the same ISP Public IP address of 18.104.22.168. The web server and mail server will be on their own dedicated local machines; one machine for web server and another machine for mail server. The web server application run on standard protocols TCP port 80 and port 443 (the web/HTTP port and HTTPS/SSL port). The mail server application also run on standard protocol TCP port 25 (the mail port).
The local network Private Subnet is 10.0.0.0/24 where the web server IP address is 10.0.0.10 and the mail server IP address is 10.0.0.11. For the public access, the 10.0.0.10 will be PAT-ed to the 22.214.171.124 on TCP port 80 and 443. Similarly, the 10.0.0.11 will be PAT-ed to the 126.96.36.199 on TCP port 25.
When users on the Internet try to connect to the public web server, those users connect to the 188.8.131.52 IP address on TCP port 80 and 443 and not to the 10.0.0.10 IP address. The reason is that on the Internet, the web server is seen as the 184.108.40.206 IP address. The 10.0.0.10 IP address is only seen within local LAN. Similarly, Internet users connect to the 220.127.116.11 IP address on TCP port 25 and not to the 10.0.0.11 IP address.
In other words, the 18.104.22.168 IP address is the PAT-ed IP address of 10.0.0.10 and 10.0.0.11 IP addresses simultaneously. Local users would just access the 10.0.0.10 and 10.0.0.11 directly and should never access the PAT-ed IP address.
During implementation and deployment, a network device such as router or firewall could be used to do the NAT/PAT between Private and Public Subnet. Such device usually have two connections; one is to connect to the ISP and another is to connect to the local network.
Note that from the local users' perspective (the PC, servers, etc.); such NAT/PAT process is transparent. The same NAT/PAT process is also transparent to the outside network (i.e. the Internet). All the NAT/PAT complexity process is taken care of by the router or firewall.
When there is NAT/PAT in place between two networks such as between your local private network and the Internet, the NAT/PAT device creates association between the local private network IP address machine, the NAT/PAT-ed IP address the local private network machine use, the machine or server IP address on the Internet that the local private network machine connects to, and the IP Protocol (and TCP/UDP ports used) to establish connection between the local private network machine and machine on the Internet. This association is stored in NAT/PAT table, managed by the NAT/PAT device.
There is a time limit that the NAT/PAT device use to keep the NAT/PAT association stored in the NAT/PAT table. When the time limit passes, the NAT/PAT device clears the NAT/PAT association off the NAT/PAT table. Clearing NAT/PAT association off the NAT/PAT table keeps the NAT/PAT device memory use efficient. However if the clearing takes too often or too soon, some traffic flow can break. Check out the following FAQ for more info.
»Cisco Forum FAQ »Minimum and Maximum NAT Timeouts
NAT/PAT and Network Security
When you use PAT to go out to the Internet as mentioned earlier, then you only use the Public IP address for outbound traffic. This means simply PAT mechanism only permit outbound traffic that initiate from your local private network machines out to the Internet and permit the returning traffic coming from the Internet back to your local private network machines. In other words, any inbound traffic initiated from the Internet come into your local private network will be dropped.
When you use NAT to go out to the Internet, then you use the Public IP address for both inbound and outbound traffic. In basic NAT/PAT device, this means simply NAT mechanism permit outbound traffic that initiate from your local private network machines out to the Internet and permit the returning traffic coming from the Internet back to your local private network machines. In addition, the NAT mechanism permit any inbound traffic initiated from the Internet come into your local private network. In other words, basic NAT mechanism is less secure than basic PAT mechanism from network security perspective.
Should you like to have more control of which permitted inbound traffic initiated from the Internet come into your local private network (i.e. due to network security reason), there are several approach you can put into place. For those basic NAT/PAT device, you can implement some kind of rule or ACL that control which inbound and returning traffic are permitted to come into your local private network.
When you use more sophisticated NAT/PAT device such as stateful firewall, by default the following are in place in terms of NAT/PAT mechanism.
* All inbound traffic initiated from the Internet come into your local private network will be dropped
* All outbound traffic that initiate from your local private network machines out to the Internet will be permitted
* All returning traffic coming from the Internet back to your local private network machines will be permitted
Should you like to permit inbound traffic initiated from the Internet come into your local private network to go through the stateful firewall, you have implement some kind of rule or ACL to permit such traffic.
NAT/PAT-able IP Protocols
Any Layer-4 IP protocol that has a concept of port such as TCP (Protocol 6) and UDP (Protocol 17) can be NAT/PAT-ed. However some IP protocols such as ICMP (Protocol 1), ESP (Protocol 50), and GRE (Protocol 47) have no concept of port. Therefore in general, these kind of procotols cannot be PAT-ed and then can only be NAT-ed.
Check out following official IANA documentation on protocols and TCP/UDP port number.
As a note that in most IP-based device implementation nowdays, ICMP can be PAT-able. In addition, further development as noted on RFC 3948, there is now a mechanism to run ESP over UDP to make the ESP protocol PAT-able. Check out the following for more detail: RFC3948 - UDP Encapsulation of IPsec ESP Packets
As mentioned previously in a case of running public- (Internet-) accessible server, there will be NAT/PAT process in place between the Internet and the server when the server uses Private IP address, where the NAT/PAT process could take place at router, firewall, or any NAT/PAT device. Following is more detail of what happen.
Let's say there is an Internet user connects to the NAT/PAT-ed Public IP address of a web server running on standard web service port (TCP port 80). On such connection, there is information containing the source IP address (the Internet user Public IP address), the source TCP port (the TCP port the Internet user use to connect to server TCP port which is usually a random port number between TCP port 49152 and 65535 according to IANA), the destination IP address (the web server NAT/PAT-ed Public IP address), and the destination TCP port (the TCP port 80).
When the connection from the Internet user arrives at the NAT/PAT device, the NAT/PAT device check which Private IP address the NAT/PAT-ed Public IP address associates to. This check refers to the NAT/PAT table consist on the NAT/PAT device memory. Once the NAT/PAT device finds the associated Public-Private IP address, the NAT/PAT device replaces the destination IP address from its NAT/PAT-ed Public IP address to the actual Private IP address while maintaining other info (source IP address, source TCP port, and destination TCP port) intact. The NAT/PAT device then forward this updated info to the server based on the NAT/PAT device routing table.
In relationship to NAT/PAT process, there is a term called Port Forwarding. The term Port Forwarding refers to the mechanism of replacing the NAT/PAT-ed Public IP address to the actual Private IP address while maintaining other info (source IP address, source TCP port, and destination TCP port) intact since from one perspective's, such process could be seen as forwarding the TCP port from the NAT/PAT-ed Public IP address to the actual Private IP address; which in this case was forwarding the destination TCP port 80 from the NAT/PAT-ed Public IP address to the actual Private IP address destination TCP port 80.
The understanding of such TCP port forwarding can be implemented to other Layer-4 IP protocol such as UDP in PAT process, or even other Layer-3 IP protocols in NAT process such as ICMP and ESP.
Complete View of NAT/PAT process
In previous illustration of port forwarding, it mentioned NAT/PAT process when traffic originated from the Internet to the server. The same understanding occurs for the return traffic from the server back to the Internet and for traffic initiated from the server to the Internet and the return traffic from the Internet back to the server.
As of previous illustration, there is a pair of source and destination IP addresses and a pair of source and destination port numbers. For return traffic from the server back to the Internet, the source IP address is that actual Private IP address of the server. The source port is the port of the server uses. In previous illustration, the source port of the server for the return traffic back to the Internet is TCP port 80.
The destination IP address is now the Internet user (Public) IP address. The destination port is the actual port the Internet user uses, which is the same port number that ranged between 49152 and 65535 according to IANA.
In terms of return traffic or of traffic initiated from the server to the Internet, the source IP address changes once the traffic hits the NAT/PAT device. As previous illustration, the NAT/PAT device checks its NAT/PAT table to find the Private-Public NAT/PAT-ed IP address association. Once the device finds the correct association, the source IP address change takes place. The traffic is now forwarded to the Internet by the NAT/PAT device based on the device's routing table.
For more info on NAT/PAT process, check out the following link.
RFC 3022 - Traditional IP Network Address Translator (Traditional NAT)
Static and Dynamic NAT/PAT
As mentioned earlier, one advantage of using NAT/PAT is to use single Public IP address for multiple local machines. Within the NAT device itself (either router or firewall), there is a NAT table that keep associations between the Public and Private IP address; on which protocol and on which port number. This way the NAT device understand which local machine (that uses Private IP address) associates with which Public IP address, with which protocol, and with which port numbers.
When you run Internet or public-accessible server using NAT device, you need to maintain constant NAT/PAT association between Public and Private IP address. When there are only workstations within the local machines, dynamic NAT/PAT association is desirable.
Keep in mind that with constant (static) NAT/PAT association, the Public and Private IP address one-on-one relationship is fixed (never changed) even though the local machine is powered off or is not connected to the local network. With dynamic NAT/PAT association, the Public and Private IP address one-on-one relationship is changing, especially when the local machine is powered off or is not connected to the local network. This static NAT/PAT association between Public and Private IP addresses is called static NAT/PAT where the dynamic NAT/PAT association is called dynamic NAT/PAT.
Following is some discussion on NAT and PAT implementation
Using Cisco router
»[Config] NAT routing
Using Cisco ASA or PIX Firewall
»[Config] different types of port forward on a 501 box clarifaca
Outside and Inside Network
From local network perspective, the Internet from the previous illustration is considered outside network and the local network is considered inside network. Note that outside network is not limited only to the Internet. Basically any network that is not within local network is considered outside network.
Let's review the following situation. Consider there are two organizations A and B. Both A and B have their own local network. From A perspective, A network is considered inside network and B network is considered outside network. Similarly; from B perspective, B network is considered inside network and A network is considered outside network. Both A and B consider the Internet as outside network, where the Internet consider both A and B as outside network as well.
NAT and Overlap Network
As mentioned previously, Private Subnet is established to provide local traffic network connectivity. Anybody or any organization can use the Private Subnet in anyway they like within local network.
Let's revisit the previous illustration of two organizations A and B. Consider A and B need to inter-communicate; where there are servers within A need to be accessible by B and there are servers within B need to be accessible by A. To provide this communication, there is a private connection between the A and B.
Each organization utilizes 10.0.0.0/16 Private Subnet within their local network. Since the traffic between A and B is internal to them over private connection, both A and B decide to use Private Subnet to communicate.
Note that there will be a problem connecting. Let's say there is a server with 10.0.0.10 IP address exist on both A and B networks. There is a host with 10.0.0.9 IP address within A need to communicate with the 10.0.0.10 server within B. The traffic will not go to 10.0.0.10 within B but go to the one within A instead since there is no mechanism to distinguish between 10.0.0.10 within A and 10.0.0.10 within B. This situation is referred as overlap network where both networks use the same subnet.
To provide A-B inter-communication, you can implement NAT. There will be subnet that both A and B agree to utilize as a bridge for inter-communication. This subnet bridge must be something that is not and will not be used within A or B locally to make it work.
Let's say both A and B agree to utilize 192.168.0.0/16 subnet. A 192.168.1.0/24 is assigned to A and a 192.168.2.0/24 is assigned to B. Any A hosts that need to communicate with B hosts will be NAT to IP address within 192.168.1.0/24. Similarly, any B hosts that need to communicate with A hosts will be NAT to IP address within 192.168.2.0/24.
With this setup, A hosts will appear distinct from B hosts' perspective and vice versa. A hosts can distinguish properly when there is a need to reach B hosts. This NAT setup is called Double NAT, where NAT process takes place on both networks to provide connectivity between the two networks.
NAT and Internal Communication between multiple organizations
In previous illustration, it was described that NAT was used to avoid routing confusion due to overlap network between multiple organizations. It was decided that both A and B used 192.168.0.0/16 subnet to inter-communicate.
Now let's say there is a 3rd organization which is C that also need to inter-communicate with A and B. Unfortunately C uses 192.168.0.0/16 internally where present another overlap network with the NAT network of A and B.
One way to make 192.168.0.0/16 to still be the NAT network between the three organizations is to "force" C to internally NAT their 192.168.0.0/16 into different subnet; i.e. 10.0.0.0/16. After the C internal subnet of 192.168.0.0/16 is NAT-ed to 10.0.0.0/16, the 10.0.0.0/16 is NAT-ed to 192.168.0.0/24 to be able to inter-communicate with A and B.
Note that A and B internally only NAT once (from the 10.0.0.0/16 to 192.168.1.0/24 for A and to 192.168.2.0/24 for B). However C is "forced" to do internal Double NAT (from 192.168.0.0/16 to 10.0.0.0/16 to 192.168.0.0/24).
Another way is to forbid any organization to use 192.168.0.0/16 for any internal usage since it is "reserved" as the NAT subnet for inter-communication. This way might work in some organization. However no organization should have right to reserve any part of the IANA RFC 3330 Private Subnets since they have no authority to do so.
You should be able to see that the decision A and B made of using Private Subnet as NAT network was a mistake; or at least it was not scalable. Keep in mind that Private Subnet is something that anybody or any organization can use for any purpose. Therefore Private Subnet should only be used internally within one organization and should never be used as NAT network for multiple organization inter-communication.
For NAT and for any devices that would be accessible from any organizations, it is suggested that Public Subnet (Internet-routable subnet) is used; even though the inter-communication takes place over private connection and not over public connection (not over the Internet). Public Subnet is unique (is assigned to only single organization), hence unnecessary NAT process won't take place for multiple organization inter-communication.
Another advantage using Public Subnet as NAT network is the following. From previous illustration, it was mentioned that A, B, and C were inter-communicating over private connection. Let's say the private connection fails or goes down. When that is the case, either one of the three organizations could use the public connection (Internet connection) to keep the inter-communication flowing when the organization uses Public Subnet as the NAT network and as the IP Subnet of any devices that would be accessible from any organizations since Public Subnet is Internet-routeable subnet and is commonly found in the Internet anyway.
»[Config] Persistent IPSec Tunnel ASA-ASA
The Internet and DMZ
If you notice, the Double NAT implementation is similar to the previous illustration of local network running public web server for users within the Internet. Here are the perspectives.
From A network perspective, B users are "within the Internet" (the A's outside network). From B perspective, A users are "within the Internet" (the B's outside network). Note that the 192.168.0.0/16 from both A and B perspective is outside network, even though the subnet is within Private Subnet.
Of course, neither A nor B are the actual users within the Internet since there is private connection between two organizations. This where the concept of DMZ (De-Militarized Zone) is applied. From A perspective, B users are within the DMZ. From B perspective, A users are within the DMZ.
To be precise, the 192.168.0.0/16 is the DMZ network from both A and B perspectives. Both A and B users consider the Internet as "the real" outside (public) network.
In some organizations, public servers for users within the Internet reside within the DMZ. In other word, there is a distinct separation between local network and public servers within the DMZ. From network security perspective, this distinct separation is considered more secure.
Extranet and DMZ
In multi-organization communication over private connection, there is a term called Extranet. To illustrate what Extranet is, let's revisit previous example of A and B networks. From A's perspective, B network is called Extranet since the communication is going over private connection to reach external network. The same perspective takes place on B network where B sees A as Extranet.
Typically this Extranet is seen between most untrusted network such as the Internet and most trusted network such as internal network. Therefore in typical network implementation, Extranet is placed on DMZ.
Many organizations have multiple DMZ where each is to serve different purpose. One DMZ could be for clients or users that resides in the Internet, one DMZ could be for clients or users that resides in the Extranet, and one DMZ could be for clients or users that resides in the intranet or internal network. More about Intranet will be on the next discussion.
As mention in previous illustration, connection across Extranet and DMZ could be utilizing some kind of NAT to avoid overlap network, due to simplicity, and due to security network requirement.
Intranet and DMZ
Typically in larger organization, there could be several sub-organizations or sub-networks that run independently within single organization. At some points, these sub-networks could be in need to interconnect to each other, typically over some private connections. Communication between these internal sub-networks that are under the same network or the same larger organization is called Intranet communication.
As mention in previous illustration, Intranet is typically set as "another" DMZ. In addition, connection across Intranet and DMZ could be utilizing some kind of NAT to avoid overlap network, due to simplicity, and due to security network requirement.
The Use of Internet-routable (Public) IP Address or Subnet
As mentioned in previous illustration that Internet-routable (Public) IP Address or Subnet should be used as NAT/PAT-ed IP address or Subnet in Extranet or Intranet to avoid overlap network, due to simplicity and scalability.
As a note here that Public IP address or subnet does not necessarily have to be seen on the Internet. In a lot of organizations, it is typical network design to have Internet-routeable (Public) subnet utilized only for internal use and not seen on the Internet. This network design is more apparent when such organization have multiple Extranet and/or Intranet. Such network design is also typically found in ISP (Internet Service Provider) or in public web hosting environment in serving Internet access, DNS access, mail access, or any services to their clients.
NAT Expected Behavior
Let's review the previous illustration of local network running servers to be accessible from outside network. The servers are in fact using two different IP addresses from two different subnets; one IP address is within the outside network and another IP address is within the inside network. The outside IP address is the NAT/PAT-ed IP address of the internal IP address.
From outside users perspective, the servers are located within outside network using their outside IP address. From inside users perspective, the servers are located within inside network using their inside IP address. Let's say a local user's network device are using the server outside IP address instead to access the server. In general, the connection will fail since the local user's network device is unable to determine the server location, whether the server is located within outside or inside network. This is the reason why the local network should use the internal IP addresses to access the servers and why the outside users would then use the outside IP address.
Note that by using some network devices, local users are still able to access the server using the server outside IP address. However this situation applies only to those specific network device internetworking. In addition, this internetworking is non-standard (read: against the IETF RFC 3022) and may create unexpected behavior in multi-vendor inter-connectivity or in any other situations. The suggested approach is not to deploy such network devices. Instead it is suggested to exercise the proper practice that comply with the RFC 3022.
For more info regarding NAT expected behavior, check out the following RFC as follow.
RFC 2663 - NAT Terminology and Considerations
RFC 5382 - NAT Behavioral Requirements for TCP
RFC 5508 - NAT Behavioral Requirements for ICMP
RFC 4787 - Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
RFC 5135 - IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)
NAT and DNS/WINS
When there are servers that need to be accessible by both outside and inside users, a proper practise is using some kind of name resolving mechanism to access the servers. This name resolving mechanism here is performed by DNS (and/or WINS in Microsoft Network).
Basically the DNS provides relationship between a name and IP addresses. When users (either local or outside) access the server, the users use the server name to access. The DNS then will translate (resolve) the name into the server IP address and forward the users' access request to the server.
Let's revisit the previous situation where the server has inside IP address and outside IP address (the NAT-ed inside IP address). When the users are within outside network, then DNS should resolve the name into outside IP address. When the users are within inside network, then DNS should resolve the name into inside IP address. This way, no inside nor outside users' network device will be confused in accessing the server.
Note that the server name is exactly the same (verbatim) from outside and inside users' perspective. As illustration, the server name is always www.publicserver.com, either the server is accessed from outside or from inside network. However the DNS will resolve www.publicserver.com into its outside IP address when the users are within outside network. Similarly, the DNS will resolve www.publicserver.com into its inside IP address when the users are within inside network.
DNS and ASA/PIX Firewall NAT DNS feature
As mentioned previously, DNS name resolving should be able to choose the proper IP address for specific users; where outside users will be receiving outside IP address when accessing the public server, and inside users will be receiving inside IP address when accessing the same server.
In general, your system administrator need to configure the DNS BIND to be able to do such resolving. Fortunately there is a nice DNS feature on Cisco ASA and PIX Firewall where the DNS need only to resolve names to inside IP address, and still have the outside users able to access the server.
The key is to use static command followed by the dns parameter. Here is the official Cisco command reference
ASA/PIX Firewall Static command description
Using the static dns command, the ASA or PIX will rewrite the inside IP address to the proper outside IP address of all necessary devices for outside users server access need. Usually the DNS server and the public server IP addresses are both included in the static dns command. When there is Microsoft network involved; then WINS and/or Domain Controller IP addresses would also be included as well. The DNS, WINS, and/or Domain Controller in Microsoft network (or just DNS in non-Microsoft network) will then be used by outside users transparently as if the users are within inside network.
NAT/PAT Sample Implementations
»Cisco Forum FAQ »Setting Up Network With ISP WAN and Public IP Block subnets running NAT
»PIX 515 - Private T1, Public IP
Alternate Solution of DNS Name Resolving and Server Access
Concerning DNS name resolving, another approach is to associate DNS name only with the NAT (Public) IP address. This approach is simpler since there is no need for DNS BIND to resolve to both Public and Private IP addresses. Both outside and inside users will access the Public IP address regardless, which means no NAT necessary to access the server.
To make this work, there must be dedicated static Public IP address block only for those outside and inside users server access. In other words, there will be a dedicated Public IP address for Internet access, and other dedicated Public IP addresses for those servers.
In addition, those dedicated Public IP addresses for the servers must be in different subnet than the Public IP address for Internet access. This means that you may need to have another Public IP address block from your ISP. Another approach is to subnet your current Public IP address block into smaller network from let's say single /27 subnet block to two smaller /28 subnet blocks. Whatever the approach is, make sure that your ISP understand what you are trying to achieve to ensure the ISP can provide the proper access for those servers.
Following is illustration list of network design and consideration
»Cisco Forum FAQ »Router configuration to run server (with and without port forwarding)
»Cisco Forum FAQ »PIX Firewall/ASA configuration to run server (with and without port forwarding)
»Cisco Forum FAQ »Separate Internet: Dedicate T1/E1 for server, dedicate DSL/Cable for LAN
»[Config] Cisco 806 IP Routing Help
More on DNS Name Resolving and Design
As noted previously, you could have the static command with dns parameter to use internal DNS server to resolve names for inbound connection coming from the Internet in. You could also create duplicate zones with same entries, which is not really efficient.
Should you consider to create duplicate zones, here are the choices that you can implement.
1. Short-term (bandage) solution: Use DNS Redirector such as SimpleDNS
This approach will allow you to modify DNS requests without duplicating the entire zone internally. For example if your website is on 22.214.171.124 you would just need to add two following lines to the SimpleDNS file.
(and not replicate the rest of the zone's records)
If you're having to do any of this, it would seem that your internal domain name configuration was not well thought out.
Let's say your domain name is example.com
- www.example.com and example.com should resolve to the (outside) hosted website
- example.com was used as the internal, or Active-Directory integrated domain-name
...this was a bad idea!
2. Long-term solution: Redesign DNS architecture
As noted above, the DNS redirecting approach is not designed to be as long-term solution since it is merely providing quick fix. It is highly suggested to have DNS architecture redesign as long-term solution instead. Following is one typical approach of a good DNS architecture.
Let's say your domain name is example.com
- www.example.com and example.com will still resolve to the (outside) hosted website, which is used for external machines such as extserver1.example.com and extserver2.example.com using Public IP addresses typically
- internal.example.com is the internal, or Active-Directory integrated domain-name as the Fully Qualified Domain Names for internal machines such as server1.internal.example.com and pc12.internal.example.com using Private IP addresses typically
With this approach, any DNS name resolve for connection coming from internal machines use internal.example.com zone and any DNS name resolve for connection coming from external machines use example.com zone; where each zone has separated name resolve of IP address and names to avoid name resolving confusion.
»Cisco Forum FAQ »NAT, PAT, Port Forward, Internet and Server Access: Introduction and Practices
Network Address Translation or NAT is an Internet standard (IETF RFC 1631) that enables a local-area network (LAN) to use one set of IP addresses for internal traffic and a second set of addresses for external traffic. A NAT box (e.g. a router) located where the LAN meets the Internet makes all necessary IP address translations.
- Hides internal IP addresses.
- Enables a company to use more internal IP addresses. Since they're used internally only, there's no possibility of conflict with IP addresses used by other companies and organisations.
The links below provide NAT information in greater detail:
An introduction to NAT
NAT FAQ @ Cisco.com
How to configure NAT?
NAT and route maps.
NAT Implementation: Sample Configurations
1. Basic Internet Access (Outbound Traffic Only) - No Public Servers
Various Cisco Router, PIX/ASA NAT/PAT Sample Configurations
2. Basic Internet Access and Public Servers (Inbound and Outbound Traffic)
Running Servers using Cisco Router, PIX/ASA NAT/PAT Technology
Generic NAT configuration
This configuration was worked up on a cisco 831 with 12.2(13)ZH2 software but should work on any cisco router with a modern version of IOS, just adjust the interfaces accordingly.
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
logging queue-limit 100
ip dhcp excluded-address 192.168.4.1 192.168.4.10
ip dhcp pool LOCALPOOL
network 192.168.4.0 255.255.255.0
ip audit notify log
ip audit po max-events 100
no ftp-server write-enable
description Inside private interface
ip address 192.168.4.1 255.255.255.0
ip nat inside
hold-queue 100 out
description Outside public interface
ip address dhcp
ip nat outside
ip nat inside source list 1 interface Ethernet1 overload
ip http server
no ip http secure-server
access-list 1 permit 192.168.4.0 0.0.0.255
line con 0
no modem enable
line aux 0
line vty 0 4
scheduler max-task-time 5000
If you would like to add any more links or information to this FAQ, please do not hesitate to contact the FAQ Editors whose avatars are present at the top of the Cisco FAQ forum page or click the feedback link which can be found at the bottom left hand corner of this page.
These timeouts will count individually for each NAT session, and after the session has been inactive for the time specified the router will flush it, if the session is active (some traffic is passing through it) the router won't start the timer. For some connections like FTP and telnet the TCP session is established and traffic start passing through, if the router sees a TCP-FIN packet it will flush the NAT connection, and if not, it will wait for the timeout, but for SMTP and HTTP, the session is established, but the applications won't send traffic unless you click on a link or download an email, so for that, the session is flushed by the router as soon as the timeout is reached. So the timeout of a session depends more on the application than the NAT timeout.
There are some applications like SQL, Citrix and other databases and thin clients that are really sensitive, and if the session is flushed and a process has not being finished the application would need to restart the process. Some others like MSN, HTTP and normal applications are not so sensitive and if the NAT session is flushed it will establish a new one and nothing will be noticed by the user.
At the other extreme, we have maximal timeouts and that brings with it a whole range of problems. A large, really large NAT timeout will impact the router's memory and result in latency in most of cases and in extreme scenarios the router can crash per a lack of memory. This is because all sessions that for any reason were not finished by a TCP-FIN packet, will stay in the router forever and ever and spend memory and CPU. Maybe one day the timer would be reached, but maybe not and the router crashes first.
So playing with NAT timouts is not condoned unless undertaken or supervised by someone experienced with NAT and its impact on various protocols. Cisco's default timeouts are adequate for most needs and do not need adjusting for any reason. It's only in extreme circumstances will the timeouts be evaluated and a test run with the protocols and sessions involved undertaken to determine its effect on the application(s) in question and its impact on router resources.
Derived from this thread:
»[HELP] Minimal NAT TCP/UDP timeouts?
However it is possible using a technique that was actually designed for a different purpose, an IP NAT pool. Using a NAT pool means you can specify an ACL (in this case with the port range) but you use a "pool" of a single address and specify the rotary method.
In the example below the IP address 192.168.1.10 is the internal address that you wish to forward the range of TCP ports to:
ip nat pool p2p 192.168.1.10 192.168.1.10 netmask 255.255.255.0 type rotary ip nat inside destination list 100 pool p2p access-list 100 permit tcp any any range 6881 6999
* This tip has been tested working with various routers within various network topology
* Similar attempts have been tried on UDP traffic to no avail. Therefore it is safely assumed that this tip does not work on UDP traffic.
Feedback received on this FAQ entry:
This FAQ discuss some options in regards to modify existing ACL on routers in general, and specifically inserting lines into existing ACL. Though the term router is used, this concept applies to any Cisco IOS-based platform including switches and AP (Access Point). Into some extent, the concept also applies to Cisco firewall (PIX and ASA) and Nexus switches running NX-OS.
Most CCNA books say modifying existing ACL or inserting lines into existing ACL can't be done....well that shows you shouldn't believe everything you read :)
Option 1: IOS image supports ACL line number
If the IOS image running on the router supports ACL line number, then following is the procedure you can follow.
First do a show access-list at the exec prompt
Note the line numbering in the required access-list e.g.:
extended IP access-list 115 10 access-list 115 deny ip host 126.96.36.199 any 20 access-list 115 permit ip any any
Then enter config mode and insert the line you want to add, prefixing it with the appropriate number to position it where you want in the list (substitute standard for extended in the example below if you are working with a standard ACL):
conf ter ip access-list extended 115 15 deny ip host 188.8.131.52 any end
If you repeat the show access-list you should find the deny just where you want it ;)
extended IP access-list 115 10 access-list 115 deny ip host 184.108.40.206 any 15 access-list 115 deny ip host 220.127.116.11 any 20 access-list 115 permit ip any any
Below is a full example with a named extended ACL
router#show access-list Extended IP access list to-internet 10 deny udp any any eq netbios-dgm (17226 matches) 20 deny udp any any eq netbios-ns (6648 matches) 30 deny udp any any eq netbios-ss 40 deny tcp any any eq 137 50 deny tcp any any eq 138 60 deny tcp any any eq 139 70 deny udp any any eq 445 80 deny tcp any any eq 445 90 deny udp any any eq 593 100 deny tcp any any eq 593 110 permit ip any any (152039 matches) router#conf ter Enter configuration commands, one per line. End with CNTL/Z. router(config)#ip access-list ext to-internet router(config-ext-nacl)#25 permit ip any host 18.104.22.168 router(config-ext-nacl)#exit router(config)#exit router# router#show access-list Extended IP access list to-internet 10 deny udp any any eq netbios-dgm (17226 matches) 20 deny udp any any eq netbios-ns (6648 matches) 25 permit ip any host 22.214.171.124 30 deny udp any any eq netbios-ss 40 deny tcp any any eq 137 50 deny tcp any any eq 138 60 deny tcp any any eq 139 70 deny udp any any eq 445 80 deny tcp any any eq 445 90 deny udp any any eq 593 100 deny tcp any any eq 593 110 permit ip any any (152039 matches)
The suggested next step is to renumber the access-list starting from 10 by step of 10 using the following command
router#conf ter Enter configuration commands, one per line. End with CNTL/Z. router(config)#ip access-list resequence to-internet 10 10 router(config)#exit router# router#show access-list Extended IP access list to-internet 10 deny udp any any eq netbios-dgm (17226 matches) 20 deny udp any any eq netbios-ns (6648 matches) 30 permit ip any host 126.96.36.199 40 deny udp any any eq netbios-ss 50 deny tcp any any eq 137 60 deny tcp any any eq 138 70 deny tcp any any eq 139 80 deny udp any any eq 445 90 deny tcp any any eq 445 100 deny udp any any eq 593 110 deny tcp any any eq 593 120 permit ip any any (152039 matches)
This method has been tested with both IOS 12.3 and 12.4 and works with standard, extended, numbered and named ACLs.
Note that on older IOS image version, you may have to issue service linenumber command to activate the ACL line numbering. In newer IOS image version, this command is already activated by default; therefore there is no need to reissue the command.
Option 2: IOS image does not support ACL line number
When the router IOS image does not support ACL line number, then following is the procedure you can follow.
1. Copy the ACL into a text editor (i.e. Notepad on Windows or vi on UNIX).
2. On the text editor, insert the ACL line.
3. Verify that your work is correct and will not bring down production time.
4. On router, unapply the ACL temporarily off the router.
5. Remove the ACL off the router.
6. Copy the updated ACL from the text editor into the router.
7. Verify that the router already have the updated ACL.
8. When the router does have the updated ACL, reapply the ACL as existing condition.
You have the following on your router
interface Ethernet0 ip address 188.8.131.52 255.255.255.0 ip access-group 100 in ! access-list 100 permit udp any eq 53 any access-list 100 permit tcp any any established access-list 100 deny ip any any
You need to have the ACL 100 to look like the following
access-list 100 permit tcp any any eq 80 access-list 100 permit udp any eq 53 any access-list 100 permit tcp any any established access-list 100 deny ip any any
Following the above steps, here are what you should do
1. Copy the existing ACL 100 and paste to your text editor
Let's say your Notepad as the text editor. On the router, highlight the access list. Copy the highlighted and paste to Notepad.
2. On the text editor, insert the ACL line (the "access-list 100 permit tcp any any eq 80")
access-list 100 permit tcp any any eq 80
3. Verify that the updated ACL 100 on the text editor is correct and will not bring down production time. This means that access-list line order is proper which should not block legitimate traffic and only block illegitimate one.
4. On router, unapply the ACL temporarily off the router.
configure terminal interface Ethernet0 no ip access-group 100 in
5. Remove the ACL off the router
no access-list 100
6. Copy the updated ACL from the text editor and paste into the router.
Let's say you use Notepad as the text editor. On the Notepad, you should have the following
conf t access-list 100 permit tcp any any eq 80 access-list 100 permit udp any eq 53 any access-list 100 permit tcp any any established access-list 100 deny ip any any end
Have the router to be at global configuration mode, like following
Highlight all of the above command lines on the Notepad (from "conf t" to "end"), select copy of the highlighted and paste to the router.
7. Verify that the router already have the updated ACL.
show access-list 100
8. When the router does have the updated ACL, reapply the ACL as existing condition back to the interface
configure terminal interface Ethernet0 ip access-group 100 in end
The illustration assumes that the ACL 100 is only applied to a single interface. When the same ACL is applied to multiple interfaces, you need to unapply and reapply the ACL on all interfaces. In some cases, the router may need to dedicate ACL 100 to one interface while other interfaces use different ACL (i.e. ACL 101, 102).
In addition, keep in mind that you can lock yourself out of a router by making a mistake when working with ACLs. Worse, your ACL work could bring production time down. If you are working remotely and it is possible to reload the router afterward, it is particularly important that you consider issuing a reload in x command where x is the number of minutes that will pass before the router will reload itself. Then if you lock yourself out you know the router will be reset within x minutes. When you are happy the changes are correct you can write the new config and cancel the reload with reload cancel. Note that a router reload brings down network, so you may want to have some kind of authorized work window as previously stated.
When it it not possible to reload and you are working remotely, then you should have out-of-band access as alternate access. This out-of-band access is a dedicated line that goes directly to the router console port. A lot of out-of-band access is setup using analog dialup modem via POTS line; although many organizations also use Frame Relay, DSL, or cable modem for faster access.
Of any configuration changes, there should be considerations of impact to production time. In general, ACL change may bring down production time. ACL modification process could also bring in unwanted incoming traffic from the Internet, which then might bring down some system. With that in mind, a consideration that an ACL modification process is to take place after hours or during off-hours is in order. Depending on the environment you are working on, you may need some approval from authorized people or your manager to make any changes and to get authorized work window.
Options in this FAQ are not meant to be real-live implementation, especially in production network; rather it is intended as illustrations of possible ways of modifying ACL. Certain companies have their own standard and methodologies in regards of modifying existing ACL or of any configuration changes, which you should be aware of. If you are unaware of such, consult your manager prior any work.
Feedback received on this FAQ entry:
There are times that some network devices have Public IP addresses that belong to different companies or organizations. In other times, there are appliances that "insist" to only work with certain IP addresses and refuse to work with other IP subnet.
In cases like these, NAT/PAT are necessary to avoid overlapping IP address assignment or routing issue. Following is the list of discussion with some sample network design and approach.
Setting up routing within internal network is probably simplest thing to accomplish. Simply run your routing protocol of your choosing on routers and Layer-3 switches (i.e. EIGRP for Cisco shop), the routes simply work "out of the box".
After the routes have been working for years, people start having ideas of introducing firewall into the mix which mean creating multiple security zones; i.e. Outside or Untrust zone for users, Inside or Trust zone for database servers, and DMZ for web servers. Unfortunately these people simply introduce the firewall into the mix and set up its routing just like routers without further consideration of what multiple security zone creation means.
Firewall introduction means to protect certain network resources, where there are at least two zones to be in place; Outside or Untrust zone and Inside or Trust zone. Untrust zone is where the least trusted networks lie, such as the Internet or simple users with their PC. Trust zone on the other hand is the most trusted networks lie, such as the server networks.
Prior the firewall introduction, those Untrust and Trust networks are interconnected in a setup as mesh as possible for redundancy. Firewall introduction that simply logically disconnect certain connectivity between Untrust and Trust networks while leaving the rest of networks in place is by default network design fundamental flaw since traffic between Untrust and Trust networks can simply be going bypassing the firewall through those alternate connectivity, hence defeat the purpose of firewall introduction.
This is when careful consideration is in order prior firewall introduction, where no traffic flow can bypass the firewall after the firewall introduction. Network redesign is a must to avoid issues. Following is an illustration.
»ASA SSH copnnection issues
Conditional NAT (NAT source only to specific destinations)
For those who are unaware, RFC 1918 as with any RFC stating world-wide industry standard, basically saying that there are IP version 4 subnets that anyone can use for anything including internal network connectivity and VPN between organizations, and would not be Internet-routable IP subnets. These IP subnets within RFC 1918 are popularly called as "Private IP address" while the non-RFC-1918 IP addresses are popularly called as "Public IP address". These name Private and Public IP addresses arose with the consideration that only Public IP address that are Internet routable while internally in any organization, IP addresses used within are Private IP address. When those hosts using the Private IP address needed to go out to the Internet, there should be a NAT in place as explained in RFC 1631.
In today's internal network design, it is typical (and highly suggested) to use those RFC-1918 IP addresses as the internal IP address and only use non-RFC-1918 IP address when the internal hosts that use the RFC 1918 IP addressed need to go out to the Internet. There are some exception with this typical setup as follows.
* Private connectivity between two or more organizations to use non-RFC-1918 IP addresses as the NAT-ed IP address to avoid IP scheme conflicts between those organizations
* An organization has a huge internal network that it is simply impossible to use only RFC-1918 IP addresses for internal hosts. The typical solution is to use RFC-1918 IP addresses for point-to-point network while using non-RFC-1918 IP addresses for hosts such as router's Loopback, servers, printers, and PC. With this case there are usually two separate non-RFC-1918 IP addresses to be used where one is for internal hosts and another one is as NAT IP address when those hosts need to go out to the Internet or need to reach business partner's network through private circuit or VPN connection
* The internal hosts need to be reachable from both private connection and the Internet
Check out the following thread for illustration.
»[Info] Enterprise IP Addressing Scheme
»IPS on a cisco 1801 IPS