Background
[consider this fair warning that this post is a bit long]
In the first part of this series I planned out my “enterprise” environment for an Exchange 2003 to 2010 upgrade. In the second part I built the internal router and verified it was working with directly connected subnets. At this point I have something resembling the following.
In this entry I’ll work on adding the DMZ router, enabling the firewall on one of its interfaces and adding static routers to it and rtr-home so that it’s reachable from my home LAN (essentially the stuff in the red box below). There are two phases to this. The first phase consists of setting up the router and verifying that it is able to reach hosts on the respective subnets it’s directly attached to. As part of this I’ll also set up static routing between rtr-dmz and rtr-home so that we can pass traffic from one subnet to another traversing both routers. In the second phase we’ll set up a very simple firewall ruleset to limit traffic coming out of the DMZ.
Configuring the router
To start I need to create new router rtr-dmz (much as I did in Part 2), with three interfaces. One interface will be on the intranet to DMZ network/VLAN (192.168.4.1/30), another on the DMZ to internet VLAN (192.168.5.1/30)) and the third connected to the DMZ network itself(192.168.254.254/24).
After starting up the VM I assign the IP addresses and enable ssh.
Now I want to verify that I can ping devices on the two interface that are connected to the DMZ subnet(192.168.254.254) and the DMZ to intranet switch (192.168.4.1). I could also check the DMZ to internet interface but don’t have anything else on that side yet whereas I do have a machine in the DMZ and rtr-home is also on the DMZ-to-intranet switch.
Now turning to my PC back on the “Home” LAN I can try to ping the interface of the new dmz router….
Oops! that didn’t work. .. As before I need to add a route on my PC so that it know how to get traffic to that interface through rtr-home.
Now let my try again….
Still no joy… what does traceroute say?
Ok it looks as if traffic is headed in the right direction.
For grins lets ping the DMZ to intranet interface of rtr-home…
Ok so that works and we can see from the traceroute that it’s starting its journey headed in the right direction. The issue is that much like my PC the rtr-dmz needs to know where to send packets destined to come back to a subnet it’s not attached to. To fix this I need to add a static route on rtr-dmz back to my PC. I also need to add routes to the HQ and Remote LANs as well. I’ll start by adding the route to the router:
Now if I try to ping the router from my PC it works as we would expect it to.
With that working its time to add the routes for the HQ and Remote LANs as well.
Now if I look at what I have configured again I’m noticing that rtr-home will also need to have a static route added to get to the DMZ and the DMZ to Internet network (red-lines). This is also true of my PC.
After adding the static routes to rtr-home using 192.168.4.1 as the gateway I’m now able to ping a machine in the DMZ from rtr-home.
Note: Typically for the scenario I’m trying to simulate there would be two sets of traffic flows. One between hosts on the “internet” and “DMZ” and the other between the DMZ and the intranet (HQ and Remote LANs). This means I wouldn’t normally have any traffic coming across rtr-home headed to/thru the 192.168.5.1 interface and so wouldn’t need to add a route for it to rtr-home. But since this my home lab and I prefer being able to ssh/RDP to hosts in the Internet directly rather than using the VM console(s) I’m going to go ahead and add it.
After doing the same on my PC ( this time using 192.168.1.254 as the gateway) I’m also able to ping the machine in the DMZ.
Because machines in the DMZ and on the HQ and Remote LANs will use the rtr-dmz and rtr-home as their default gateways we don’t need to add manual routes to those machines.
Continue reading Simulating a more interesting environment with Vyatta and VMware ESXi – pt 3
Recent Comments