Network Address Translation (NAT) is technically what Cisco refers to as translating

one IP address to another. The majority of installations, including most home

networks,
translate many IP addresses to a single address. This is actually called Port
Address Translation (PAT). PAT has also been called NAT Overload in IOS.

To complicate matters, in the PIX OS, NAT is usedin a number of ways that may
not seem obvious. For example, you may have to use a nat statement to allow
packets
from one interface to another, even though they both have public IP addresses,
and would normally require no translation.

NAT Commands
nat
The nat commandis usedwhen translating addresses from a more secure interface
to a less secure interface. For example, if you needed to translate an address
on the inside of your PIX to an address on the outside, you would use the nat
command. Private IP addresses on the inside of a PIX are translated to one or
more public IP addresses using the nat command. (Technically, the addresses do
not need to be private and public addresses as described by RFC1918. The PIX
documentation uses the terms “global” and “local” to describe addresses seen
outside the PIX as opposed to those seen inside.)

static
The static commandis usedwhen translating addresses from a less secure interface
to a more secure interface. For example, if you hada server inside your PIX
that needed to be accessed from outside, you would assign a public IP address to
the private IP address of the server using the static command.

global
The global commandis usedfor PAT configurations where many addresses are
translated to one address. It is also used to provide a pool of NAT addresses.
This command is used in conjunction with the nat command.

For these examples, I will be using 10.0.0.0 to represent a publicly routable IP

network, and 192.168.1.0 as a private, unroutable network.

Simple PAT using the outside interface

One of the most common scenarios for a firewall is providing an office with protection
from the Internet. Assuming that all nodes inside the firewall require access to the
Internet, andno connections will be initiatedinbound , a simple PAT configuration
can be used.

Here, I’ve configured the outside interface to be used as the IP address for the global
PAT. In other words, all packets that originate from the inside will be translated to
the same IP address as the one used on the outside interface of the PIX:

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

All internal IP addresses will be translated because the nat statement

references 0.0.0.0, which means all addresses.

Simple PAT using a dedicated IP address

Older releases of the PIX OS (before 6.0) did not allow PAT to be configured using
an interface. This was a problem for installations with limited public IP addresses.

To accomplish PAT without using the interface’s IP address, use the same
configuration
as the previous one, but specify the IP address used for the global PAT in the
global command instead of the keyword interface:

global (outside) 1 10.0.0.5

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

Simple PAT with public servers on the inside

Small installations may have a server inside (not on a DMZ) that must be accessible
from the public Internet. While this is usually not a goodid ea, it is nevertheless a
distinct possibility that you’ll need to configure such a solution. Smaller companies—
andeven home networks—often require such configurations because a DMZ
is either impractical or impossible.

Here, I’ve designed a global PAT using the outside interface, with all addresses from
the inside being translated. Additionally, I’ve created two static entries. The first
forwards packets sent to the public IP address 10.0.0.10 to the private IP address
192.
168.1.10. The second translates 10.0.0.11 to the private IP address 192.168.1.11:

global (outside) 1 interface

nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) 10.0.0.10 192.168.1.10 netmask 255.255.255.255 0 0
static (inside,outside) 10.0.0.11 192.168.1.11 netmask 255.255.255.255 0 0

static statements override the more generic nat statement, so these commands can
be usedtogether in this way without issue. Be wary when configuring static
statements,
however. The order of interfaces and networks can be confusing. If you look
carefully at the preceding example, you’ll see that the references are essentially:
(inside-int,outside-int) outside-net inside-net

Remember that these static statements are allowing connections from outside to
come into these two IP addresses, which reside inside the secure network. This may
sound dangerous, but because the outside interface has a security level of 0, and the
inside interface has a security level of 100, traffic cannot flow from outside to inside
unless it’s permitted with an access list.

In other words, an access list must now be created to allow the desired traffic to
pass.

Port redirection

Port redirection is different from Port Address Translation. While PAT translates a
pool of addresses to a single address by translating the ports within the packets
being
sent, port redirection does something else entirely.

Port redirection allows you to configure a static NAT where, though there is one IP
address on the public side, there can be many IP addresses on the private side, each
of which responds to a different port. PAT does not permit inbound connections.
Port translation does.
Imagine you have only eight IP addresses on your public network, which are all in
use:
.0 – Network address
.1 – ISP Router VIP (HSRP)
.2 – ISP Router 1
.3 – ISP Router 2
.4 – Primary PIX
.5 – Secondary PIX
.6 – Web server public IP
.7 – Broadcast address

While it might not seem realistic to have so much resilient equipment on such a
small network, you might be surprisedwhat happens in the field. Many small business
networks are limited to eight addresses. In reality, many don’t need any more
than that.

In this example, we only needto have one static NAT configured—the web server.
Here is the configuration relating to NAT:
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) 10.0.0.6 192.168.1.6 netmask 255.255.255.255 0 0

This configuration works fine, but what if the needarises for another web server to
be available on the Internet? Say a secure server has been built using HTTPS, which
listens on TCP port 443. The problem is a lack of public IP addresses. Assuming that
the original web server only listens on TCP port 80, we can solve the problem using
port redirection.

Using capabilities introduced in the 6.x release of the PIX OS, we can specify that
incoming traffic destined for the 10.0.0.6 IP address on TCP port 80 be translated to
one IP address internally, while packets destined for the same IP address on TCP
port 443 be sent to another IP address:
static (inside,outside) tcp 10.0.0.6 80 192.168.1.6 80 netmask 255.255.255.255
static (inside,outside) tcp 10.0.0.6 443 192.168.1.7 443 netmask 255.255.255.255

Normally, the static command includes only the outside and inside IP addresses,
andall packets are sent between them. Including the port numbers makes the static
statement more specific.

The result is that packets destined for 10.0.0.6 will be translated to different IP
addresses internally, depending on their destination ports: a packet sent to
10.0.0.6:80
will be translatedto 192.168.1.6:80, while a packet destinedfor 10.0.0.6:443 will be
translated to 192.168.1.7:443.

DMZ
Here is a very common scenario. A company has put a PIX in place for Internet
security.
Certain servers needto be accessedfrom the Internet. These servers will be in a
DMZ. The outside interface connects to the Internet, the inside interface connects to
the company LANs, andthe DMZ contains the Internet-accessible servers.

From a NAT point of view, we must remember that the security levels are important.
The outside interface has a security level of 0, the inside interface has a level of
100, and the DMZ has a level of 50.

In this case, we want the servers in the DMZ to be accessible from outside. We also
want hosts on the inside network to be able to access the DMZ servers, although the
DMZ servers should not be able to access the inside network.

First, we needthe nat and global statements for the inside network using the Internet:

global (outside) 1 interface

nat (inside) 1 192.168.1.0 255.255.255.0 0 0

Specifying a specific network, rather than using 0.0.0.0 as the address in the nat
statement, ensures that only that network will be able to access the Internet. Should
other networks that need Internet access be added internally, they will need to be
added to the PIX with additional nat (inside) 1 statements.

Now, we needto addthe static statements so the servers on the DMZ can be
accessed from the Internet:

static (DMZ,outside) 10.0.0.11 192.168.100.11 netmask 255.255.255.255

static (DMZ,outside) 10.0.0.12 192.168.100.12 netmask 255.255.255.255
static (DMZ,outside) 10.0.0.13 192.168.100.13 netmask 255.255.255.255

By default, the DMZ will not be able to access the inside network because the DMZ
has a lower security level than the inside network. In this case, we must use a static
statement to allow the connections. Where it gets a little strange is that we don’t
needto translate the source network; we just needto allow the connection. As odd
as it sounds, to accomplish this, we must statically NAT the inside network to itself:

static (inside,DMZ) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

A PIX firewall must translate a higher-security interface for the network to be seen by
a lower-security interface. This can be confusing because doing this creates a
“translation,”
even though nothing is being translated. The PIX must have a translation in
place for the hosts on the inside network to be able to connect to the hosts on the
DMZ. The IP addresses do not need to be changed, but the path needs to be built.

Once NAT is in place, all that’s left to do is configure access lists to allow the
required traffic from the DMZ to the inside network.