Well by this time you have your TMG server(s) up and running, you’re able to get out to the Internet through them, and you’re probably scratching your head saying ‘now what?’ Let’s publish our first website! After all, we probably pitched the enhanced security, anti-malware, and intrusion prevention capabilities of our TMGs when we talked our boss into buying the licenses so I guess it is time we make them do something useful.
In this two-part howto, we’re going to use TMG to publish our public facing website, www.example.com. Part one will set up the farm, and part two will publish it to the web. It is all anonymous access, so no authentication required. Here is a quick diagram of our setup. We have our TMG server connected to the Internet and the internal network, a pair of web servers on the inside network hosting our website, and our edge firewall is allowing inbound HTTP traffic and ICMP echo from the Internet to a VIP on our TMG server set aside for our website.
Yes, that’s right, I said we’re letting ping in <dramatic musical crescendo>. Let’s face it, folks out there are getting at least a little wiser to the ways of the tubes. They know what ping is, and they’re not afraid to use it. If they don’t get a response, they’ll call you up complaining that the tubes are full, or the Internet is broken, or Al Gore took his ball and went home, or whatever. ICMP echo requests to a modern box you keep up to date on patches present a negligible risk, and if you are shopping for the heavy-duty foil, remember you aren’t letting them ping your web servers, you’re letting them ping your TMGs.
Notice we have two web servers on the inside network hosting our corporate website. We’re using an internal name space of example.corp, and and external namespace of example.com. We have one TMG server with an interface on the inside, and an interface on the outside. We should have two TMG servers too, but budgets are tight. Why do we want two? Reliability. A very wise man has this to say about reliability…
Redundancy means never getting that 2 AM phone call.
With two TMG servers, we can patch, we can do maintenance, we can do whatever we need, and never have to take down the website. With two web servers and only one TMG server, we will require a monthly maintenance window for patching, repairs, etc. when the web site WILL be down. However, in this case, that is considered acceptable, so we do what we can with what we have.
If we have two datacenters, with one TMG at each and all published services available from both, we can use DNS round robin to resolve both TMG external interfaces. Time will roughly balance out all connections across both, and we can take one down without having an outage. Half of our clients will see a delay as they timeout trying to connect to the down system, but they will eventually connect to the live box, keeping our services available while letting us bounce servers for patches, etc. as necessary.
Preliminary work
What we want to do to publish a pair of web servers together is create what TMG refers to as a server farm. Our TMG will balance connections between the servers in a farm, and can monitor them so that if one stops responding, or if we wish to take it out of rotation, all connections will be served by the remaining farm member until it comes back. Farms of course need at least two members, but can have as many as you want. There are a few steps to create our farm, which we’ll spend the rest of this post going over. Then, in part two, we’ll publish our farm. If you only have one internal server to publish, show your boss how cool high availability is, and get a second web server up! Just kidding, but you can skip to part two of this post to see how to actually publish a website. Those of you who wish to stay with me, let’s get ready to rumble!!!!!!!
Before we get started on our TMG server, we’re going to want to do a couple of preliminary steps on web servers. This will help us with our testing, as well as ongoing care and feeding of our servers. First, we’ll configure our internal servers either to not require host headers, or to accept web01.example.corp and webo2.example.corp as valid host headers. When accepting traffic from the Internet, we always want to require host headers. That way, we’ll drop most inbound noise that includes scans and worms trying to hit ip.addrs only. Internally, we don’t have to do this, but if we are trying to host multiple sites on a single ip.addr, we will, so let’s make sure our internal site will resolve for our internal clients. Then, we need to create a simple html file at the web root of each server, and call it serverup.html. We’ll use this for connectivity testing, and to take a server out of rotation without stopping the httpd if we want to test something without exposing it to the outside world. Here’s an example file that I use.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1250">
<meta name="generator" content="PSPad editor, www.pspad.com">
<title>Server is UP!</title>
</head>
<body>
This file controls whether or not this box should service proxied connections. </br> </br>
If you want to take this server out of rotation, rename this file </br>
to serverup.bak. </br> </br>
When you are ready to put it back in service, name this file back </br>
to serverup.html. </br>
</body>
</html>
It’s not glamorous but it works. We’ll see in a bit how to configure TMG to make use of that file. Now we’re ready to log on to our TMG server and get this party started. Here are the steps to setting up a farm.
Farm setup
- 1. Speaking of ping, I always like to start out any new publishing or access rule that I am setting up by pinging the internal server(s) from the TMG, and then connecting to the internally hosted service with my browser or telnet client. It takes just a couple of seconds, and it makes sure that I’m starting off on the right foot. No sense troubleshooting a new rule from the outside, if the problem lies inside.
I won’t show it here, but I entered http://web01.example.corp and http://web02.example.corp in my browser to make sure the site came up.
- 2. Launch the TMG Management console.
- 3. Expand your server (or array) if necessary, and click on Firewall Policy.
- 4. On the right hand side, in the Task Pane (View, Task Pane if it is not displayed) click the Toolbox tab, come down to Server Farms, right-click, and select “New Server Farm…”
- 5. This will launch the New Server Farm Wizard. Enter a descriptive name and click Next.
- 6. Add the two servers using their internal fqdn to the farm and then click Next.
- 7. Here is where we configure how TMG will monitor our farm to make sure the servers can handle requests. We could do a simple PING or a SYN to port 80, but by using the serverup.html file we created earlier, we can take a box out of rotation without having to shut it down or disable the httpd. Pretty clever, eh?
- 8. Clicking OK and then Next let’s us complete the wizard.
- 9. If this is the first thing you have setup on your TMG, you will get this prompt, asking to allow the TMG server to connect to selected servers to verify connectivity. You want to click Yes.
- 10. Click Apply at the top, and document your reason for this change.
- 11. Finally, you want to check your connectivity verifiers to make sure the farm is up and responding. On the TMG console, go up to Monitoring, and then click the Connectivity Verifiers tab. Both web servers should show green.
And that is all there is to that. We now have our farm ready to publish, and we’re monitoring it using HTTP GETs to serverup.html, so that we can drop a web server into a maintenance mode but still access it ourselves from the inside. Pretty cool, eh? In part two, we’ll go over the actual publishing of our farm. See you there! Until then, post any questions as a comment, and I will be happy to get back to you.
You might also enjoy:
