This section contains NAT configuration examples for a single
virtual router configuration and NAT translation between two virtual
routers.
NAPT Example
Figure 6 illustrates a NAPT
configuration for a private network with two inside subnetworks, a
field office, and a corporate office.
Both offices use private addresses. The corporate
office has a dual T-3 link and a public FTP server that has a global
address (that is, it does not need translation).
Figure 6: NAPT Example
The address pool consists of three addresses (the
number of addresses is small, because NAPT is used). Addresses matching
the private address spaces of the corporate and field subnetworks
are translated to global addresses from the pool through NAPT.
Note:
Null route applies to 192.32.6.0–192.32.6.3, which do
not exist in the address pool
All hosts that use private addresses in both the
field office and the corporate office must have their addresses translated
to one of the three addresses in the pool. Because this example uses
NAPT, the interface can use only one pool address, depending on the
number of inside hosts attempting to access the outside at any given
time.
Bidirectional NAT Example
Figure 7 illustrates how
outside hosts can initiate conversations with inside hosts through
the use of a DNS server that resides on the inside network.
The inside realm uses basic NAT. The inside network
uses a mix of private subnetwork address space (192.168.22/24) and
registered public addresses.
Note:
Null route applies to 192.32.6.0 and 192.32.6.1, which do not
exist in the address pool.
Twice NAT Example
Twice NAT is often useful when the inside network
is using a nonprivate address space (unregistered usage of global
address space) and you want it to connect to the public network. Inside
local addresses need to be translated to legal global addresses. Legal
addresses from the outside that overlap those used on the inside network
need to be translated to unused and recognizable addresses in the
inside network. Both inside source and outside source translations
must be configured on the NAT router.
Figure 8 illustrates how
the inside network is using the unregistered global address space
of 15.12.0.0/16. Outside hosts whose addresses overlap with this subnetwork
that want to access the inside network need their global addresses
translated.
Figure 8: Twice NAT Example
To configure this example:
Enter the correct virtual router context.
host1(config)#virtual-router blue
Mark the inside interface.
host1:blue(config)#interface fast-ethernet
6/1
host1:blue(config-interface)#ip nat inside
host1:blue(config-interface)#exit
Mark the outside Interface.
host1:blue(config)#interface atm 3/0.20
host1:blue(config-interface)#ip nat outside
host1:blue(config-interface)#exit
Create the address pool for inside source translations.
host1:blue(config)#ip nat pool entAoutpool
12.220.1.0 12.220.255.255 prefix-length
16
Note:
This pool is purposely smaller than the size of the company
network because not all private hosts are likely to access the public
network at the same time.
Create the access list for addresses eligible for dynamic
translation.
Note:
An inside host cannot directly access hosts on the outside network
that use addresses that overlap with the inside subnetwork. However,
by using outside source translation and DNS name resolution, the NAT
router can install translations so inside hosts can access these outside
hosts by using nonoverlapping addresses.
In MPLS VPN configurations, you might want to offer
public Internet access to VPN subscribers. MPLS VPNs are enabled through
the use of VRFs. If a VPN is using a private or overlapping address
space, you can use NAT to enable access to the public network because
the NAT implementation is both VR and VRF aware. Figure 9 illustrates how the subscriber interface feature of the router
is used in conjunction with NAT to connect the VPNs to the public
network.
Figure 9: Cross-VRF Example
VRF11 is the local (this PE) representation of
the MPLS VPN and connects enterpriseA to the VPN. Enterprise A communicates
to VRFs in other PE devices (the rest of the VPN) through RFC2547bis
(MPLS VPNs). VR1, of which the VRF is administratively a member, represents
the public network. The interface to EnterpriseA is marked as an inside
interface. The normal steps for configuring inside source translation
are applied. A subscriber interface is created off the uplink to the
core network and anchored in the VRF. A DA-based demultiplexer matching
the inside global address range is configured on the subscriber interface.
The subscriber interface is marked as an outside interface.
To configure this example:
Enter the correct virtual routing and forwarding instance.
