Overlapping Subnets Lab Environment

A while back I wrote up a post about creating an isolated test environment using the same ips and subnets with VMware.  This post was written from a layer 2 perspective with users who needed access gaining access to that environment by having a tagged interface and IP on the “external lab ip” vlan.  However, recently, I had the need to extend access to the lab environment to layer 3 design and have multiple sites be able to access the environment for some development and testing work.  However, this overlapping subnets lab environment poses its own challenges.

When subnets overlap with routed traffic, it gets confused on where to route traffic as it thinks traffic coming from a certain subnet, can be found on its own local interfaces – if it has the same subnet assigned locally.  With a layer 2 VLAN only access environment, this is not a problem as users have an IP assigned on their interface that is on the same lab VLAN subnet so they have access.  However, once you start routing traffic, the source address that comes across may be a subnet that you are replicating in your lab environment.

Overlapping Subnets Lab Environment

So how do we get around the limitations when we take access up to layer 3 connectivity?  Well, the key here lies in NAT’ing traffic coming from your “real” subnet over to the lab sunet of the same range.  This way the traffic appears to come from a NAT’ed address for the source IP address.

Overview of Routers

• Router A – router that has the simulated real interfaces and IPs
  • Connected to (2) port groups:
    • Lab Public VLAN
    • Lab Isolated
      • Lab isolated connection has same gateway address that VMs would expect in production, allowing all network configurations to stay the same
  • Has Port Address Translation setup
    • IP Aliases setup for every “internal” production VM which maps Lab Public IP to internal production IP
  • Setup with a route to the IP NAT src IP coming from Router B
• Router B – router that is NAT’ing traffic coming in from the real network to the lab
  • Setup with an Alias address used as source address is NAT rule
  • Setup with a NAT rule to change source traffic to another source address used in route on Router A

The lab router I use for ease of deployment and setup is Untangle.  This linux distribution is a great little appliance that is robust enough to handle anything we want to do in the lab.  I prefer Untangle distro compared to others because it is fairly point and click for setup in the GUI and has a wide range of GUI troubleshooting tools builtin so you don’t have to spend time learning commandline syntax or other distro specifics to get a lab up and running.  However, most virtual linux router appliances will have the ability to do NAT, so any flavor or distro should work, but some are much more difficult than others to configure.  Any of the principles outlined below should work in any linux router appliance.

In order to pull this off, I used (2) lab routers loaded with Untangle.  One of the routers is setup with the simulated “real” networks attached to an isolated internal interface and another interface sitting on the “public” lab VLAN (Router A).  The other router is setup with one interface sitting on the “real” network (production) and the other interface setup on the “lab VLAN” subnet (Router B).  Router B as mentioned above serves the purpose of NAT’ing traffic requests coming from the “real” network.

Router A has IP address aliases (on the public lab VLAN) for each internal VM.  Then port address translation is in place for RDP and other services to translate the public lab VLAN IP to the internal “real network” ip of the VM.

Router B is setup with custom NAT for any traffic coming from the source address 10.50.0.0/24 (production subnet) and destined for the 192.168.0.0/24 (public lab VLAN subnet) range to change the address to a new source address of 192.168.50.1.  This is so that a request coming from 10.50.0.0/24 for a lab VM that also has the address in the range of 10.50.0.0/24 will appear to come from 192.168.50.1.  So replies from a lab VM would know to exit the correct interface.  If we didn’t do this, the request would come in, and the reply would stay internal to the router as it would think the host is on one of its own interfaces.

As you can see above we are “listening” for requested coming from our real production network range, and also checking to see if it is destined for the LAB VLAN and if so, we are changing the source to 192.168.50.1.

On Router A we have a route setup to account for this network.  The next hop is the address of Router B that is on the VLAN subnet.

Now traffic coming in from the real production network will get the source address changed and route over to the LAB VLAN network interface of Router A and then return traffic will get returned to the 192.168.0.50 address above which is the address on Router B assigned to the VLAN subnet.

Conceptual Drawing

Other Details

Between sites, you will need to of course have the proper routes in place to forward requests for the lab subnet on to the “NAT’ing” router that is translating the source traffic over to the lab environment.  Also, if you don’t wish to add this route to a global router, you can essentially have a restriction builtin and only add a route to a specific workstation or number of workstations that need to communicate via layer 3 with the lab environment.

Final Thoughts

Hopefully this overlapping subnets lab environment post will help out if you are trying to design out a lab environment that can be reached between multiple sites and that simulates a real production network without the need to change the IP addresses of all production cloned VMs that exist in the lab environment.