Back to NSC NAT Home Page

The NetNAT
By Network Safety

Network Safety manufactures a line of tools that assist organizations and individuals to leverage their access to the Internet. The NetNAT is one of these tools.

Overview

The NetNAT is a powerful Firewall IP Router that connects one or more "private" networks with a "public" network. In the process, all information about the private network is obscured, including the IP Addresses in use, the topology of the private Enterprise Network, and the number of hosts or workstations. The number of external "registered IP Addresses" is drastically reduced, and the security of internal hosts is greatly enhanced. The Net NAT is available with a variety of LAN interfaces, and can be supplied with an RFC 1490 Frame Relay Interface for 56Kbps or T-1 connection.

Firewall Specifications

The Net NAT performs high-speed packet-level filtering like a traditional router, and adds application-level filtering for additional security. Unlike a router, the Net NAT needs no special configuration to keep out the Bad Guys. By default, the Net NAT lets you do anything, but lets the "outside" do nothing. Other safety functions include prevention of ping or traceroute from the outside, as well as simple configuration of traps for invasion attempts.

Internet Access Control

Your users want the Internet, but you need to keep control. The next version of the Net NAT has exclusive features to give you that control.

Network Address Translation

In addition to traditional firewall functions, the Net NAT performs enhanced RFC 1631 Network Address Translation. This assists organization use of the RFC 1597 private internet addresses. All features detailed in RFC 1631 are supported, including: In addition, the Net NAT expands upon the NAT standard with:

Internet Access Control

This soon-to-be-released feature categorizes your workstations and hosts into control groups with default access rights. These rights may be anything from "none" to "unlimited." Any access attempt that exceeds the rights is rejected and optionally logged. Current status of your defined groups is available from your Web browser.

Conversion of IP Addresses

The main feature of an RFC 1631 NAT is to enable an organization to use the free IP Networks reserved in RFC 1597 while still permitting clients or servers on this network to access, or be accessed by, the public Internet. It does this through a mechanism that substitutes a globally registered IP Address into the source IP Address part of a message leaving the private network, and restores the private IP Address into the destination part of a reply message entering the private network. For example, assume a translate table of the following nature:

Name

Private IP Address

Public IP Address
ws12 192.168.16.12 204.116.73.1
ws26 192.168.16.26 204.116.73.2
ws27 192.168.16.27 204.116.73.3
ws59 192.168.16.59 204.116.73.4

A message originating at ws12 has 192.168.16.12 in the Source IP Address part of the message header. As it passes through the NAT to the Public Internet, the NAT substitutes 204.116.73.1 into that part of the header and recalculates the various message checksums. The message is then sent to the addressed host on the "outside" as though it originated from the public address. When a message arrives at the NAT from the Public Internet addressed to 204.116.73.1, the private IP Address of ws12 is substituted into the destination part of the message header, the checksums are recalculated, and the message is delivered to ws12.

Even though the four workstations in this example are spread across a wide section of the internal RFC 1597 Class C Network (192.168.16), their Public IP Addresses have been consolidated into a very small section of the external IP Network.

We Prefer Actual and Apparent

Instead of Private IP Addresses (or "reusable addresses" from RFC 1631) we prefer to call them "Actual Addresses." In the same light, we call the Public IP Addresses (non-reusables from RFC 1631) "Apparent Addresses." This seems much more understandable, and is less limiting. Many NATs are used in large Enterprise Networks that are not connected to the Public Internet, and so have no "non-reusable" addresses at all.

Correct Handling of FTP and ICMP Messages

Some of the NAT function would be much simpler if IP Addresses were only found in headers. But, several application protocols and the Internet Control Message Protocol carry IP Addresses in the message data. If a NAT is to work with these protocols, it must identify the protocol, find the embedded IP Address and fix it there, as well as in the header. Needless to say, the creation of protocols that do this should be discouraged or standardized to make the process more robust.

Dynamic Concentration of IP Addresses

An examination of the address translation table above will explain the first enhancement made to the RFC 1631 NAT. Instead of a fixed actual-to-apparent mapping, a pool of apparent addresses is created, and then dynamically assigned to the actual users. The assignment is temporary, so that apparent addresses can be used by other actual users.

Several other vendors of NAT products do this. We chose to do it differently. Please read on!

Conversion of TCP and UDP Port Numbers

The thought of tying up a large range of apparent IP Addresses seemed very silly to us, so we built the Net NAT to perform a different kind of concentration. Instead of translating just the IP Address, we also translate the TCP or UDP Port Numbers. These are also called service numbers. In our version of the address translation table, there is only one entry, and that is a single Apparent IP Address. And, instead of a pool of apparent addresses, there is a pool of "Apparent Ports."

So, when a workstation in the private network initiates a TCP session or a UDP exchange, the Net NAT assigns a port from the apparent port pool and then substitutes the apparent address and port for the actual address and port before sending the message to the public network. In a similar way, the apparent address and port in a message from the public network are replaced with the actual address and port before the message is passed to the workstation. The actual addresses may be RFC 1597 private addresses, or someone else's public addresses that were used before a connection to the Public Internet was anticipated, and must be kept due to inertia.

This permits the sharing of a single Apparent IP Address between a very large number of actual users. In practice, the number of users is virtually unlimited. The true limit is in the number of simultaneous sessions. That is limited by the size of the apparent port pool and the memory available for session context blocks.

Creation of Virtual Servers

The Net NAT can provide support for servers in the private network that need to be "seen" from the public network. Two modes are available for this function. We call them Fixed, Port, and Mux.

Fixed Server Mapping Mode

Fixed mode is the equivalent of the RFC 1631 conversion described above. In this mode, a table defines a fixed relationship between apparent and actual addresses. No translation of port number is performed in this mode, since that isn't required.

Port Server Mapping Mode

Port mode is very similar to Fixed Mode, except that the fixed relationships are between combinations of apparent address and port and actual address and port. Thus, the port number is added to the translation process. Consider this new table:

Name

Actual Address and Port

Apparent Address and Port
ser12 192.168.16.12 80 204.116.73.1 80
ser26 192.168.16.26 80 204.116.73.2 80
ser27 192.168.16.27 80 204.116.73.3 80
ser59 192.168.16.59 80 204.116.73.4 80

This looks a lot like our earlier table, except that only the specified services are permitted in. This example shows 4 WWW Servers on the inside that are to be offered to users on the outside. In practice, the table also includes the higher-level protocol (TCP or UDP) so that the Net NAT may discriminate to that level. For a far more interesting configuration, consider:

Name

Actual Address and Port

Apparent Address and Port
ser12 192.168.16.12 8000 204.116.73.1 80
ser12 192.168.16.12 8001 204.116.73.2 80
ser12 192.168.16.12 8002 204.116.73.3 80
ser59 192.168.16.59 23 204.116.73.1 23

This shows three publically-visible WWW Servers on apparent addresses 1-3, and an inbound telnet destination sharing the first apparent address. While the outside "sees" three separate WWW Server "machines," there is really only one "machine" on the inside. There are, however, three separate WWW Server processes running on that machine, using ports 8000 through 8002. There is probably also one on port 80 for the internal users, but that doesn't need to be in the table. It's interesting to note that WWW requests to apparent address 1 go to machine ser12, while telnet requests go to machine ser59. This allows very tight securing of the network by directing telnets to a secured telnet proxy and keeping telnet accounts off of the WWW Server.

Mux Server Mapping Mode

Mux Mode is much like Port mode, in that an external combination of IP Address and port is converted into the internal world. Unlike Port Mode, and unlike any other established product, our Mux Mode maps the incoming service requests across an array on internal servers. This lets you distribute the service load across multiple server platforms. We sold this separately as our WebMUX product since 1994, but have added it our standard NAT products at no extra charge. A NAT performing Mux Mode mapping may do all of our other NAT functions at the same time.

Support for Great New Applications

The Public Internet is an exciting environment for us all. What is fueling the stunning growth is the array of wonderful new client/server applications, and new browsers for older applications. Running some of these new applications through a NAT device can be a real challenge. We mentioned the kind of problem that one encounters in our discussion of embedded IP Address and Port information. We will teach the Net NAT to deal with these applications if we can. A notable example (and a wonderful product) is Realaudio from Progressive Networks. The potential of this product encouraged us to add specific modifications to the Net NAT. Check it out!

This page was last modified on December 6, 1995.

This information is proprietary to Network Safety. Network Safety, WebElite and NetNAT are trademarks of Network Safety. For information on our products and services, please contact our sales department. This page was prepared using WebElite, our professional editor for the Web.