28 April 2012

Multiple VPN connections fail from home DSL router

I found an issue this weekend while testing some additional devices form home.   I had configured a TMG PPTP VPN so that all my test devices (iPhone, Android Tablet, Mac, Blackberry)  could connect and authenticate to it.  But I ran into a snag.  It appeared that randomly some of my devices could and then could not connect to the VPN.

PC would sit at authenticating username and password for ages and would eventually show the following Error 806

iPhone had a very generic error

Mac OS X also gave a basic one

And you have to love how they all tell you to contact your administrator - and it is often you!

I eventually traced down the issue to my home DSL router.  What pointed me in the right direction was disconnecting my iPhone from my home WIFI and trying the exact same connect over 3G and it worked.

The problem is not having multiple session connected to the TMG VPN, this works just fine.  As long as the connections do not come from the same IP as it would from your basic home router using simple NAT.   To further complicate things, simply disconnecting the first device that connect does not solve the issue.  In my experiences the only way to get the secondary connection to connect was to restart the DSL router.

11 April 2012

Configure TMG VPN with a split personality

As corporates are moving toward Direct Access for the corporate VPN replacement it introduces a slight problem.   Direct access is awesome for a whole load of reasons, but it is not great  if you are trying to accommodate non corporate non windows devices. So if you have a mixed bag a clients and you want to provide a mixed bag of access based on the device the his is how to do it.

The key here is that we want to differentiate the access level not by the user - who is trustes - but by the device he is using.  There are two classes of devices we will cater for.

  • Windows Corporate machine with a user PKI certificate
  • Non windows machine authenticating with just a username and password

The premise is that to get a user certificate onto the Windows machine it has to belong to the corporate domain.  Because this is now a corporate managed device it is trusted and can have unrestricted access to the network via the VPN

The non windows machine catagory is one that is becoming more prevelant with tablets and BYOD schemes.  These devices are not part of the corporate domain, therefore they are less trusted.  They also do not require access to certain infrastructure that a corporate machine would.

We will configure the TMG VPN to accomodate the following

  • Allow Corporate machines to connect over SSTP with EAP authentication
  • Allow non corporate machines to connect over PPTP with MS-CHAPv2 with a more restricted VPN rule set

Configure the VPN Protocols
To accommodate the different devices I enable both PPTP and SSTP, strictly speaking if you are only needing to accommodate Vista and Win 7 machine you would not need PPTP, but it is such an open standard that it can natively be used by just about any device.

User Mapping
This is a crucial part in configuring this.  Because we want to differentiate based on the device we need to be able to tell how they are authenticating.  When authenticating with EAP the user show up as user@domain.com.  When the user authenticates with MS-CHAPv2 the user shows up as domain\user

 Enabling user mapping will effectively hide this from us.

For this to work you need to authenticate against TMG, you cannot use RADIUS.  You would of course also need to enable both the authentication methods.

 By this stage your VPN would now allow for both the authentication types.  User would also show up differently so we can apply selective rules.

Limiting user access to the VPN
There are two parts to this.  The first purely governs who is allowed to connect to the VPN.  This is controlled by the groups specified in the VPN Clients Properties Groups tab.  Typically I allow a broader scope of users.  This is because the group is an active directory group as opposed to a TMG user set.

You can of course be far more restrictive here, but bear in mind that this purely allows who is allowed to connect, this does not give access to any resources, this is allowed by the access rules.

At this point you will also need to create a TMG user set.  This set should include the users that are allowed to both connect and access internal resources through the "less secure" connection.  In this image you can see that the user set only includes an domain AD group called PPTP_MSCHAP_VPN

Creating Access rules
The order of the rules here is very important.  Rules are processed top down until an allow or deny is encountered.  Basic sequence is as follows

  1. Allow MSCHAP users
  2. Deny MSCHAP user
  3. AllowEAP users
  4. Deny EAP users

Here is a section of the allow rules for the MSCHAP users followed by the Deny rule

These are followed by a rule to allow the remaining users (those not authenticated by MS-CHAPv2 but with EAP)

You need to think about this a little bit.  Users need to be able to authenticate using EAP, This will allow them access to the VPN, but because there is no user mapping they do not match the rules configured for the MSCHAP users.  They will therefor skip past those and finally hit the VPN access rule shown above.

Testing the access rules
For this test I use a domain joined laptop with the required EAP certificate.  I configure two VPN connection for connecting to the same VPN.  the Difference between them is purely the authentication mechanism.  One is set to use EAP (using a certificate) and the other to use MS-CHAPv2

Connecting with the EAP VPN connection shows up as follows in the TMG logs

Connecting with the MS-CHAPv2 VPN connection shows up as follows

Using the method you can cater for the same user but give different levels of access based on the device type being used.  This only covers the basic mechanics of making this work.  Your final VPN configuration with regards to rules and users will be very different.

For more on setting up and configuring TMG VPN and a variety of devices check out my series on this:
Complete TMG VPN deployment guide

02 April 2012

Re-partition OS volume to create log storage drive

One of the most common problem I have countered over the years are servers that fall over because of running out of disk space on the system drive.  In other words the C drive fills up to the point where the machine fails to operate correctly.

There are of course loads of ways to avoid this happening.  I my case here I am going to follow a best practice recommendation for TMG and move my logging to a non system drive.  The TMG BPA recommendation is the following"

"Forefront TMG is configured to write logs to the Windows system drive. If this drive is filled to capacity with logs, the server will crash and fail to start. "

There are of course hundreds of different ways that physical drive and volumes can be presented to the operating system.  In my scenario the server are physical server with two physical drives.  The drives are configured in the RAID controller as a single RAID 1 volume for full fault tolerance.

This presents one disk to the OS.  Typically during install the whole disk is provisioned with a single partition for the OS.

The steps below will shrink the primary OS partition.  This will free up space on the disk to create another partition that can then be used for a log store drive.

Shrink the System partition to create space

  • Open Computer Management
  • Select the Disk management node
  • Right Click the C: partition and select Shrink Volume
  • From the menu screen specify the amount of space to shrink
  • Wait for the process to finish

You should now see the disk showing one healthy partition and another section as "unallocated"

Create the secondary drive

  • Right Click the un-allocated space
  • Select new simple volume
  • Specify the amount of space to allocate
  • Assign a drive letter
  • Format  with NTFS
  • Finish the wizard

You should now see the disk showing two healthy partitions

Next up you want to change the service's logging location to the new drive

Move TMG Logging location

  • From the TMG management console
  • Select Logs & Reports
  • From the Tasks pane select Configure Firewall or Web Proxy Logging
  • Click the Options button
  • Specify "This folder"

The logs will now be stored on your second partition.  Even if this fills up it will no longer cause your server to fall over.

Correctly configuring logging on a server can reduce potential problem related to disk space.  If this was not done at build time or if there are other restriction you can still follow best practice using this method.

Side note:  If you are using a TMG array.  Complete the disk changes before making the logging changes since the change will be applied to all hosts in the array.