8.11 NAT, Firewalls, VPNs, and the DMZ

8.11 NAT, Firewalls, VPNs, and the DMZ

Network address translation (NAT), as previously discussed, is best defined as a supporting firewall technology. In this role, NAT is commonly found as part of a firewall product. The purpose of this section is to describe the integration with NAT and packet filtering. Depending on the firewall vendor, this section may be entirely of an informative nature. For some vendor's NAT implementations, the configuration decisions we are about to discuss are configured with a single checkbox during firewall setup. Other times, NAT must be properly configured and this section describes the issues surrounding NAT.

The discussion in this section assumes an average mid-sized network. As illustrated in Exhibit 13, the network has a single Internet connection, two Frame Relay links to remote offices, and a single DMZ housed off the firewall. On the DMZ, the company has the most common services available, such as a POP3/SMTP relay, a public HTTP server, a public DNS, and a public FTP server. Although the subject has not yet been discussed in depth in this text, we are also going to include a VPN server on the DMZ. The contract signed with the service provider allocates a /28 address space for the 200 local hosts on the company LAN. A /28 network will provide a maximum of 14 usable IP addresses, assuming that the network is not further subnetted. Clearly, NAT is going to be an important technology to allow full Internet connectivity for the internal hosts and the DMZ hosts. The only tricky part about this network diagram is to remember to include the subnet between the access router and the firewall during the NAT design. This segment is an Ethernet segment but will only include two devices on it. ^[7] Nevertheless, it requires a full subnet for proper routing. Many are confused as to whether the addresses for this subnet need to be private or public. The answer, of course, depends on how you configure your NAT. We will find, however, that it permissible to have the DMZ be a public network while still keeping this intermediate subnet in the private range.

Exhibit 13: NAT and the Firewall: Setting the Scene

Based on this topology, there is more than one way to configure NAT to effectively utilize the available address space. The first is to configure the access router with NAT for the entire /28 address space and be done with it. This would allow you to configure the entire network using a private address space. This means that the DMZ would be configured with private addresses, the subnet between the firewall and the router would be in the private address space, and the LAN would be a subnet from the private address space. Access to the each of these networks would be through NAT performed on the router itself. Logically speaking, the network would look like that in Exhibit 14.

Exhibit 14: Using NAT on the Screening Router

For sake of discussion, let us assume that we are using the 172.16.0.0/12 range as the private address range and 200.1.1.0/28 as the public range. This provides a usable address space of 200.1.1.1 through 200.1.1.15 for NAT translations on the access router.

To allow the DMZ services to be reachable from the outside world, you would have to perform static mapping on the access router to map a public IP address to the private address of the device on the DMZ. Thus, the DMZ POP/SMTP relay might have a private address of 172.16.10.10/24. You will advertise the relay in DNS as 200.1.1.10. Thus, when a host wishes to send mail to the mail.proteris.com server, it will send a packet addressed to 200.1.1.10. The access router will have a configuration statement that states that every packet destined to 200.1.1.10 should be translated to 172.16.10.10. Each additional service will also include an identical configuration statement on the access-router with a different public and private address pair. Thus, the HTTP server might be 172.16.10.11 internally and advertised as 200.1.1.11 publicly. The VPN server might be 172.16.10.12 internally and advertised as 200.1.1.12 publicly and so on for each additional service.

Any public addresses not allocated for the one-to-one relationship between a DMZ server and LAN clients connecting to Internet resources will use the remaining nine public IP addresses as part of a pool. Because there are 200 internal LAN hosts, to allow more than nine internal hosts to access the Internet at a single time, NAT with port address translation (PAT) will be utilized.

It is worth noting that in this particular case, there is no need to have the entire /28. A single public IP address would also suffice. Assuming the single public IP address was 200.1.1.1, you would allow the LAN hosts to access the Internet using PAT. The publicly available servers would statically map to the public IP address of 200.1.1.1 and a port. For example, the HTTP server is listening on port 80. You would advertise www.proteris.com as 200.1.1.1. The access router would be configured to translate any packet sent to 200.1.1.1 with a TCP destination port of 80 to translate into 172.16.10.11:80. The SMTP gateway, which listens on port 25, would be advertised as 200.1.1.1 as well, but packets sent to the access router with a TCP destination port of 25 would be translated into a private address of 172.16.10.13:25 instead. This process would be repeated for each internal service running. As long as the destination port for each server is different, there would be no confusion on the part of the access router. Where this system would not work would be if there are two Web servers, each listening on port 80 on the DMZ. In this situation, the access router would not know to translate a packet destined to 200.1.1.1:80 to the first Web server or the second Web server.

While this solution is feasible (and commonly implemented), there are a couple of disadvantages to the current configuration. The first is efficiency. Packets that are NAT'ed naturally have more overhead than an untranslated packet. There is a slight delay in the actual translation, but more importantly, each NAT connection consumes resources on the NAT device. In the case of performing NAT on the access router, all LAN connections must have NAT state information and all incoming DMZ connections must have NAT state maintained as well. Assuming that the public network is moderately busy, at any given point, there could be hundreds of NAT translations active to serve the DNS, SMTP, POP3, HTTP, VPN, and FTP servers.

Our current solution is lacking in that it may also confuse our VPN services. A great deal of detail has not been provided on the configuration of the VPN device. For example, you do not know if this device serves to terminate a remote VPN connection from another company, if it allows remote mobile users to access the corporate LAN, or if serves as a gateway device for our LAN to connect to a larger corporation or business partner. Regardless of the configuration, we will see in the VPN section that VPNs and NAT have a difficult time getting along. The crux of the problem is that a VPN does not like changes to be made to the packets once they are encrypted. NAT, by definition, makes changes to the packet. In this case, no matter the scenario, if we conclude that the VPN server encrypts information and sends it out to the Internet, NAT is in a position to certainly change the packets after they have been encrypted.

A better solution is to utilize the /28 network and subnet it further. If we subnet the /28 network into two /29 networks, we have effectively broken the network block into two smaller networks of six hosts each. One /29 network could be used to address the DMZ. For the DMZ, this would provide an address for the HTTP server, FTP server, DNS, VPN, and SMTP/POP3 servers. That would be five of the six usable addresses taken up and finally one for the firewall interface to the DMZ to utilize all six addresses — just enough. The other six addresses would be used to provide for the NAT pool for the LAN. Utilizing the port address translation feature along with NAT would provide plenty of addresses for translation.

With this design, the network would look like the illustration in Exhibit 15. Note that the subnet between the access router and the firewall is a private address space. This is allowable. As far as routing is concerned, the only function of that subnet is to provide a next hop address from the firewall to the access router or vice versa. From the access router, the /29 public DMZ and /29 public NAT pool is reachable via the IP address of the firewall interface. The access router does not care if the IP address of its directly attached neighbor is public or private. From the point of view of the firewall, it is attached to the public /29 DMZ and the /29 public NAT pool, and the rest of the Internet is reached by sending a packet to the router's IP address. The firewall is not bothered by the fact that it is reaching public IP addresses on the Internet by first sending the packet to a next-hop of a private interface.

Exhibit 15: Using NAT on the Firewall

Along with conserving IP addresses in this scenario, placing the subnet between the firewall and the router in the private address space also ensures that these interfaces of the router and firewall will not be reachable from the Internet. Because the private address space is never advertised to the rest of the Internet, packets can never reach these interfaces from the outside. Of course, the DMZ interface of the firewall is reachable from the Internet, but hopefully our access-filters will be addressing that vulnerability.

This solution is advantageous in all the ways that the previous solution was disadvantageous. The amount of NAT that needs to occur has been minimized. Because services on the DMZ have public addresses, no translation needs to occur for them, thereby conserving both firewall and router resources and improving performance for connections to these sites. Furthermore, our VPN configuration has become easier to manage because the packets are not subject to change after they have been encrypted.

The real disadvantage in this instance is in the utilization of our addresses. We see that by splitting the 14 usable IP addresses in the /28 network in two /29 networks, we end up with two networks of six usable addresses each. We have lost two more IP addresses. Furthermore, our DMZ currently utilizes all six addresses, preventing us from adding any new services to the DMZ. At the same time, the LAN has a NAT pool of six IP addresses. Using port address translation, this is more than enough addresses for our needs.

Unfortunately, the solution to this particular problem has nothing to do with firewalling or information security. It is simply the way that subnetting works. If we wished to add more hosts to the DMZ, we would have to request a /27 from the service provider to be able to allocate the appropriate addresses.

In some cases, if acquiring additional IP addresses from the service provider is impossible, then the entire /28 network could be assigned to the DMZ subnet. From the /28, a single IP address— 200.1.1.15, for example — could be used to NAT for the private LAN using port address translation. Care must be taken in this instance, however, to ensure that the 200.1.1.15 address is not used on any host device in the subnet. You have logically included your LAN subnet in the same subnet as your DMZ, although from a security point of view operation is unaffected because packets entering the router from the Internet destined to the LAN network are translated to the private address before they are routed.

^[7]If this were a full network design, the subnet between the access router and the firewall would be ideal for an intrusion detection system. Because we are focusing on NAT in this discussion, however, we will omit this from the diagram.