how-to block ads
|
| | | | FAQ Revisions | Editors: skj  , Covenant , aryoba , Phraxos
Last modified on 2009-11-27 07:30:01
| |
|
|
40.1 NAT/VPN/ACL/CBAC/Firewall·NAT, PAT, Port Forward, Internet and Server Access: Introduction and Practices
·Generic NAT configuration (RFC 1631)
·Minimum and Maximum NAT Timeouts
·How do I NAT a TCP port range without entering a seperate NAT for each port?
·How can I insert a line into an existing ACL on Routers?
| | | Following is short introduction of NAT and PAT; and how Cisco equipments implement such technology. Please note that some info could be misleading without proper understanding of background conditions. However most of the answers are straight-forward that should not lead to any misinterpretations.
Network Address Translation (NAT) Frequently Asked Questions
Introduction
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 3.12.62.154 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.
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 3.12.62.154 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 3.12.62.154 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 3.12.62.154. 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 3.12.62.154 on TCP port 80.
When users on the Internet try to connect to the public web server, those users connect to the 3.12.62.154 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 3.12.62.154 IP address. The 10.0.0.10 IP address is only seen within local LAN.
In other words, the 3.12.62.154 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 3.12.62.154 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 3.12.62.154, 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 3.12.62.154. 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 3.12.62.154 on TCP port 80 and 443. Similarly, the 10.0.0.11 will be PAT-ed to the 3.12.62.154 on TCP port 25.
When users on the Internet try to connect to the public web server, those users connect to the 3.12.62.154 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 3.12.62.154 IP address. The 10.0.0.10 IP address is only seen within local LAN. Similarly, Internet users connect to the 3.12.62.154 IP address on TCP port 25 and not to the 10.0.0.11 IP address.
In other words, the 3.12.62.154 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 deployement, 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.
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.
PORT NUMBERS
Protocol Numbers
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
Port Forwarding
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 it return traffic.
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 term 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 destination 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.
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
Some discussions
»[Config] Cisco 806 IP Routing Help
 feedback form
 feedback form
by aryoba
last modified: 2009-10-08 10:21:23 | | | Prerequisite reading:
»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.
NAT:
- 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.
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
logging queue-limit 100
!
ip subnet-zero
ip dhcp excluded-address 192.168.4.1 192.168.4.10
!
ip dhcp pool LOCALPOOL
import all
network 192.168.4.0 255.255.255.0
default-router 192.168.4.1
!
!
ip audit notify log
ip audit po max-events 100
no ftp-server write-enable
!
!
!
!
!
!
!
interface Ethernet0
description Inside private interface
ip address 192.168.4.1 255.255.255.0
ip nat inside
hold-queue 100 out
!
interface Ethernet1
description Outside public interface
ip address dhcp
ip nat outside
duplex auto
!
ip nat inside source list 1 interface Ethernet1 overload
ip classless
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
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
scheduler max-task-time 5000
!
end
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.
feedback form
feedback form
by Covenant edited by aryoba
last modified: 2008-12-24 10:03:21 | | | Moving the default NAT timers has benefits, such as the utilisation of a small timer, will clean the table and flush translations that are not active. It will free memory within the router for other purposes. I know that sounds great, but if for some reason one of your applications needs a large timeout to finish the session, the router if configured with a small timer will flush them and new sessions would need to be established. The cpu utilization will be lower in general, but there will be an increase in cpu processing (occurs in peaks) when the table gets flushed and new sessions are established. After that, it will resort again back to its low level, hence my use of the word peaks.
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?
feedback form
feedback form
by Covenant edited by aryoba
last modified: 2006-06-26 18:56:27 | | | The general answer to this question is that it can't be done.
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:
feedback form
feedback form
by Phraxos edited by aryoba
last modified: 2009-09-13 03:40:56 | | | Most books say this 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.:
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):
If you repeat the show access-list you should find the deny just where you want it ;)
Below is a full example with a named extended ACL
The suggested next step is to renumber the access-list starting from 10 by step of 10 using the following command
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.
Illustration
You have the following on your router
You need to have the ACL 100 to look like the following
Following the above steps, here are what you should do
1. Copy the existing ACL 100 to your text editor
Tips:
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
access-list 100 permit udp any eq 53 any
access-list 100 permit tcp any any established
access-list 100 deny ip any any
3. Verify that the updated ACL 100 on the text editor 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.
Tips:
Let's say you use Notepad as the text editor. On the Notepad, you should have the following
Have the router to be at global configuration mode, like following
Router#
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.
8. When the router does have the updated ACL, reapply the ACL as existing condition back to the interface
Important Note:
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.
When the ACL is applied under specific interface or specific line terminal (i.e. line vty), then the above procedure should be applicable during the router production time. When the ACL is relating to NAT or routing process, then there would be some down time. ACL modification process could also bring in unwanted incoming traffic from the Internet, which might bring down some system. If the down time is unavoidable during production time, verify that the ACL modification process is scheduled being done after hours or off-hours.
Don't forget 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.
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.
feedback form
feedback form
by Phraxos edited by aryoba
last modified: 2009-08-21 15:02:04 |
|
