168.1.3HERE ARE THE STEPS TO FOLLOW IN WALKING THROUGH THE CONFIGU...
192.168.1.3
Here are the steps to follow in walking through the configuration
example, with explanations for clarification after each step as you go
through the commands:
configure terminalinterface ethernet0ip address 192.168.1.1 255.255.255.0This assigns the IP address to ethernet0 interface.
ip nat insideThis designates ethernet0 interface as an inside network.
no shutdownhttps://traloihay.net
This removes the interface from shutdown status.
interface serial0ip address 207.139.221.1 255.255.255.128This assigns the IP address to serial0 interface.
ip nat outsideThis designates the serial0 interface as an outside network.
As in the previous example, this removes the interface from shutdown
status.
interface ethernet1ip address 192.168.2.1 255.255.255.0This assigns the IP address to ethernet1 interface.
This designates ethernet1 interface as an inside network.
access-list 10 permit ip 192.168.1.0 0.0.0.255This specifies that traffic originating from 192.168.1.0 network will be
translated.
ip nat pool net-207 207.139.221.4 207.139.221.126 netmask 255.255.255.128This defines a pool of global IP addresses named net-207 with an
address range of 207.139.221.4-207.139.221.126 to be used for NAT.
ip nat pool net-207-napt 207.139.221.127 netmask 255.255.255.128This defines a single global IP address named net-207-napt with
address 207.139.221.127 to be used for NAPT.
ip nat inside source list 10 pool net-207This specifies that the source IP address of traffic defined in access list
10 will be NAT’d with the IP addresses defined in net-207 pool.
ip nat inside source list 10 pool net-207-napt overloadNetwork Address Translation (NAT) • Chapter 3 12710 will be NAPTed with the IP address defined in net-207-napt pool. NAPT
will occur once NAT has used all available addresses in net-207 pool.
Once a translation has timed out due to inactivity, that global IP address
will be reused for future NAT translations.
ip nat inside source static 192.168.2.2 207.139.221.2 netmask>255.255.255.128Create a static translation for inside IP address 192.168.2.2 to global IP
address 207.139.221.2. Any traffic destined for 207.139.221.2 will be stati-
cally translated to 192.168.2.2.
ip nat inside source static 192.168.2.3 207.139.221.3 netmaskConsiderations on NAT and NAPT
Even though NAT helps to avoid the problem of scarce availability of glob-
ally routable IP addresses, NAT has an impact on the functionality of cer-
tain protocols, therefore complicating their deployment. This section will
outline some of the problems that are associated with NAT.
IP Address Information in Data
Numerous applications fail when packets traverse a NAT device. These
packets carry IP address or port information in the data portion of the
packet. Since NAT only alters the IP header to perform the translation, the
data portion is left untouched. With the aid of an ALG, a work-around may
be provided in some cases. But if the packet data is IPSec secured (or
secured by another transport or application level mechanism), the applica-
tion is going to fail.
Bundled Session Applications
Bundled session applications such as FTP, H.323, SIP, and RTSP, which
use a control connection to establish data flow are also usually broken by
NAT devices. This occurs because the applications exchange address and
port information within control session to establish data sessions and ses-
sion orientations. NAT cannot know the interdependency of the bundled
sessions and would treat each session as if they were unrelated to each
other. Applications like these can fail for a variety of reasons. Two of the
most common reasons for failures are as follows:
■
Addressing information in the data portion of the packet is realm
specific and is not valid once the packet crosses the originating
realm
■
Control sessions create new data sessions about which NAT has
no information. These will fail in many cases.
Peer-to-Peer Applications
Peer-to-peer applications are more prone to failure than client/server-
based applications. Peer-to-peer applications can be originated by any of
the peers; if the peers are located in different realms, NAT translations may
not be established because the host on the inside network is not visible to
the host on the outside network. This is more problematic with traditional
NAT (dynamic NAT and NAPT) where connections are client to server.
IP Fragmentation with NAPT En Route
IP fragmentation with NAPT can occur when two hosts originate frag-
mented TCP/UDP packets to the same destination host, and they happen
to use the same fragmentation identifier. When the target host receives the
two unrelated packets, carrying the same fragmentation id, and from the
same assigned host address, the target host is unable to distinguish which
of the two sessions the packets belong to (due to the translation of the
local source address, to that used in the global NAPT address); therefore,
both sessions will be corrupted.
Applications Requiring Retention of
Address Mapping
When a session is established across realms through the use of NAT, the
translation for that session will eventually time out and then be utilized by
another session’s traversing realms. This can be a problem for applications
that require numerous sessions to the same external address. NAT cannot
know this requirement ahead of time and may reassign the global address
between sessions. For example, if Host A on the inside network has estab-
lished a session with Host Z on the outside network, the application will
function properly. Once the session stops sending traffic and the NAT
timer expires, the translation will be terminated and the global IP allocated
for that specific translation will be used for another translation. What hap-
pens if Host Z requires more data and tries to initiate a session with the IP
Network Address Translation (NAT) • Chapter 3 129address that Host A had while it was translated? At this point, the applica-
tion will no longer function properly.
To remedy this problem, keepalive messages need to be sent between
hosts to keep the translation active. This can be especially annoying and
may not be possible in some situations. An alternative is to use an ALG to
keep the address mapping from being discarded by NAT.
IPSec and IKE
NAT operates by modifying source addresses within the IP header while it
passes through the NAT device. Due to the nature of IPSec, the AH pro-
tocol is designed to detect alterations to an IP packet header. So when NAT
alters the source address information, the destination host receiving the
altered packet will discard the packet since the IP headers have been
altered. The IPSec AH secure packet traversing NAT will simply not reach
the target application.
IPSec ESP encrypted packets may be altered by NAT devices only in a
limited number of cases. In the cases of TCP/UDP packets, NAT would
need to update the checksum in the TCP/UDP headers whenever the IP
header is changed. However, because the TCP/UDP header is encrypted by
the ESP, NAT would not be able to make this checksum update because it
is now encrypted. TCP/UDP packets that are encrypted and traverse a NAT
device will fail because the TCP/UDP checksum validation is on the
receiving end and will not reach the target application.
Internet Key Exchange (IKE) protocol can potentially pass IP addresses
as node identifiers during the Main, Aggressive, and Quick Modes. In order
for an IKE negotiation to correctly pass through NAT, these data portions
would need to be modified. However, these payloads are often protected by
encryption. For all practical purposes, end-to-end IPSec is almost impos-
sible to accomplish with NAT translation en route.
Summary
NAT solves the problem of the limited available supply of global IP
addresses. By implementing a private IP address scheme in a private net-
work, those addresses can then be translated into global IP addresses via a
NAT device. This chapter covered various generic terms used by NAT, vari-
ations of NAT, deploying NAT on a network, and considerations for using
NAT. As I stated at the beginning of the chapter, NAT is not a security fea-
ture and should not be used for security. It simply allows private IP
addresses to be translated into global IP addresses. The myth that NAT
“hides” a network is exactly that, a myth. A company’s ISP may have
knowledge of that private network and can therefore inject a route to that
network in their routing tables, therefore exposing the private network.
FAQs
Q: Should I use NAT or NAPT?
A: It is a good idea to implement both, depending on how many global
addresses are available and how many local hosts need to be trans-
lated. If a NAT pool is implemented, NAPT can then be used once all of
the NAT translations are used up. Once a translation times out, it will
be reallocated to another local host trying to open a session with a host
on the outside.
Q: How do I know if NAT should be used on my network?
A: Typically, NAT must be used if your network is using a private IP
address space and traffic must be routed globally (Internet). Another
instance when NAT would be used is when two companies merge two
LANs that use an overlapping IP subnet.
Q: I have implemented NAT on my network; at different points in time,
hosts are no longer being translated. Why is this happening?
A: Check the number of global addresses in your global pool. The number
of hosts requiring translation may be outnumbering the available
addresses. If this is the case, remove one of the addresses from the
NAT pool and assign that address for NAPT.
Q: RFC1918? RFC2663? What are these?
A: RFC is short for Request for Comments. RFCs are standards that are
published on various topics. For a listing of RFCs, visit https://traloihay.net or
https://traloihay.net (official mirror site for internet drafts and RFCs).
Chapter 4
Cisco PIX Firewall
Solutions in this chapter:
■
Overview of the Security Features
■
Initial Configuration
■
Configuring NAT and NAPT
■
Security Policy Configuration
■
PIX Configuration Examples
■