The terms tunneling and NAT come up fairly regularly now in networking conversations. Over time, these techniques have become invaluable in the face of an IP v4 address space shortage and in facilitating secure internetworking across the public Internet. Both methods are vital to internetworking and are not at all mutually exclusive in their implementations. We can use both techniques within the same router configurations for access to intranets, extranets, and the Internet.

The key is to configure these methods together. In this Daily Drill Down, I’ll show you how to configure these two methods together in order to get tunneling and NAT to complement one another and provide multiple paths between networks.

So many questions
With NAT, we can transform an address originating from a private network host into a valid public IP, thereby allowing access between private and public networks (i.e., the Internet). With tunneling, we can direct packets from the aforementioned private network across a public network to another private network attached to the same public network. Mind you, the features and functionality provided with NAT and tunneling are by no means limited to this. These are only somewhat common uses of the methods. The issues I’ll address are based on these uses. How and why would we use both simultaneously? What if we want to provide general Internet access to private network hosts and a secure tunnel between private networks across the Internet? Which do we do first: translate the address before sending it down a tunnel to another office or encapsulate it? Do we even want to NAT sessions that are bound for our other private network? Let’s take a deeper look into these concepts.

VPN: A better understanding

If you need more information on VPN technology, take a look at Debra Littlejohn Shinder’s ”Understanding and troubleshooting virtual private networking” or Talainia Posey’s ”Understanding virtual private networking.”

To better understand our topic, we must examine some of the details to determine how best to design such an implementation. The process of tunneling implies encapsulating or wrapping one protocol within another. Often, the terms VPN, tunneling, and encryption are used in conjunction. In fact, a VPN consists of two basic concepts: tunneling and encryption. In this case, we’re encapsulating the packets bound from one private network to another so that they can be carried across the Internet. Otherwise, these private address packets couldn’t be routed across the Internet’s public address infrastructure. With respect to tunneling, we must designate endpoints for our tunnel.

Cisco IOS

If you’re not familiar with the Cisco IOS firewall, take a look at Robert McIntire’s ”Securing the Edge: Advanced networking with the Cisco IOS firewall.”


NAT and IPSec information

The configuration information provided here is not meant as an in-depth example of IPSec or NAT setup but rather to provide an overview focused on attaining interoperability. For more information on NAT, take a look at Debra Littlejohn Shinder’s ”Selecting the best address translation option for your network,” and for an in-depth look into IPSec, take a glance at her ”Configuring IPSec on Windows 2000 Professional” Daily Drill Down.

Figure A
Our Cisco routers will handle both tunneling and NAT between the external and internal networks.

In this case, we’ll assume the use of two Cisco access series routers running the IOS IP/Firewall Plus IPSec 56 software as the endpoints for our tunnel (see Figure A).

Each connects one of our private networks to the Internet. With both the firewall and IPSec feature sets, we can provide firewall security for the private network and tunnel encryption across the Internet to the remote private network. Since we have both inside and outside interfaces on our edge or access routers, which do we designate as the tunnel endpoint? Actually, the outside interfaces that connect to the Internet will be used as peers in our scenario. Here’s a partial configuration highlighting the IPSec configuration for Router A.

And this is the partial configuration for Router B.

On both routers, the outside interfaces are Ethernet0/1, and the addresses are and for routers A and B, respectively. The inside interfaces are Ethernet0/0 on both; the private address spaces are and, respectively. Notice in the first few lines of both VPN peer router A and B configurations that we create a new Internet Key exchange (IKE) policy with the ISAKMP statements, a requirement for IPSec. To do so, we specify the hash and the authentication type (a pre-shared key of a-b-vpn in our scenario), along with the address of the peer VPN router. Then we create a name for our IPSec transform set, tset-1. This transform set name is referenced later in the set transform statement. The crypto map specifies a name for the map, cmap-1, and puts us into Crypto configuration mode. Also, this map name is also referenced in the Ethernet0/1 (outside interface) configuration.

The next several statements complete our tunnel configuration. The last statement in this section is the one that makes all the difference. The match address statement is entered in crypto config mode and references an access list, 101, which specifies what traffic we want to direct down our VPN tunnel. Access list 101 on each router includes a statement to allow traffic to the other private network ( <–> 192.1068.2.0) via the tunnel and excludes all other traffic. This is one step in solving the problem of how we selectively direct private, interoffice traffic down our tunnel.

Access list basics

Need more information on Cisco access lists? Take a look at Lance Cockcroft’s ”Using Cisco access lists to increase network security.”

Now it’s time to look at how this works in conjunction with NAT for simultaneous access to both the Internet and the interoffice WAN. In NAT configurations, we must specify inside and outside interfaces. Allowed traffic coming from the inside is generally translated using a public IP pool as it heads for the outside interface. If this session is bound for the Internet to surf a Web site, we want to translate it to a valid address and direct it to the default route. However, our private networks employ private addressing, and we don’t want to translate the addresses of packets passing between our two private networks down the tunnel across the Internet. Figure B illustrates two machines on our internal network using NAT.
Figure B
Machine routes to the external network only; machine routes to the internal network only.

Since the packets are encapsulated at one end and unencapsulated at the other end of the tunnel, we don’t really need to NAT this traffic. But can we selectively NAT? We can use a standard access list to control which private host addresses get NATed by source address, but that isn’t really the functionality we’re looking for. The key here is to maintain our private addresses with respect to data tunneled to the other private network but to NAT the address if headed for public Internet access. To do so, we can use an extended access list to specify which traffic gets NATed by destination, which is what we’re looking for. Note the following NAT and access list-related portion of the configurations for Router A and Router B.


In the first line of the NAT configuration, we perform a dynamic NAT mapping from the inside interface to the outside interface, Ethernet0/1. In this statement, we specify the un-nat route map. The third line is the default route to the ISP. And then we have our access list, 102, controlling which traffic gets NATed in conjunction with the aforementioned dynamic NAT map statement. All private traffic from Router A ( to Router B’s private network ( is explicitly denied and excluded from the NATing process. The second access list statement allows any traffic from A’s private network to the Internet. The next entry creates the route map, un-nat, referenced in the previous dynamic NAT map statement. This places the router into route map config mode, where we set the matching IP address based on access list 102. The same is true for Router B. Now this is what we’re looking for. With the proper NAT configuration, we can configure our access/VPN router to handle private and public traffic in the appropriate manner.

Allowing VPN traffic
The one thing that we have not looked at yet is the final detail. Chances are we have either the IOS firewall or an access list configured to restrict incoming traffic at the outside interface of both access routers. For this scenario, we’ll assume that an extended access list guards the outside interface. We’ll need to make a hole to pass the VPN traffic. To do that, we’ll specify the IKE and IPSec protocol information for Router A and Router B. The protocol identification numbers required are 50 and 51, and the port is UDP 500.


Naturally, these access list entries should be placed at or near the beginning of your ACL since these routers will be hosting a dedicated tunnel between them. By doing so, you decrease the processing load incurred by the inbound access list.

Although an in-depth discussion of IPSec and NAT is not the aim here, we begin to see how these features can be configured to work together to handle network traffic appropriately, whether private or public. By configuring NAT and tunneling together in our networks, we can leverage our investment in Internet connectivity. In this manner, we not only use our Internet link for general Internet access from and to private application servers and clients, but we gain the additional benefit of a secure WAN link between our remote private networks.

The cost advantages can be compelling. So compelling that VPNs, once considered a security risk, have become more and more prevalent as encryption technology has improved over the years. An even more compelling fact is that implementation is becoming easier as manufacturers continue to develop all-in-one security appliances and VPN configuration tools that can assist network administrators when deploying Internet connectivity, as well as secure VPN tunneling technology.