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 [...]]]> 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.

Setting up the internal firewall

Planning

While I want to use the firewall capability in Vyatta to simulate my production environment, I also want to keep things simple. Since I’m really more interested in the Exchange 2010 portion of the environment I’m going to take a few liberties with the rules. I’m planning on ending up with two different machines in the DMZ. An Exchange 2003 server providing Outlook Web Access (OWA) functionality, and a box running Forefront Threat Management Gateway (TMG). The Exchange 2003 server would ordinarily need to have a number of ports opened up back to the domain controller(s) and other Exchange servers to be able to function properly. Since I’ve got the Exchange 2003 server and the Domain Controller for each site installed on a single machine, I’m going to opt to let the OWA server free access to each combined machine by IP address and not worry about specifying ports. For the TMG box I’ll limit it to being able to communicate with the new Exchange 2010 servers by ports (443/80). I’ll also want to make sure that I can connect to the DMZ boxes via RDP/Terminal Services.

My preliminary ruleset will look something like:

1. OWA:* to 2K3-HQ:* [OWA to the combined DC/Exchange server in the HQ Lan]
2. OWA:* to 2K3-Remote:* [OWA to the combined DC/Exchange server in the Remote Lan]
3. DMZLAN:3389 to HOMELAN:* [Traffic from any machine/port combination in the Home Lan bound for/coming the RDP port of any machine in the DMZ]
4. TMG:* to E2KX-HQ:80 [
5. TMG:* to E2KX-HQ:443

I’ll also need to add rules for traffic coming from the “Internet” but will tackle that when I build the Internet LAN.

A rule in Vyatta requires a minimum of three pieces of information.

1. An action: accept packet, reject packet or drop the packet.
2. A destination (Network, host, range, etc)
3. A source (network, host, range, etc)

In some of the rules I’ll be adding to the rule set I will also be specifying ports. (ex: 443 for HTTPS, 3389 for RDP, etc). Vyatta allows me to specify which interface I’ll apply a particular ruleset to, as well as what direction the traffic it’ll be applied to is going(inbound from outside the router or outbound through the interface) . In this case I’ll apply the rules to inbound traffic on the interface attached to the DMZ subnet and not worry about restricting traffic coming into the DMZ LAN since the inbound rules will prevent a reply. I bring this up because Its important to make a decision before I start about which traffic flow (inbound or outbound) I’ll be applying because that affects how the rules get written, specifically the source and destination parts. For inbound traffic, the host in the DMZ will always be the source.

The actual configuration

To start the process I need to “create” a new ruleset. To do this I give it a name (line 1). Then I’ll add a description (Line 2) so that I’ll have clue as to what it does when I come back in a few months and look at it again.

Once the ruleset is created I can start to add individual rules by using the “modify” keyword to modify the ruleset. I start the first rule by specifying an action(Line 3), in this case it’s “accept” since we want to pass this particular traffic through. Again I’ll add a description to this particular rule (Line 4) for allowing the OWA server to connect to the combined DC/Exchange 2003 server in the HQ LAN. Next I’ll specify the packet source I want the rule to apply to(Line 5). In this case it’s the OWA server itself so I’ll use the IP address of the OWA server as the source. Then I need to specify the destination (Line 6), the combined server, by IP address as well.

The second rule which allows OWA traffic to the DC/E2K3 server in the Remote LAN differs from rule 1 only in the destination.

The third rule, to allow RDP traffic to anything in the DMZ from the Home Lan, is a little bit different from the first two in that it’s one for which I a) specify a port and b) specify networks for the source and destination. As before I start with the action (Line 1) and a description (Line2). Then because I’m going to specify a port I also need to specify a protocol, here it’s TCP (Line3). Because the source can be any machine in the network I specify a network (192.168.254.0) and netmask( 255.255.255.0 a.k.a /24). I then add the port (Line 5). For the destination I specify the Home Lan network and appropriate netmask, 192.168.1.0/24 (Line 6).

The fourth rule specifies an IP address for both the source and destination like rules 1 and 2, but also incorporates a port option like rule 3. The only difference between Rules 4 and 5 is that the specified port changes.

Rule 5

How I go about things

Rather than entering all the rules at once, I like to commit each rule to the running Vyatta configuration so that I can test it before I start the next rule.

Above I’ve create the first rule. Now to I need to actually apply the ruleset to the DMZ facing interface . This is done using the set interfaces command similar to when I assign an IP Address to an interface. In this case I’ll be assigning the ruleset to the eth1 ethernet interface for inbound traffic. I can then run the show firewalls command to verify its in effect.

Now I want do a simple test and ping the one box I should be able to reach as well as one I shouldn’t (on the Remote LAN). I do this by logging into the OWA server in the DMZ.

Because I’m paranoid and want to make sure it’s a valid test, I’ll try to ping both the HQ and Remote servers from my desktop PC as well. I would expect both of these pings to succeed.

And they’re both successful. Just for good measure I’ll try to ping the OWA server in the DMZ from my desktop as well.

Note – Because I’ve chose to take a simplistic approach to my firewalls it helps to understand what’s actually happening. If I ping the OWA server from my desktop I expect the ping to fail as show below.

What is happening here is that because there isn’t an outbound rule on dmz-rtr’s DMZ interface the packet from my PC to the OWA server is actually making it to the OWA server. It’s the returning traffic that’s getting blocked by the firewall.

In a production environment you’d probably want to control the outbound traffic to the DMZ as well as traffic coming in from it.

I can test the first and second rules using a couple of different methods. Since these rules govern traffic from the OWA server to the DCs simply trying to join it to the domain would be a good test if it hasn’t already been joined. If it has ensuring that I can still log on to the domain from it would tell me things seem to be working. Some more manual options would include ping, nslookup against the DNS server on the DC, an LDAP browser etc. The third rule I can test by trying to connect to the server via the Terminal Services client from my desktop PC. The fourth and fifth rules I can simply test using a browser.

Summary

With this initial set of rules in place I now have my two internal networks and DMZ connected together with a  rudimentary firewall in place. Though I’ve taken some liberties with how laxly I’ve put the firewall together it sufficient to have the end result that I’ll want as I go through this process of migrating from Exchange 2003 to 2010.  In the next entry I’ll add the “Internet” and another simple firewall configuration. I’ll also need to further modify the firewall ruleset on rtr-dmz for communication between the DMZ and “Internet”

At work we’ve recently made the decision to migrate to Exchange 2010 from Exchange 2003. While we do have an environment that we can use for some testing of the migration it doesn’t mimic our production environment [...]]]> [Part 2 of this series which involves the actual configuration of the Vyatta routers is now up here -crt]

At work we’ve recently made the decision to migrate to Exchange 2010 from Exchange 2003. While we do have an environment that we can use for some testing of the migration it doesn’t mimic our production environment closely enough for me to be comfortable using it as the sole test area. Given the changes in how Exchange 2010 (E2KX) works vs 2003 I wanted to be able to simulate multiple (2) Active Directory sites (i.e. subnets), a DMZ, and the “Internet” including some really simple firewalls.

I wanted to use virtual machines to go through this exercise so that I could take snapshots and repeat the various steps and/or variations of them if necessary. In order to do this I utilized the Vyatta Community Edition based routers to help create my virtual “enterprise” environment. I’ve talked about Vyatta before in this article. In this post I’ll talk a little about the process I went through to get to my final configuration (shown below).  In subsequent articles I’ll go  through the actual router and VMware configuration process.

The final environment as laid out on two interconnected servers

Physical view of the network

In initially penciling out a plan for what I wanted to do I had nine VMs scattered across four subnets.

Isolated environment with multiple gateways per subnet

Consolidating functions to reduce # of VMs

In further looking at this from a networking perspective, I was hit with the realization the initial configuration with two routers attached to the HQ and DMZ subnets would require me to manage routing on each individual VM in each of those subnets as well as on each of the routers. As an example one can look at the Exchange 2010 server in the HQ site/subnet.

In this particular case the Exchange server would need to be able to route some traffic to the DMZ via 192.168.2.253 and other traffic to the “Remote” site via 192.168.2.254. (If the server was going to communicate directly with machines in our fake “Internet” I’d have to add yet another routing entry.) I can of course configure a default gateway when configuring the NIC, but still have to manually add a route for the other gateway. This process then has to be repeated on each machine. It then gets more complicated if I want to be able to use Terminal Services (RDP) to connect to the VMs rather than using the VM remote console because I now have to figure out how to connect the virtual routers to my home network and potentially add yet another routing entry.

I decided I’d rather have a single gateway on each subnet (so I only had to specify a default gateway on each VM) and then rely on the routers to do all the routing. I considered a couple of different ways to do this. One option was do something “meshy” where the router for each subnet was connected to common shared subnet.

This would have had the desired effect a single gateway for each subnet regardless of where traffic was going, but would have required 5 virtual routers which seemed a little excessive. Going in the other direction, another option was to have a single router connected to everything.

Single-router solution

I ended up with a solution somewhere between the “mesh” and the single mongo router. It employs three routers. I decided on this partly because I wanted to keep things relatively simple especially since I was going to be enabling the firewall functionality between the DMZ and Internet (and wanting to limit the damage I could do to myself when working late at night).

Again, when all was said and done the environment I ended up with looks like the one below. In the next couple of entries I’ll go through the actual process of building the networking side of this.

Physical/Logical view

After finally getting around to clearing space in the garage and getting an old Dell PowerEdge 2650 I’d acquired up and running with VMware ESXi I started [...]]]> [Note: I've started another series of posts using Vyatta in VMware for a more complex environment that starts with this one- crt (2/20/2010)]

After finally getting around to clearing space in the garage and getting an old Dell PowerEdge 2650 I’d acquired up and running with VMware ESXi I started to think about what I’d need to do to set up a few tests/scenarios I wanted to play with. One of these includes the use of Read Only Domain Controllers in Windows Server 2008. Setting up a virtualized Domain Controller (DC) in VMware is easy enough, the trick was trying to figure out how to simulate multiple IP subnets given that I only have one ESX box at the moment.

At work I can do the whole assigning port groups and VLANs thing and let our physical routers do the routing. For my home lab what I needed was some sort of virtual router that didn’t require 1) a bunch of work to configure, 2) lots of resources on my small host. That’s where Vyatta comes in. In addition to their networking appliances they also provide a “Community Edition” of their software as either a Virtual Appliance (for VMware server it appears) or as a Live CD.

I’ve chosen to use the Live CD for my particular lab scenario because it’s much smaller and since it’s based on an ISO image I can have multiple installations/configurations for just the cost of a virtual floppy image for each instance.

Ultimately my goal is to get to a configuration resembling the following diagram all on one physical server:

In this post I’ll describe setting up Vyatta using the LiveCD image and validating that routing is happening.

The first thing I had to do was create a second virtual switch (vSwitch1) on my ESX box for the second subnet. One could just as easily create port groups and use VLANs on the first switch but I wanted to keep it really simple for now plus I think that conceptually this fits the model a little better.

Creating the second virtual switch

The second virtual switch can be created by navigating to the server node in the Virtual infrastructure client. Then going to the Configuration tab. Select the Add Networking option. Choose the “Virtual machine” connection type. Click next. Choose “create a virtual switch” and uncheck the NIC (if applicable). Click next. Specify a network label. (in my case this is the virtual “remote site”). Click “Next” click Finish

Creating the Vyatta VM.

I started by downloading the Vyatta Live-CD image from http://www.vyatta.com/download/swdl.php. Once I had a local copy of the ISO, I uploaded it to the ESXi box.

Actually creating the VM four our purposes consists of two parts: the initial creation, and then the creation of the floppy image to store the configuration. Because I prefer to keep the floppy image with the VM’s config files I have to perform that portion of the configuration after the VM (and it’s associated folder) is created.   Using your good friend the VMware Infrastructure Client here’s the first set of steps to follow, (they’ll probably be fairly familiar with the slight change that we’re not going to add a hard disk).

Steps for Initial creation

1. File -> New Virtual Machine
2. Custom Virtual Machine Configuration (Next)
3. Specify the Virtual Machine’s Name (Next)
4. Select the Datastore where you want to store the VM (Next)
5. Choose Linux for the guest Operating System and RHEL5-32bit as the version. (Next)
6. Select the number of virtual CPUs, I chose 1. (Next)
7. Specify the amount of memory 128 MB RAM
8. Specify the number of NICs. For my scenario I chose 2 and assigned one to each virtual switch (Next)
9. Pick a Scsi adapter type the choice here doesn’t really matter since we won’t be adding a hard drive to this VM.(Next)
10. Choose “Do Not create a disk”. (Next)
11. Finish

Now that the VM has been created we want to right click on it in the VIClient and choose “Edit Settings”

In the Virtual Machine Properties window go to the Hardware tab.

Select the Floppy Drive.

1. 1. Choose “Create new floppy image in datastore” as the Device Type
   2. Click “Browse” and navigate to the directory in the datastore where you want to keep the floppy image.
   3. Specify the name of the floppy image. (ex: vyatta-config) and click “OK.”
   4. Ensure that the checkbox next to “Connect at power on” is checked,
   5. Click Ok.

Select the CD/DVD Drive

1. 1. Choose Datastore ISO file as the Device Type.
   2. Click Browse and navigate to where the ISO image is stored.
   3. Set to connect at power on and click OK

You’re now ready to poweron the vm and begin the process of configuring it. Power it on via the VI client and connect to the console.  You can log in as ‘vyatta’ with the password ‘vyatta’. The first thing you should do is make sure your VM sees both of the assigned NICs. This can be done by typing:  /sbin/ifconfig | grep -i ethernet. You should see two lines of output; one starting with ‘eth0′ the other with ‘eth1′.

 

vyatta@vyatta:/$ /sbin/ifconfig | grep -i ethernet

eth0      Link encap:Ethernet  HWaddr 00:0c:29:be:8e:2d

eth1      Link encap:Ethernet  HWaddr 00:0c:29:be:8e:37

vyatta@vyatta:/$

To configure the router to match our diagram above we’re going to assign eth0 the IP address 192.168.1.10 and use a subnet mask of 255.255.255.0 (/24). The second NIC will be assigned the IP address 192.168.2.10.  To do this we’ll enter the four following commands.

configure

Set interfaces ethernet eth0 address 192.168.1.10/24

Set interfaces ethernet eth1 address 192.168.2.10/24

commit

exit

The first ‘configure’ puts Vyatta into configuration mode where we can enter actual configuration commands. You might notice that the prompt changes from vyatta@vyatta:~$ to vyatta@vyatta#. The second command assigns an IP address to the interface eth0, while the third does the same for eth1. The fourth command “commit” actually commits the changes so that they’re in use in the running config. The last command exits the configuration mode and you’ll notice that the prompt has changed back as well

 yatta@vyatta:~$ configure
[edit]
vyatta@vyatta# set interfaces ethernet eth0 address 192.168.1.10/24
[edit]
vyatta@vyatta# set interfaces ethernet eth1 address 192.168.2.10/24
[edit]
vyatta@vyatta# commit
[edit]
vyatta@vyatta# exit
exit
vyatta@vyatta:~$

To validate that this is now the running configuration you can type: show configuration

Now to ensure that this configuration sticks with the VM between reboots we need to initialize the attached floppy by entering ‘init-floppy’ This will cause the VM to (re)format the floppy and write the configuration to the floppy.

vyatta@vyatta:/$ init-floppy

This will erase all data on floppy /dev/fd0.

Your configuration was saved in: /media/floppy/config/config.boot

vyatta@vyatta:/$

To validate that the configuration has been properly saved to the floppy and will be automatically available and in use upon reboot you can reboot the VM by typing “reboot” and waiting for the VM to reboot. Upon logging back in you can again run the ’show configuration’ command to see if the config has been kept through the reboot.

How do I know routing is working?

Now that the router has been set up with an interface on each of your virtual switches/subnets you need to verify that it will actually route packets between the two subnets. One way to do this is to create two VMs, one on each virtual switch configured to use the appropriate router interface as its default router.  That can be a bunch of work just to test the routing depending on what kind of guest you use. Another option which I used to do my intital testing was to create two more VMs using the Vyatta LiveCD.  Simply by entering a few commands I can quickly have a configured VM on each subnet that I can use to ping back and forth with.  For the VM on the 192.168.1 subnet I could enter the following commands to configure the new VM.

configure
set interfaces eth0 address 192.168.1.11/24
set system gateway-address 192.168.1.1
commit
exit

Enabling SSH

I also like to enable ssh access for the vyatta router so I can use Putty from my Windows box to administer the VM and not have to use the VI Client console. That can be done by entering:

configure
set service ssh
commit
exit

Saving your configuration

Again to ensure that this is kept in the config through reboots you need to execute the ‘init-floppy’ command.