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