Republished with permission from WatchGuard Technologies, Inc.


How and When to Use 1:1 NAT

by David M. Piscitello, President, Core Competence, Inc.

Network Address Translation (NAT) was originally designed as one of several solutions for organizations that could not obtain enough registered IP network numbers from Internet Address Registrars for their organization’s growing population of hosts and networks. NAT was initially a stop gap measure: it would temporarily allow continued Internet growth while a new version of IP, with a new and considerably larger address space, was deployed. Nearly 10 years later, we’re still waiting for IPv6, and NAT is now used virtually everywhere, by everyone.

The acronym NAT (pronounced as a word, not as initials) is generically used to describe any of the several forms of IP address and port translation. Its primary purposes are to stretch the number of computers able to work off of a publicly routable IP address, and to hide the private IP addresses of hosts on your LAN. In this article, we’ll examine 1:1 (pronounced "one to one") NAT, distinguish it from other NATs, and explain when and how to use it.

Do You Mean PAT, Dynamic, 1:1 or Static NAT?

Network Address Translation is a steaming kettle of acronym soup. As a Firebox or SOHO user, you should know which terms WatchGuard uses and what they mean.

You probably already use Dynamic NAT from your trusted to external networks. This NAT technique, also called Network Address Port Translation (NAPT) or Port Address Translation (PAT), dynamically maps all the private addresses used on your trusted network onto a single public IP address that you assign to your firewall’s External interface, as follows:

  • A host on your trusted network sends a packet out with a private source IP address, (e.g.,,,  This packet also carries a source port number (e.g., 3506).

  • When the firewall receives the packet, it changes the private source IP address to an external, public IP address (e.g.,

  • The firewall also changes the source port address (3506) to an unused source port on the firewall (e.g., 6000) and maintains mapping information in its memory so it can process response packets.

  • When a response packet destined for is received by the firewall, it is mapped back to the private source IP and port that sent the first packet in this TCP connection or UDP stream.

To the world outside, it appears as if every host on your network shares the same public address. How economical. Hundreds, even thousands of hosts can share the same public address. This is also called IP masquerading in security circles, which means one technique is known by four terms. To review (for those of you who tuned in late): Dynamic NAT, Network Address Port Translation (NAPT), Port Address Translation (PAT), and IP masquerading mean essentially the same thing.

Static NAT is much simpler to explain: the firewall binds one unique public address to each privately addressed host, and forwards traffic between the real address of a computer on your trusted or optional network and a public (or, as we say, NATted) address on the external network. So, for example, private address is presented to the world as public address, private address is presented to the world as public address, and so on. Using static NAT, you can forward one or all ports to a server behind your firewall. WatchGuard deviates a bit from general security industry terminology by using the term "static NAT" only to refer to forwarding one port to a single server, and using the term "1:1 NAT" to refer to forwarding one address to a single server.

1:1 NAT is simpler than port forwarding, the static NAT technique that can be used to selectively map individual ports to individual servers. Unlike dynamic NAT, 1:1 NAT provides no addressing economy. However, 1:1 NAT is useful when you want to protect your public-facing server from attacks firewalls are generally designed to defeat.

When 1:1 NAT is appropriate

While Dynamic NAT is perfect for outbound connections initiated by client computers protected by your firewall, it won’t help you when you want to make servers available for inbound connections from any Internet user. Since Dynamic NAT presents all your internal IP addresses to the world as the same single IP address (your Firebox’s External address), in most cases when new connection requests from the outside hit the Firebox, it (silently) discards them. But what if you want the world to access services on public IP addresses other than your Firebox’s External address? If you need to make only one service externally visible, you could use port forwarding (send inbound port 80 requests to one inside Web server, for example). But in many cases -- for example, if you run a server that provides HTTP, SSL, and FTP services to clients on the Internet -- you will need to make several ports and possibly several servers externally visible.  Generally speaking, your public-facing servers need their own public addresses -- that is, they need to be 1:1 NATted.

With 1:1 NAT, you can bind a public address for each Web and other (DNS, mail) server to the private address you assigned to each server located on your trusted or optional networks. So, in a nutshell, Dynamic NAT is generally useful for hiding addresses of internal hosts when they access public services ; 1:1 NAT is useful for permitting public hosts access to internal servers.

Before you 1:1 NAT, take time to consider what must be done to secure public-facing servers:

  1. Consider placing public-accessible servers on your Optional interface, separated from servers (and clients) operating on your trusted networks. This separation protects against attacks from one compromised server to another. Don’t worry, client computers on your trusted networks will be able to access servers on your Optional interface.
  2. Apply all OS updates, security patches, and hot fixes, and “harden” your OS against attacks, then install server grade anti-virus and system integrity software such as ServerLock.

  3.  Disable all services you don’t explicitly wish to make available on your public servers, especially file access and sharing services. And of course, remove any information that is sensitive or useful to an attacker.

  4. Where possible, use separate servers to host public Web, DNS, and SMTP mail services. This separation, coupled with previously stated measures, protects against an attacker who has gained administrative privileges through one service (e.g., SMTP mail) from gaining control of and misusing other essential services (e.g., public DNS).

  5. Configure your Firebox to limit access to only those services you wish to make public on 1:1 NATted servers.

This is admittedly the 50,000 foot view of preparing a public server, but this column is about NAT. Plenty of resources on the Web can provide you details of how to diligently pursue the steps above.

Setting up 1:1 NAT

Now that we know what 1:1 NAT is and what it’s good for, let’s set up a public Web server. Assume that we’ve created a DNS entry that binds to the public IP address, which we are going to represent as our external IP address for 1:1 NAT. In reality, this Web server is connected to the Optional interface of our Firebox, listening for HTTP requests sent to the private IP address

From the Policy Manager’s Menu Bar, choose Setup, then NAT… Click on the Advanced… button in the NAT Setup window. (If Enable Dynamic NAT is checked, leave this setting alone, since it is the default NAT policy for all hosts behind your firewall.) From the 1-to-1 NAT Setup Tab, select Enable 1-to-1 NAT, then choose Edit… Select External as the interface, then select the number of servers you want to NAT. To keep this example simple, we’ll NAT one server on our trusted network. The server’s private address,, is the Real Base. An unused public IP address,, is the NAT Base.

Your 1:1 NAT is now established, but you must still create an exception policy to your default Dynamic NAT. If you don't, when the outside world sends packets to (the public-facing 1:1 NAT IP you've just set up), your Firebox will dutifully perform Dynamic NAT (since that’s the default policy), and your server's responses will say they come from your Firebox's IP address. This bad practice can create undesired results. But using the Firebox's Dynamic NAT Exceptions feature, you can allow your server to show its 1:1 NAT IP, instead of the Firebox's external IP. Here's how to do it. From the Dynamic NAT Exceptions tab, choose Add… then add an exception from to external.

Your 1:1 NAT is now configured to map all inbound connect requests to this server. Since is a Web server, you would configure your Firebox to further restrict server access to Web only: for our purposes, we’ll add Filtered-HTTP (80) and HTTPS (443) services. For both services, enable and allow incoming traffic received on the public IP address If your server must communicate with other public servers, you must enable and allow outgoing traffic from this server. Enable logging. Reboot your Firebox and test your configuration.

Common errors when configuring 1:1 NAT

If you’re familiar with the network configuration of your Firebox, you know about Aliases for the External Interface. You may be tempted to create aliases for all the public IP addresses you’ll use in 1:1 NAT. I was. However, aliases have nothing to do with configuring 1:1 NAT. Aliases are used to add external IP addresses to the Firebox itself, not to a server. WatchGuard Technical Support reports that failing to create the Dynamic NAT exception rule is another common error. And remember, 1:1 NAT is exactly that. You can’t map two public addresses onto a single private address. Finally, you can’t assign a public IP address that you have used in 1:1 NAT to any other system in your trusted or optional networks.


Some "DMZ" configurations place public servers outside a firewall and behind a WAN access router. In such configurations, you must rely on router packet filtering to protect your servers. Your Firebox can do a much better job protecting your public servers than WAN access routers can, and 1:1 NAT makes the task very easy. ##


Frequently Asked Questions: Network Address Translation (accessible to LiveSecurity subscribers only)

Online Training: Using Network Address Translation

Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.

Copyright © 1996 - 2002 WatchGuard Technologies, Inc. All rights reserved.