James D. Stallardblog

I have written previously on how to quickly create a free, secure and fast VPN solution on Windows Server 2003. Having just migrated my own VPN to Windows Server 2008, I thought I should do a new article for the more recent operating system. This version of the install requires only one network interface and therefore does not require configuration as a router, which simplifies the solution and makes it far easier to implement in todays subnetted networks.

This solution provides for proper 2 factor authentication, which makes it plenty secure enough for it's intended use - a quick and secure way to provide remote access to your network while the comms team sets up their enterprise class VPN solution. The solution is not perfect, primarily in it's requirement to manage the pre-shared key by hand - unworkable for more than a *very* small number of users.

I built this solution using a VM and total configuration and testing time is comfortably under an hour.

First, deploy yourself a fresh Windows Server 2008 VM; not forgetting to sysprep it (thus making sure you have a nice fresh SID!) if necessary and then join it to the domain, so it can authenticate users on the domain.

After logging on as an administrator for the first time, the server manager should open up and allow you to install additional roles. The roles wizard is excellent, but a little mickey mouse for those of us that know what we're about.

If you are using a VM and have the capability, you might want to take a snapshot of the machine at this point in case you want to start again.

Install the Role
Open the Server Manager (right-click on my computer and select manage).
Start the roles wizard by expanding out the left hand menu, selecting roles and clicking the add roles button.
Select the Network Policy and Access Services check box and click next through to the role services dialog.
Select only the Remote access service and click through to install.

Configure RRAS
Once complete, close the role wizard and from the administrative tools menu, open routing and remote access.

Verify the machine name in the snapin is correct and right-click on it, selecting configure and enable to start the wizard. It's worth noting here that if you want to fry the config and start again, you can right-click on the server name and select disable routing and remote access to completely clrea the RRAS config.

Unless specified, from now on leave all the default settings and only change what is decribed below:

Select Custom Configuration
Check VPN Access Only
Finish and start the service

Right-click on the server and select properties:
Server Properties
General Tab: Enable this computer as a: (IPv4) Remote Access Server, uncheck everything else

Security Tab: Authentication Provider: Windows Authentication
Allow custom IPSEC policy for L2tp connection (enter a long passphrase to act as shared key, save this for entry into the client

setup)

IPv4 Tab: Enable IP forwarding
This server can assign addresses by using DHCP
Enable broadcast name resolution

PPP Tab: Check all

Logging Tab: Log all events

Ports Properties
Uncheck all connections boxes for everything other than L2TP and where required, set maximum ports to 1 or 0
L2TP: Remote access connections (inbound only)
Uncheck everything else
Maximum ports: 10 (or whatever you think you'll need)

IPv4 Properties
Routing: Only General and Static Routes, remove everything else
General Properties
Logging Tab: Log errors and warnings

Remote Access Logging and Policies
New Network Policy
Policy Name: "Permit Windows VPN Access"
Policy Condition: Tunnel-Type matches "Layer Two Tunneling Protocol (L2TP)"
Policy Condition: Tunnel-Type matches "Point to Point Tunneling Protocol (PPTP)" (only if you require it)
Access is determined by user dial-in properties (IE set on the Dial-In tab of the user account)
Configure Authentication Methods
Check: Microsoft Encrypted Authentication v2 (MS-CHAP v2) (and user can change password feature)
Check: Microsoft Encrypted Authentication (MSCHAP) (and user can change password feature)
Uncheck everything else on authentication methods
Default remaining settings

Don't forget to remove any snapshots you created as they are no longer required.

Once the setup is complete you will need to open the firewall and configure a public facing IP and preferably a prublic DNS entry too. If this is your home connection and you have no fixed public IP or public DNS then you can set your firewall to accept the connections and static map the ports straight through to your new VPN server.

Firewall Configuration Settings
L2TP Inbound Requirements: Protocol 50, IPSec NAT-T UDP 4500, IKE UDP 500
PPTP Inbound Requirement: Protocol 47, PPTP TCP 1723
Configure the firewall to allow any source to access the firewall on the above ports and the rule to map the results to the internal IP of the VPN Server.

To configure the Windows VPN Client
New Connection Wizard
Connect to the network at my workplace
Virtual Private Network Connection
Set the connection Name "My VPN"
Decide if a dial-up connection is required first
Enter the IP address/DNS Name of the VPN Server

Connection Properties
Options Tab: Check all Dialling Options
Security Tab: IPSec Settings
Use pre-shared key for authentication
(enter text to act as shared key, same as that entered above)
Security Tab: Everything else, leave as default
Networking Tab: Type of VPN L2TP IPSec VPN or PPTP if you configured it above
Networking Tab: Everything else, leave as default

There, all done. I've used this in a few places and because the setup is so quick and easy, on the very rare occasions when it goes wrong, it's actually quicker to fry the config and start again than to try and diagnose what went wrong.

Having migrated this blog to Windows Server 2008 I was checking the logs and noticed that the mail.asp pages was being abused to try and send me spam email.

This has been going on for a while, but my mailserver knows the difference between legit comment and muppets posting porn site links and I never received the duff email. However, I felt that I should be doing something to stop this behaviour.

To this end I've modded the email response page to break the typical attempts and stop it from working. If you also run BlogX and want to know how this was done, please drop me a line.

Of course, there are a variety of methods of doing this, so I will have to see how successful my first try was. It's likely I'll have to brush off more of my rusty ASP to solve it permanently.

Update: My first try was not that successful and about 80% of the bot-based spammers was able to get through. However, my second attempt makes use of the server itself to detect the source of request and block anyone not using the page for legit comment.

I have emailed the author of the blog software who will be implementing a verification methodology where users are required to confirm over email - thus neatly removing any false/spoofed addresses and their messages. This will be available once Matthew1471 has finished his finals!

The fact that you're able to read this at all can be considered something of a success as I've just finished migrating my various web applications to new webservers running Windows Server 2008. IIS 7 is a whole new ball game, and I don't just mean the incomprehensible admin interface!

The first problem was working out what needed to be installed; in fact, I installed and uninstalled IIS so many times (OK, only 3) that eventually the web service refused to serve even HTML pages and I had to rebuild the server from scratch. Twice. Thank the Lord for unattended installations and VMware ESX 3.5 or I would have gone a little more insane

So, one working webserver later, I migrated the first of the apps, a basic HTML only site with authentication. So far so good on a few more apps - until I got to my main website www.leafgrove.com, where I "discovered" that CDONTS no longer works and the email contact page was broken as a result. Actually, I discovered this years ago when I moved this app to Windows 2003 Server, but back then all you had to do was find a copy of CDONTS.DLL on Windows 2000 Server SP4+, copy it over and register it. The new solution is CDOSYS and I felt better using that rather than the now very old code from W2K.

A couple of hours (I know, but my ASP is rusty ) with my favourite scripting tool (Sapien PrimalScript 2007) and I had written a spanking new email processor and even improved the old processor's functionality. Some testing followed, and we were finally up and away on that site too.

A couple of other sites making use of HTTP redirects had to be tweaked and I was left with the blog.

The blog was fine until you tried to edit or create entries, whereupon you got one of those useless HTTP500 errors. HTTP500 is a generic message that the server returns when it's sure something's broken but it's not prepared to tell you what. To get any sense out of it you have to switch off friendly messages in the browser and switch on client side errors on the server (not forgetting to switch them off again afterwards!). The problem turned out to be parent paths - which was exactly the same problem as it was a couple of years ago when I migrated this blog to Windows 2003 Server.. The disabling of parent paths was done by Microsoft as a security measure and the correct thing to do is fix the code to remove the ".." where proper paths should be. However, the original issue no longer exists and as this isn't my code and I don't fancy editing 30 odd ASP files looking for duff includes I chose to take the lazy route.

No worries there then, a click or two later to enable parent paths and all was operational.

Being as this is all new, I would appreciate feedback from those that notice any difference. If your feedback is particularly helpful, I might even come up with a prize or something for your efforts! Just click the email button below or drop me a line at the usual place.