Creating a dual NAT lab gateway router


Often times during an infrastructure project you need to create a quick mirror network environment to stage equipment or systems that will later be moved into production networks.  But having to go sit in the lab plugged into the lab isn’t always an option for efficient work-flows!

These setups typically are:

- short-lived environments that will be destroyed when the systems are moved to production

- duplicates of current VLAN(s) and IP address space(es)

- should not require any changes to the production network to accommodate their creation and deletion

Typically you have to go “plug in” to the sandbox to work.  Or you have to establish separate VPN gateways into the environment.  The VPN gateway approach (without using split tunnels) is a great approach if you have the ability, although it does mean you are either “in the lab” or “in the office”, not both, preventing access to email and Slack and other systems while working on the staging environment.

Since many times we only need to access a select set of hosts in the “sandbox” area, it’s feasible to leverage a NAT device with static translations to reach those endpoints.  But, since there is no routing between the sandbox and production networks (because we likely have duplicate networks and hosts!), we need to also fully nat the source and destination addresses of all traffic flowing in both directions through the gateway to ensure that hosts on each side of the NAT gateway have no knowledge of the IP addresses in use on the other side of the NAT gateway.

Since we all have a few extras lying around, let’s leverage a Cisco IOS router to server as a gateway for us!

Cisco’s IOS implementation of NAT is some times considered confusing to understand because of its terminology.

I find it helpful to remember the following when looking at its configurations:

  • INSIDE = the network to hide
    • INSIDE LOCAL = addresses on the inside before they are translated to the outside
    • INSIDE GLOBAL = addresses on the inside as they appear after translation to the outside
  • OUTSIDE = the public network
    • OUTSIDE GLOBAL = outside public addresses before they are translated to the inside
    • OUTSIDE LOCAL = outside public addresses after they are translated to the inside
  • Refer to Cisco’s overview of the terms HERE for a more clinical definition when in doubt ;)
  • All NAT rules are bi-directional and handle the corresponding return traffic automatically
    • A “nat inside source <local> <global>” rule performs:
      • NAT of source IP for traffic going in -> out (translates source from local to global ip to hide the private IP)
      • NAT of destination IP for traffic going out-> in (translates destination from global ip to local ip to reach the internal host)
    • A “nat outside source <global> <local>” rule also performs :
      • NAT of source IP for traffic going out -> in (translates source from global to local ip to hide the public IP from internal hosts)
      • NAT of destination IP for traffic going in->out (translates destination from local ip to global ip to reach the external host)

First, let’s setup our gateway’s interfaces to the two networks. will be our lab network that is a duplicate of some production subnet. will be our simulated production management network that is routable in our production environment.  In real use-cases we will need 1 or more available IP addresses in this network to create NATs pointing to our staging hosts.   For this lab, we’ll use a router as our lab host @ and a router to emulate a host on the production network (such as our laptop) that needs to connect into the lab host as  We will snag a production IP of to use as our NAT ip to access the lab host from the production network.

NAT gateway interface configurations:

interface GigabitEthernet0/1
 description to lab
 ip address
 ip nat inside
 ip virtual-reassembly in
 duplex full
 speed auto
 media-type rj45
interface GigabitEthernet0/3
 description to prod
 ip address
 ip nat outside
 ip virtual-reassembly in
 duplex full
 speed auto
 media-type rj45

Next, we configure our static NAT to allow our host to be reachable at from the outside so that externally we don’t need to be aware of the network:

ip nat inside source static

Normally you would add one static NAT for each lab host you want to access.  Or you could leverage PAT and map specific TCP ports on a single address to different hosts in the lab if you prefer.

Lastly, we add a NAT pool to eliminate the need for the network to know about the network at all!  Using this, all traffic that comes into the static NAT will then be NAT’d again as it is handed to the inside lab network, resulting in the lab hosts only communicating with addresses:

access-list 2 permit
ip nat pool net-in prefix-length 16
ip nat outside source list 2 pool net-in add-route

In our lab topology we are only matching access-list 2 on, but in a real use-case you would match all production network IP ranges that need to access the lab.  Also, the pool in our example is 90 IP addresses.  You can size that larger or smaller depending on many machines are expected to be accessing hosts in the lab.

This should result in us building a topology like this:


Let’s look at the resulting NAT translation tables before any connections are made:

nat-gateway#sh ip nat trans
Pro Inside global Inside local Outside local Outside global 
---    ---           ---

Here we see just our static translation as expected.

Now let’s test it out by trying to telnet from to the static NAT to access our lab router!

Connected to
Escape sequence is '^^q'.
User Access Verification
Username: cisco

It worked! Let’s now look at the NAT translation tables while we’re connected through the NAT router:

nat-gateway#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
--- ---           ---
---    ---           ---

Here we can see the router connecting to, which is then NAT’d into the lab at  As the traffic is delivered to the host it’s source is NAT’d to an address from our pool as  So on the inside, the traffic appears as the LOCAL columns (session between and, and on the outside the traffic appears as the GLOBAL columns (session between and  The router is handling the ARP responses for the corresponding NAT addresses allowing hosts on each side to talk to only their local subnets.

All that’s required is to then add one additional static NAT for each host in the lab that you wish to access.  You can do 1:1 IP based NATs if you have enough addresses or need to accommodate lots of services to each target host (telnet/ssh/tftp/etc/etc), or you can PAT to the hosts using a single production IP.  Below is an example of using PAT to access SSH on 2 routers with 1 production IP address:

ip nat inside source static tcp 22 10100 extendable
ip nat inside source static tcp 22 10101 extendable
nat-gateway#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
tcp --- ---
tcp --- ---

Hopefully that helps make your lab time more productive!