Home Networking: Configuring Forefront TMG for Web (and SharePoint) publishing
After building your bog-standard Hyper-V server with 20Gb RAM, 1Tb HD mirrored, on a quad-core AMD chip (x2), you kinda want to use it as much as you can. I have used this machine to setup a few personal web site projects, as well as various SharePoint farms. But more recently I have been using it for SharePoint 2010 testing and exploration.
I had setup external access to my sites using port forwarding from my D-Link router, but I was having to use a different port for each server. On top of that, I have a Windows Home Server in the mix, which loves to grab port 80 from my router through UPnP.
Here’s what I’m trying to do. Have three internal web sites, http://www.mydomain.com, sp2010.mydomain.com, sp2007.mydomain.com. Make all of these accessible from the internet using Forefront TMG. Setup Dynamic DNS to manage my dynamic IP.
Forefront TMG – The next generation of Microsoft ISA server. Forefront TMG will handle traffic for the 3 three web sites.
DynDNS.com – Will handle the dynamic DNS for me. There are several alternatives, I just happened to pick this one.
D-Link router – The router will handle directing all traffic to the TMG server on port 80.
SharePoint AAM – We need to configure SharePoint to understand the addresses it will receive.
Windows Home Server – Not a direct player, but it does hijack port 80 from the router, so need to disable this.
- All web servers have a static IP address.
- Forefront TMG is already installed and configured.
- Web Sites are available on port 80
- you have a valid domain name (e.g. mydomain.com) and can manage the DNS for it
- While I was setting this up, I used the local hosts file (c:\windows\system32\drivers\etc) to test 1st that the web site host header (and SharePoint AAM) was working correctly by pointing the web address directly at the server; then by testing the TMG firewall rule by pointing the web address at the TMG server.
Publishing a SharePoint Web Application
The following will setup a rule for a SharePoint web application, the same steps will apply for a standard web application, without the SharePoint configuration piece obviously.
We have our SharePoint site already built and hosting a site collection, so now we need to do the following to get it published at sp2010.mydomain.com:
- Configure Alternate Access Mapping (see end of this article)
- Create local hosts entry for SharePoint web server (for testing only)
- Create Firewall rule in TMG
- Edit local hosts entry to point to TMG server (for testing only)
- Configure DNS entry
- Edit router rules (one time)
- Disable Windows Home Server Port Configuring service (optional)
From the TMG Console, open the Firewall Policy page from the tree on the left.
Before we create a rule for the web site publishing, we need to configure a Web Site Listener (if not already configured).
Creating a Web Listener
From the Toolbox tab in the right pane, right-click on the Web Listeners folder and select ‘New’.
Using the Wizard to enter/select the following:
- Name: HTTP Web Site Listener
- Connection Security: Do not require SSL
- IP Addresses: Internal (Because this is a single NIC network, all requests will come from internal.)
- Authentication: HTTP Authentication for Basic, Digest, Integrated
- SSO: No SSO will be available as we are not using Just forms authentication.
Once the wizard is complete, you will see the listener listed in the folder.
Double click to bring up it’s properties and make the following modification.
Under the Authentication tab, click Advanced…
Select to “Allow client authentication over HTTP”.
This is disabled by default as you would typically authenticate over SSL for an external connection.
Now that the Web Listener is created, we will use this when creating our rules. So on to our Firewall Rule.
Creating a Firewall Rule
Switching back to the Tasks tab in the right pane, select Publish Web Sites.
Note: There is also a Publish SharePoint Sites option. From what I could see the only difference is that the wizard asks if you have configured Alternate Access Mapping for the site – it does not seem to do it for you; making it no different to the Publish Web Sites wizard.
Use the wizard to provide/select the following:
- Rule Name: sp2010.mydomain.com
- Rule Action: Allow
- Publishing Type: Publish a single Web site or load balancer
- Server Connection Security: Use non-secured connections
- Internal Site Name: sp2010.mydomain.com
- Internal Publishing Details: Select to forward original host header
- Public Name Details: Accept requests for this domain name (sp2010.mydomain.com)
- Web Listener: Select the one created earlier
- Authentication Delegation: No delegation, but client may authenticate directly
- User Sets: All authenticated users
Once you are happy with the rules and Web Listener, you need to apply them. You will see an Apply button at the top of the window.
After the rules are applied, we can test by pointing the local hosts entry at the TMG server IP address.
In order for us to access this internal web site from the outside, we have to configure the router to handle the traffic accordingly. My router is the excellent D-Link DIR-655.
The configuration involves setting up virtual servers for the web sites. Because we are having Forefront TMG handle all the redirection, we only need one virtual server entry that sends all HTTP traffic to the TMG server.
From the D-Link management console (web application), Select Virtual Server under the Advanced tab.
Enter information for a new virtual server that will send all HTTP traffic (port 80) to the IP address of the TMG server.
Now when you apply this rule, all HTTP traffic will be immediately passed to the TMG server to manage.
At this point we can test to see if:
- Router is forwarding HTTP requests
- TMG firewall rule is handling correctly
- Web site AAM is configured correctly
- To test, modify the local host entry to point to the public IP address of your router. To get this address, browse to www.whatsmyip.org from inside the router.
Because this is a home network, running off a cable provider network, I do not have a legal dedicated IP address. Instead my cable provider allocates me a dynamic one. Because of this, I cannot directly bind my web address sp2010.mydomain.com to a static address :(. This is where DynamicDNS fits in :). A dynamic DNS address gets updated when the ip changes, this update is handled by a client on the network talking to the DynamicDNS server.
To get DynamicDNS working, you need to register with a DynamicDNS provider (dyndns.com in this case), and a client to update the server. There are plenty of free clients out there, but most modern routers can act as a client also.
So I registered mydomain.dnsalias.com at dyndns.com, then I configured my router to updated it.
Now when my cable provider assigns me a new IP address, the router will update mydomain.dnsalias.com accordingly.
At this point, you could test by pointing the entry in the local hosts file at mydomain.dnsalias.com. In order to test this though, you have to configure your firewall rule, IIS host header, and SharePoint AAM accordingly.
All we have to do at our domain provider, is create a CNAME for sp2010.mydomain.com that points to mydomain.dnsalias.com. Once that propagates, we should be able to ping sp2010.mydomain.com and have it resolve to our public IP address!
Windows Home Server
The last piece of the puzzle for me was to stop my Windows Home Server from overriding my router Virtual Server settings for port 80. WHS provides for publishing it’s own web site for accessing pictures, files etc. It’s actually great, and completely handles you having your own address at mydomain.homeserver.com, including providing an SSL certificate, and automatically configuring your UPnP router. This is all great until you don’t want it to :).
There are a number of ways to tackle this. you could disable the UPnP feature of your router altogether, but doing this will mean other applications could not use it. You could disable the service by remoting into your WHS (but WHS can still re-enable it).
I just opened up the WHS console and disabled it from there. Because I never use it, this is the easiest option for me.
To disable this through the console, Open the settings window and click Remote Access on the left.
Here you can click the Turn Off button to disable the service.
SharePoint Alternate Access Mappings
Lastly, if you haven’t configured SharePoint already (and you probably have to have had successful tests), here’s what you need to do for SharePoint AAM and IIS.
From SharePoint Central Administration, select Configure alternate access mappings in the System Settings group.
On the AAM page, edit the Public URLs (make sure you have selected the right web application).
Enter http://sp2010.mydomain.com for the internet url.
Open IIS Manager, and browse to the web application. Right-click and select Edit bindings. add a new binding for sp2010.mydomain.com.
Forefront TMG gives you much more control and functionality that what I am currently using it for, however this is all I need right now. As mentioned before, this is not a production environment. For a production setup, more attention should be paid to authentication and encryption using SSL.
The same steps apply for creating a standard web application without the need to configure SharePoint. You will still need to configure IIS bindings however.
Now you should be able to access your externally published SharePoint and Web sites from wherever you are! No excuses ;).