Network Address Translation
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter discusses the topic of Network Address Translation (NAT): what it is, why it was created, and how you can implement it in FireWall-1. I first discuss the reasons NAT was created and how NAT is implemented in FireWall-1. Next, I show a step-by-step example of how to implement NAT in a network. I then talk about some of the inherent limitations of NAT and discuss a couple of ways to work around these limitations. Finally, I talk about troubleshooting NAT with a packet sniffer.
By the end of this chapter, you should be able to:
- Understand why NAT is necessary
- Identify what NAT actually does
- Identify why NAT does not always work
- Effectively troubleshoot NAT problems with a packet sniffer
- Implement a NAT Configuration
Introduction
Back in the old days of the Internet, the TCP/IP address space (as defined by IPv4, the version of IP used today) was thought to be more than enough. Organizations could reserve their own address space through the Internet Assigned Numbers Authority (IANA, now called the Internet Corporation for Assigned Names and Numbers [ICANN]), and anyone who wanted a block of IP addresses generally got them.
Since the early 1990s, various people have been predicting that the IPv4 address space will simply run out of available addresses. This is partially due to the explosive growth of the Internet, but it is also due to how the IPv4 address space is divided. Many organizations that were allocated address space early on simply have more address space allocated to them than they are using on the Internet. There are also parts of the IPv4 address space that are not legal for hosts to be assigned to on the Internet, namely the multicast (224.0.0.0/240.0.0.0 mask) and the Class E (240.0.0.0/240.0.0.0) address spaces.
As organizations are connecting to the Internet, some are discovering that their internal network does not connect well to the Internet. The main reason for this is usually a conflict in addressing. Long before the Internet was a household word, some corporations set up their internal networks using made-up addresses. However, you cannot simply make up addresses and use them on the Internet. You must use IP addresses assigned by IANA or an ISP. Renumbering a large, internal network would be a daunting task, not to mention that your ISP or IANA is not likely to give you enough addresses to cover all your hosts. Then again, does every host on your internal network really need to be uniquely addressable on the Internet?
IPv6 (the next version of IP) has far more address space—128 bits of address space versus the 32 provided by IPv4—which will solve this problem. However, most of today's Internet is still running IPv4 and probably will be for some time to come. A solution is needed that will help extend the IPv4 address space that is used today.
Network Address Translation does exactly this. It is a technology that allows hosts to transparently talk to one another with addresses that are agreeable to each other. To put it another way, it allows hosts with illegal or private address space to talk with hosts on a public network and vice versa. It is a godsend for network managers who have limited address space or want to make better use of the address space they have without having to subnet, thus reducing the number of IPs that can be used. NAT can also be perceived as a security enhancement because a firewall is required for communication between the hosts. NAT, as it is commonly implemented today, is described in RFC3022.1
NAT is implemented as part of the FireWall-1 Kernel Module that sits between the data link and network layers. As such, NAT can be provided transparently without the client's or the server's knowledge. Application proxies, by their nature, can also provide this functionality, as they originate all connections coming from the internal network. However, proxies usually are not transparent and do not usually give you the level of control you have over FireWall-1's NAT functionality. You can modify the source, destination, and service port of any connection going through FireWall-1.
Consider the following example (see Figure 9-1). Let's say your ISP gives you a /29 block of addresses (net mask 255.255.255.248). If you were to use this address space between your Internet router and your firewall, the address space would break down into the host numbers listed in Table 9-1.2
){kind=link}
Table 9-1 Breakdown of 192.168.0.0/29 address space
|
Host Number |
Description |
|
.0 |
Network identifier (cannot be used by hosts) |
|
.1 |
Internet router |
|
.2 |
Firewall |
|
.3 |
Available |
|
.4 |
Available |
|
.5 |
Available |
|
.6 |
Available |
|
.7 |
Broadcast address (cannot be used by hosts) |
Between the broadcast address, the network address, your firewall, and your Internet router, you have a grand total of four usable IP addresses. With NAT, you can:
Give your e-mail, intranet Web server, and Web server externally reachable IP addresses
Allow all your clients to access the Internet using the firewall's external IP address
Have all of your computers protected by your firewall
Change ISPs without having to renumber your internal network
Figure 9-1 illustrates a sample network.
Figure 9-1 Sample network diagram
Although NAT does add an extra layer of protection and gives you flexibility, there are some downsides to NAT:
Using NAT is like using proxies in that NAT must be updated to handle new applications. As a result, it is not compatible with every application that exists today or in the future.
NAT requires additional work to maintain. This is discussed in more detail in the "Implementing NAT, a Step-by-Step Example" section later in this chapter.
Only so many connections can be hidden behind a single IP address.
NAT requires extra memory and CPU on the gateway. In most cases, this is negligible, but it starts becoming noticeable when over 20,000 connections through a single gateway are subject to NAT.
More information about the disadvantages of using NAT is documented in RFC3027.