29 February 2012

OS X Lion and TMG array auto proxy configuration script

Getting your OS X device to play nice with a TMG proxy can be tricky.  After going through this for a while and having finally got a solution that works nicely I thought it be good to share.

There is not really any problem when you have a single TMG proxy server.  The problem comes in when you have an array that contains two or more nodes that are load balanced.  This introduces a few issues for the OS X devices.
The default proxy configuration script explicity maps each array members IP address.  This forces the client to connect to one of the hosts.  Credentials can then be stores in the keycain and used for subsequent authentication requests for that array member.  If however the client connect to another array member the the authentication process is repeated.  This is especially an issue if you are using CARP for caching.

To avoid all this this there are a few steps required.


  • Configure the TMG array to use Kerberos authentication
  • Edit the default wpad.dat file
  • Publish the edited wpad.dat file
  • Configure the clients


Configure the TMG array to use Kerberos authentication
I have already covered this in a previous article
http://fixmyitsystem.com/2012/02/how-to-enable-kerberos-authentication.html


Edit the default wpad.dat file
To be able to make use of the Kerberos authentication you need to address the SPN or NLB hostname
This was also covered in the previous article but...

Here is the portion of the file that needs to be edited


DirectNames=new MakeNames();
cDirectNames=2;
HttpPort="8080";
cNodes=2;
function MakeProxies(){
this[0]=new Node("10.40.22.6",1409863761,1.000000);
this[1]=new Node("10.40.22.5",3630121203,1.000000);


You will notice that it is single IP addresses for each node and not the NLB IP or name.
You can change this using just the NLB name which will allow for Kerberos authentication

DirectNames=new MakeNames();
cDirectNames=1;
HttpPort="8080";
cNodes=1;
function MakeProxies(){
this[0]=new Node("proxynlbname.domain.com",1409863761,1.000000);


Publish the edited wpad.dat file
The best way to distribute the wpad file is to place it on a fault tolerant web server.
Create a new web site in IIS
Copy your edited wpad.dat file to the physical path of the site
Add another MIME types for the site
File name extension *
MIME type */*


IMPORTANT
Technically you should only require to add .dat as application/x-ns-proxy-autoconfig  and this worked fine for Snow Leopard.  However with Lion this does not work.  Bizarrely it seem like Safari request a different MIME type...

Configure the clients
There are some issues with specifying a file so you should always use the URL

  • Open system preferences
  • Select the network
  • Advanced
  • Proxies
  • Make sure that only "Automatic Proxy configuration" is checked
  • Specify the url of the site configured earlier.
  • OK
  • Apply
  • Launch Safari

Conclusion
Going through this process will not only allow your OS X machines to work properly with TMG but there is also a performance benefit here for Windows machines.  You can point them to the same proxy configuration file, in fact you have to if you want to use Kerberos - which is where the performance advantage lies.






27 February 2012

DHCP high availability deployment options Windows Server 8

There are various ways to deploy DHCP in a high availability manner, by that I mean a deployment that will keep working if one DHCP server goes down.

DHCP Basics
To really understand how the various deployments work we need to first understand the basics of how the DHCP process works. Here is a brief rundown of the messages being passed.


  • Step 1 - Client Broadcasts DHCPDiscover to find available DHCP server --->
  • Step 2 - All DHCP servers that received the message return broadcasts a DHCPOffer <---
  • Step 3 - Client broadcats DHCPRequest to the DHCP server --->
  • Step 4 - DHCP server broadcasts DHCPAck to client containing defined options <---


There are a few exceptions but for the most of it all DHCP traffic is broadcast since the client does not officially have an IP yet.

Deployment options
In all of these scenarios you will have at least two server that are configured with the DHCP role.

To illustrate this I am going to work through a scenario where there is a single VLAN that contains 200 DHCP client machines

Dual Scopes per VLAN
The simplest way of doing this is to configure two DHCP servers for a VLAN.  Each configured with a big enough scope to accommodate all the machines on that VLAN. This means you are allocation 200% of the required IPs

  • Server 1 Scope 1 - 10.0.0.50 - 10.0.0.250
  • Server 2 Scope 2 - 10.0.1.50 - 10.0.0.250

The drawback here is that the VLAN now has to span two class C subnets.  The scopes also need to be manually created on both servers.

Implementing  - Dual Scope Deployment

Open DHCP Console

  • Add Server 1
  • Add server 2
  • From server 1 expand to the IPv4
  • Right Click - New Scope
  • Specify and Name and Description
  • Specify a Start IP Address and End Address
  • Specify the Length for the subnet mask
  • Specify any exclusion if you need them
  • Specify the lease duration (Default is 8 days but I prefer much shorter)
  • Yes to configure and DHCP options
  • Specify Default gateway
  • Specify domain name
  • Skip WINS
  • Do not activate the scope yet
  • Finish The wizard

Repeat the process for server 2 but specify the secondary scope range

To load balance you would not specify any response delay in the advance properties for the scope.  This will allow the client to select the server based on "who answered first."  

To achieve a primary and secondary server you would set a delay on the secondary server (max 1000ms)



Split Scope
This deployment method configured both servers with the same scope.  To avoid conflicts the split scope wizard set exclusion ranges that are mutually exclusive. The method for favoring one server over the other is the same time delay.  Often this deployment is done in a a 80/20 ratio.  One server hold the reservation for 80% of the addresses while the secondary holds 20% the theory being that when the primary fails the secondary can continue on till the primary is restored.


  • Server 1 Scope 1 - 10.0.0.50 - 10.0.0.250 - Exclusion range - 10.0.0.210 - 10.0.0.250
  • Server 2 Scope 1 - 10.0.0.50 - 10.0.0.250 - Exclusion range - 10.0.0.50 - 10.0.0.209

You can also load balance by doing a 50/50 split.  The drawback being that you would only be able to serve half the request with one server, or you have to again specify 200% of the required range.  An advantage here is that the scope creation is scripted for the second server.


Implementing Split Scope
Open DHCP Console

  • Add Server 1
  • Add server 2
  • From server 1 expand to the IPv4
  • Right Click - New Scope
  • Specify and Name and Description
  • Specify a Start IP Address and End Address
  • Specify the Length for the subnet mask
  • Specify any exclusion if you need them
  • Specify the lease duration (Default is 8 days but I prefer much shorter)
  • Yes to configure and DHCP options
  • Specify Default gateway
  • Specify domain name
  • Skip WINS
  • Do not activate the scope yet
  • Top configure spit scope
  • Right click the scope - Advanced - Split-Scope
  • Next
  • Add the second server
  • Adjust the slider to allocate the percentage split
  • Specify a Delay for the second server
  • The summary will now show what gets configured where
  • Finish the wizard




The scope is created on the second server and populated with the range, the exclusions and the DHCP options.  The original host is also updated with the new exclusions.



Fail over Cluster
This deployment method is the most efficient when it comes to DHCP allocated IPs.  A single scope is allocated per DHCP service on a failover cluster. The main drawback is that the required infrastructure is a fail over cluster using shared storage.

DHCP Failover (Windows Server 8)
New in Windows Server 8 is another deployment method called failover.  This has the same advantages as using a failover cluster service but without the requirement for a failover cluster.

A single scope is created.  When specifying failover the scope is duplicated on the secondary server.  The server are kept in sync so that conflicts do not occur.  The Wizard will create the scope on the second server.


  • Server 1 Scope 1 - 10.0.0.50 - 10.0.0.250 
  • Server 2 Scope 1 - 10.0.0.50 - 10.0.0.250 


You can have the relation ship as a load balance or as a hot fail over


Implementing Failover

Open DHCP Console

  • Add Server 1
  • Add server 2
  • From server 1 expand to the IPv4
  • Right Click - New Scope
  • Specify and Name and Description
  • Specify a Start IP Address and End Address
  • Specify the Length for the subnet mask
  • Specify any exclusion if you need them
  • Specify the lease duration (Default is 8 days but I prefer much shorter)
  • Yes to configure and DHCP options
  • Specify Default gateway
  • Specify domain name
  • Skip WINS
  • Do not activate the scope yet
  • Right Click the scope - Configure Failover
  • Select the scope to configure
  • Specify a partner server (second DHCP server)
  • Choose the relationship type - Load balance or Hot Standby
  • Specify a share secret
  • Finish the wizard




If you inspect the scope on both server they are identical


Conclusion
There are various way to implement DHCP so that you have fault tolerance and load balancing.  There are pros and cons to all of them.  The most elegant implementation of this is the Failover option in Windows Server 8.

23 February 2012

Sophos Web protection explained

Sophos endpoint protection introduced a feature in version 9.5 called "Web protection" This feature is a real time URL monitoring and filtering service run from the endpoint itself.  Sites are checked against the cloud based database for safety before the browser is allowed to open the site.  Another layer to this is that downloads are scanned.  This protection is complementary when the machines are in your corporate network behind your web access protection mechanisms but it becomes really important when the laptops leave the office.

Malicious sites are one thing but compromised, legitimate sites are another.  Often code is injected to the sites that link the browser up to a secondary malicious site that contain the actual malware.  This original site that you actually intended on going is the referring site.

The feature is either on of off. The setting is set in the Antivirus and HIPS policy from the administrator console.  By turning "ON" the block malicious websites setting you enable this.


When the browser attempt to open a compromised site the site will be blocked and a message will be rendered in it's place.


When these occur the events are also logged and synced back to the management console.



It is often very interesting and worry-some to see what the referral sites are.

The feature may seem redundant for corporate desktop machines but for portable PCs and Macs it is definitely worthwhile turning on, especially since the service run in the background where you have the Block sites setting turned on or off...


22 February 2012

Getting started with VMware vCentre Server Appliance

When building temporary or smaller VMware environements it can be a great time and money saver to deploy a vCentre Server Appliance as opposed to a full blown Windows based vCentre Server.  Here the short guide to get going:


Download the required files

Browse to http://www.vmware.com/support/product-support/vsphere/index.html
Log in with your VMware account or create one

Select the Licenses & Download Section
Expand the "Download Management server" section

You will need to download three files and save the in the same location.


  • VMware vCenter Server 5.0 Appliance - OVF File
    (to download the files right click the download butting and "save as" with a .ovf extention
  • VMware vCenter Server 5.0 Appliance - System Disk  - vmdk (4GB)
  • VMware vCenter Server 5.0 Appliance - Data Disk - vmdk (40MB)



Deploy the files to an ESX host
Connect to the host wit the vSphere client

  • File - Deploy OVF template
  • Specify the path of the ovf file you downloaded
  • Select a data store for the vca
  • Complete the wizard


The files will now be imported to the ESX host.  Once done you can continue on.


The quickstart guide
Start up the VM and connect to the console


The first thing you would want to do it to get the machine on the network so you can administer it through the web interface.

Select Configure network and follow the walk through to get the device connected.



Once finished you will be returned to the initial blue screen. I will now step through the details in the quickstart guide.

Step 1 : Connect to the web interface.

  • Open your browse and connect to https://specifiedip:5480
  • log in with the default credentials
  • Username: root
  • Password:  vmware


Step 2: Accept the EULA


Step 3:  Connect to the database section
Here you will now have to choose either to use the embedded (DB2) or Oracle database type.

For most of us this will always be embedded.  There is a limitation here though.  The embedded database only support a maximum of 5 hosts and 50 VMs

Step 4:  Enter the database connection information

  • Select embedded
  • Click save settings and wait for it to finish
  • Click test settings and wait

If all succeeds you should get the green "Operation was successful"


Step 5:  Select the status section

Step 6:  Start the vCentre

The status should now be "Running"

You should now be able to connect to the vCentre with the vSphere client.


Conclusion
Getting a vCentre Server Appliance up and running is fairly painless.  Compare to a Windows Based vCentre Server deployment it does however have with some limitations that larger deployments will encounter.

  • No Update Manager
  • No Linked-Mode
  • No support for the VSA (vSphere Storage Appliance)
  • Only support for Oracle as the external database
  • Embedded database, DB2, only supports 5 hosts and 50 VMs
  • No support for vCenter Heartbeat


Dell Remote Access Controller - DRAC - Remote OS Deployment

The Dell™ Remote Access Controller 5 (DRAC 5) is a systems management hardware and software solution designed to provide remote management capabilities, crashed system recovery, and power control functions for Dell systems.

Using the DRAC you can remotely deploy the OS itself to the hardware.  To do this you can utilize virtual media.  This is for example an ISO file residing on the network.


Getting Started
All of the following can and should be done through the DRAC web console

  • Open Internet Explorer (Active X is used)
  • Enter the IP address of the DRAC's management IP in the address bar
  • Ignore the certificate warning and log in
  • Select the console tab and launch the console .


Configuring the DRAC via the console
For you to be able to remotely deploy the OS you need to enable Virtual Media.

  • Power on the server
  • During the Server POST enter the configuration for the DRAC  <Ctrl>+R when prompted
  • Select Virtual Media Configuration
  • For Virtual Media change the setting to Attached




Configuring the virtual media via the web console

  • Select the Media Tab
  • From the CD/DVD-ROM Drive section select ISO image file
  • Browse to the ISO that you want to use
  • Connect




The screen will now refresh and indicate that the status is now attached and connected
(Once completed you can disconnect the virtual media from this screen with the disconnect button at the bottom of this screen)


Boot and install from the Virtual Media

  • From the Power Management Tab
  • Power Cycle the System
  • During the Initial POST screen press F11 to enter the boot device menu
  • From the Boot Device menu you can now select the Virtual CDROM option




The system will now boot from the virtual ISO as if it was attached directly to the server.



16 February 2012

Using TMG as a hardware load balancer for web based apps

There is always a debate when it comes to what constitutes a hardware firewall and what does not.  I have found a similar contradiction when it comes to load balancing.  Since you are actually after the service being provided and both use a combination of hardware and software it does not really matter.

The deployment referred to here is a TMG array dedicated to internal traffic to perform as a loadbalancer.  It is only connected to the Internal Network.


Criteria
In most cases I have seen, load balancing is used mainly for the purposes of  fault tolerance.
There are of course a few ways to go about load balancing with this goal in mind.  I am going to rate them based on the following criteria

Ease of adding or removing hosts form the NLB array (Add/Remove)
As load increases or additional functionality is required the array memeber might increase or decrease.

Ability to stop traffic for a host for maintenance
This pertains to the ability to temporarily stop all traffic to an array member for a know amount of planned down time.

Validation
This process checks to see if the service you are load balancing is actually active on the array members, to ensure traffic is not routed to a unresponsive member.

Networking requirements
WNLB has implications at physical switch level since it involves manipulating the MAC addresses.  This in a static environment can be managed easily, but adding dynamic virtualization into the mix makes this a nightmare. 

Virtual Implications
Same as networking requirements but it also another layer of virtual switching that need to be catered for.

Fault tolerance
This is rated based on the actual effectiveness of the NLB as a means of improving fault tolerance

DNS Round Robin (RR)  
This relies on multiple host entries in DNS that point to different IP addresses. The theory being that as DNS requests are answered the load is sent to alternating servers.  There are a few drawback to this though.


Adding / Removing hosts
Since load balancing relies entirely on DNS lookup everything happens here.  Adding a host is as simple as adding an additional host entry for the additional IP.  Removing a hosts is the same in reverse.  The catch is that client DNS cache will persists to that IP until the cache has expired.

Ability to stop for maintenance
Since there is no way to instantly update client DNS, you would have to wait until all traffic dies down for a host before you could work on it.

Validation
There is no validation method

Network requirements
One really good thing is that there is no network requirements.  No switch configuration at all.

Virtual Machine Implications
None

Fault tolerance
Poor

Windows Network Load balancing (WNLB) 
The traditional Microsoft approach to load balancing is to use WNLB.  It is a feature that is installed  on the host array members.  The member then collectively provide a virtual IP (VIP) that clients can be  directed to.  WNLB can be deployed in Unicast or Multicast.  Unicast is simple to configure at switch level but results in switch flooding so one should isolate the NLB to it's own VLAN.  Multicast require satic CAM and ARP entries to be created at switch level pointing to the physical ports on the switch.



Adding / Removing hosts
The host needs to have the WNLB feature added and then the hosts need to join the WNLB cluster.  Physical Network configuration has to be updated to cater for the new host. You can have a maximum of 8 hosts in the WLNB array.

Ability to stop for maintenance
Using the WNLB console drain stop the node and then leave it as disconnected from the NLB

Validation
The NLB can only converge if everything is setup and configured correctly, if there is an issue with a particular host it will not join the NLB.  Validation is only at host level though and not at application level.

Network requirements
Because of the nature of how either Unicast or Multicast works, network configuration is important to be done correctly.  This really slows down the ability to dynamically add and remove hosts form the NLB array.

Virtual Machine Implications 
All of the network requirements are there and then some additional overriding settings that have to be configured on both VMware and HyperV.   One of the biggest problems are that when you start migrating VMs form host to host the network configuration would have to cater for this.  So it is only suitable for static VM implemenations.

Fault tolerance
Good



TMG Farm Publishing 
As a reverse proxy it also works by providing a VIP for the applications you publish.  In an array configuration, TMG itself is load balanced natively using it own flavor of WNLB.  The advantage here is that generally TMG is deployed on physical hardware.  The resultant WNLB network requirements now has to be configured correctly only once despite load balancing numerous apps.  This is similar to deploying a hardware device such as an F5 BigIP where network configuration is equally important.  Have a

Adding / Removing hosts
TMG farm publishing requires a server farm network object to be created.  Additional servers and be added and removed easily.

Ability to stop for maintenance
By controlling the server farm properties you can drain or resume individual servers.

Validation
TMG checks the hosts in the farm for a valid response.  If the verification check fails for one server, no additional traffic will be routed there.  By performing a HTTP verification you can for instance prevent traffic from being routed if the server is up but the IIS site is down.

Network requirements
Other than TMG's own WNLB, there is no specific network requirements.





Virtual Machine Implications 
Since TMG just address the individual hosts there are no specific network requirements, so if VMs move between hosts or from switch to switch there is no impact.

Since the farm can dynamically grow or shrink TMG can also be configured with all the potential hosts in a farm. The failed validation for the offline host will prevent traffic from being routed there until they are online and the application is responsive.

Fault tolerance
Great

Added features:
Since we are using TMG we also get the same benefits as publishing a site to the outside world.  This includes the ability to pre-authenticate requests, preform SSL offloading,  name and path restrictions, etc.
Since all traffic is logged you can also analyse it with products such as Webspy and Fastvue.

Limitations
TMG can only be used as a load balancer for HTTP and HTTPS traffic
The effective WNLB throughput limit is about 500Mbps, higher is possible.

Conclusion
Using a TMG array you can have a very effective and cost efficient load balancer for web traffic.  If you already have the skill level to manage a TMG environment this is a good starting point. (Not really sure if the ISA or TMG teams ever intended for it to be used like this - but it works really well...)

If however you have multi Gbps performance requirements and need to provide more advanced load balacing on other protocols you will need to look at devices like the F5 BigIP.

10 February 2012

How to Enable Kerberos authentication on a TMG Array

With TMG SP2 came the ability to allow users to authenticate using Kerberos instead of NTLM when using an array NLB. To find out more about it check out:

From End to Edge and Beyond - Episode 11 round about 10 minutes in...

The reason you really want Kerberos is because it is far more efficient than NTLM, check Improving Web Proxy Client Authentication Performance

There are a number of steps to follow so read this whole article before you start...

Create the Service account to be used

You need to create a windows domain account that will be used to run the TMG firewall.  (The default is to use the network service account.)

There are some security guidelines for setting up and creating the account.  The suggestion is to use an account that is not a member of any domain groups. This account should also not be used for anything else.
  • Create a user account in AD 
  • Create a group in AD
  • Go to the properties of the user account.
  • Add the user account to the group you just created
  • Set it as the primary group
  • Now you can remove the domain users group

Configure the SPN
Since the SPN will be tied to the proxy host name it is probably a great idea to double check and verify that this is 100% correct.  This name should be the same DNS name as your NLB virtual IP.

  • Form the TMG admin console
  • Select the Array and view properties
  • Under the general tab look for the DNS Name: field

(Note this needs to correlate with the configuration used by the proxy clients, if they use another name or the IP address Kerberos will not be used)

To register the SPN with the Kerberos database you will need to use the setspn.exe utility from the command prompt.
  • setSPN -U -A http/<array_name> <account_name>

as in

  • setSPN -U -A http/proxyserver.domain.com domain\serviceaccount

The command should complete with "Object Updated"
To verify that it is completed correctly run a query
  • setSPN -Q http/proxyserv.domain.com

It should return the result and finish with "Existing SPN found!"

At this point I also added a SPN for just the host name to cover manual configurations that do not use the FQDN.  If you run the query again you will see two SPNs in the list

Change the Credential setting
Form the TMG console select the array you want to edit and view properties.  Note -  this will also affect reverse proxy scenarios.

  • Select the Credentials tab
  • In the Firewall Service account section select "Use this account"
  • Click on set account
  • Enter the account name as domain\servicesaccount (the one you created earlier)
  • Enter the password
  • Apply the setting and restart the services.




At this point do not panic!! The console will suddenly show Unable to retrieve data from: the array members.  This is because the firewall service now starts with a domain account and the console is still attempting to connect with the old one.

Give the array members a few minutes to come up and then close and re-open the console.

To confirm that everything started up ok:

  • Log onto the TMG array members.
  • Open the services console
  • You should now see that the Microsoft Forefront TMG Firewall service is running in the context of the service account.

Checking authentication
Using Wireshark you can spot the the authentication method used. Filter the source and destination ip to that of your NLB and search NTLM or Kerberos in the packet details. This is the NTLM authentication method.


You will see this when authenticating with NTLM.  This will still happen when:

  • Browser does not support Kerberos (IE6)
  • Using an IP address
  • Using a name that does not correspond with the SPN(s)
  • Using a proxy auto-configuration script

Below is the authentication using Kerberos


You can force this behavior in your browser by specifying the proxy server manually.  If however you go back to using your TMG generated auto detect script or wpad file you will switch back to using NTLM
This is because the configuration script explcitly specifies which IPs to connect to.

Here is the  portion of the wpad.dat file that covers that bit:

DirectNames=new MakeNames();
cDirectNames=2;
HttpPort="8080";
cNodes=2;
function MakeProxies(){
this[0]=new Node("10.40.22.6",1409863761,1.000000);
this[1]=new Node("10.40.22.5",3630121203,1.000000);


You will notice that it is single IP addresses for each node and not the NLB IP or name.
You can change this using just the NLB name which will allow for Kerberos authentication

DirectNames=new MakeNames();
cDirectNames=1;
HttpPort="8080";
cNodes=1;
function MakeProxies(){
this[0]=new Node("proxynlbname.domain.com",1409863761,1.000000);
Conclusion
It is now possible to get the performance advantages of using Kerberos for your NLB array.  Making the changes to TMG are relatively simple.  Ensuring that the clients are configured in a Kerberos supported method is the harder part.  At the very least you will now have to mange and update the wpad file.


References:
http://technet.microsoft.com/en-us/library/hh454304.aspx
http://tmgblog.richardhicks.com/2011/12/13/unable-to-retrieve-data-from-array-member-fails-after-enabling-kerberos-authentication-with-nlb-on-forefront-tmg-2010/






08 February 2012

Complete TMG VPN deployment guide Part V

Client Side Deployment steps : iOS and Android
Continuing in the series of creating TMG based VPN to support multiple platforms I am going to cover the steps required to configure a PPTP VPN on iOS and Android

Configuring iOS
To configure the VPN follow the following steps:

  • Settings
  • Network
  • VPN
  • Add VPN Configuration
  • PPTP
  • Server IP / Publid DNS name
  • Account domain\user
  • RSA OFF
  • Password Ask every time
  • Encryption Level Maximum
  • Send All traffic ON
  • Proxy Auto
  • TMG single Node http://proxy.doman/wpad.dat


To connect to the VPN
Settings
VPN toggle ON

You will see a blue VPN connection Indicator at the top of the screen.

Things to Note:
These is no way to specify a default DNS suffix, so simple host name resolution doe snot work.  So trying to browse to http://intranet will not resole, you would have to browser to http://intranet.domain.com

Proxy configuration.
It is advisable to specify a proxy auto configuration script. Normally this would be similar to:

http://proxy.domain.com/wpad.dat

There is however an issue with using the TMG NLB name.  If you are continually prompted for credentials switch to using only one of the TMG nodes.  (See configuring Kerberos authentication for TMG proxy)

Configuring Android
To configure the VPN follow the following steps:

  • Settings
  • Wireless and Network
  • VPN seetings
  • Add VPN
  • Add PPTP VPN
  • Set VPN Name
  • Set VPN server
  • Enable Encryption
  • DNS Search Domains  - specify domain.com
  • Back
  • Connect
  • Specify Username and Password


Things to note:
Android does not support using a proxy for web browsing.  So while connected to the VPN users will not be able to surf out through the proxy
The work around here is to use Opera Mini as a browser as this support using a proxy.





Complete TMG VPN deployment guide Part I - Planning

Complete TMG VPN deployment guide Part II - Server side deployment steps
Complete TMG VPN deployment guide Part III - Configuring VPN on Windows
Complete TMG VPN deployment guide Part IV - Configuring VPN on Mac OSX
Complete TMG VPN deployment guide Part V - Configuring VPN on iOS and Android

Complete TMG VPN deployment guide Part IV

Client Side Deployment steps: Mac OSX
Continuing in the series of creating TMG based VPN to support multiple platforms I am going to cover the steps required to configure a PPTP VPN on OSX.

To Configure the VPN perform the following steps:
  • Open System Preferences
  • Network
  • + (Bottom Left Corner to add an interface)
  • Interface : VPN
  • Type PPTP
  • Pick a Name
  • Create



  • On the left hand side select the interface you just created
  • Address: Specify the public name or IP
  • Encryption : Maximum
  • Authentication : leave as Password
  • Check Show VPN satus in the menu bar

(This give you an quick place to connect and disconnect as well as a duration indicator)


  • Click Advanced
  • On the Options tab check Send all traffic over VPN connection


  • On the DNS tab add the DNS suffix search domain : company.com



  • On the Proxies tab select auto proxy configuration : specify the URL http://proxy.company.com/wpad.dat


  • Close the advance section
  • Connect to start the VPN connection




Complete TMG VPN deployment guide Part I - Planning

Complete TMG VPN deployment guide Part II - Server side deployment steps
Complete TMG VPN deployment guide Part III - Configuring VPN on Windows
Complete TMG VPN deployment guide Part IV - Configuring VPN on Mac OSX
Complete TMG VPN deployment guide Part V - Configuring VPN on iOS and Android


Complete TMG VPN deployment guide Part III


Client Side Deployment steps : Windows
Continuing in the series of creating TMG based VPN to support multiple platforms I am going to cover the steps required to configure a SSTP VPN on Windows.  Manually and then via a CMAK installer.

Since Windows support the more secure SSTP portocol and has a higher chance of being able to connect through most firewalls, I will configure the connection to be SSTP but fall back to PPTP should SSTP fail.

Manual configuration
Create the VPN connection

  • Open Network and Sharing Centre
  • Setup a new Network connection or network
  • Connect to workplace
  • No, create a new connection
  • Use my Internet connection (VPN)
  • Internet address (For SSTP your host name must match the certificate name.)
  • Destination Name is the friendly name
  • Check Don't Connect now....
  • Don't Specify a username and password
  • Finish off the wizard.



Configure Security 
From the network and Sharing centre

  • Click Change adapter Settings (top left)
  • Open the VPN properties
  • Select the Security tab
  • Type of VPN : Automatic
  • Data Encryption:  Maximum strength encryption
  • Authentication Allow these protocols - only allow MS-CHAP v2


Configure Name resolution

  • Select the Networking tab
  • Select Internet Protocol Version4 (TCP/IPv4)
  • Properties
  • Advanced
  • Select DNS tab
  • Specify your domain in the DNS suffix for this connection


Enable Proxy server

  • Open Internet Explorer
  • Tools - Internet Options
  • Select the Connections tab
  • Select the VPN connection from the "Dial up and VPN setting" section
  • Settings
  • Check Automatically detect settings
  • Check use automatic configuration script specify http://proxy.domain.com/wpad.dat


Things to be aware of:
By specify the VPN type as automatic we allow the connection to attempt one VPN type after the other until one works or all fails.  It starts off with IKE, followed my SSTP and then PPTP.  If you know what work and would like to speed up the connection you can select the type explicitly.

Specifying the DNS suffix will ensure correct name resolution even if only the host name is used.  This is normally not a problem for domain joined machines, but for external parties this will make a difference.

Specifying the Proxy settings are limited to that specific VPN connection.  "Automatically detect settings" will trump "Use automatic configuration script"  but I include it as a fail over.


Configuration Manager Administration Kit
All of these setting can be preset in a CMAK package and distributed as a normal exe installation package.  This makes deployment simple and uniform.  It also allows for more advanced configuration options that maybe be beneficial.

Install CMAK
One thing to be aware of is that you need to use the right version of CMAK for the platform you want to deploy on. You need the x86 version available on Windows 7 or the x64 version available on Windows Server 2008 R2

Installing on Windows 7 x86
Go to Control panel - Programs - Turn windows features on  or off
Select RAS Connection Manager Administration Kit feature (CMAK)

Installing on Windows Server 2008 R2
Go to Server Manager - Features - Add feature
Select Connection Manager Administration Kit

Configuring a CMAK Package
Launch the CMAK from Administrative Tools
Follow the wizard and specify the same options as specified for your manual configuration.

  • Selecting the Windows 7 or Vista option enable the SSTP feature where as the XP option is limited to PPTP
  • Create a new profile
  • Specify a name that will be seen as the connection name
  • Speficy a filename
  • Do not add a realm name
  • There should be no profiles to merge yet
  • Choose Phonebook from this profile
  • Choose Always use the same VPN server - Specify the name that matches the SSTP listener certificate.
  • Edit the VPN entry


  • From the general tab enable on IPv4 addresses
  • From the IPv4 Select Server assigns addresses
  • Check Make this connection the client's default gateway
  • Check Use IP header compression
  • From the Security tab
  • Select Try Secure Sockets Tunneling Protocol first
  • Select Maximum strength encryption
  • Check only MS-CHAP v2 as Authentication Method
  • From the Advanced tab Specify your domain as the DNS suffix for this connection
  • Continue with the wizard
  • Uncheck Automatically download phone book entries


  • Edit the Dial-up network entry 

  • (This section is not used if you change the connection type in advanced customization )
  • Form the general tab select only IPv4 addresses
  • From the IPv4 Select Server assigns addresses
  • Check Make this connection the client's default gateway
  • Check Use IP header compression
  • From the Security tab
  • Select Maximum strength encryption
  • Check only MS-CHAP v2 as Authentication Method
  • From the Advanced tab Specify your domain as the DNS suffix for this connection
  • Continue the Wizard
  • Do not change the routing tables

  • Select Automatic configure proxy settings
  • Add the proxy settings file
  • Check Restore the users' previous proxy settings...

  • You will need to create the text file for this but it is very simple.
  • Create a text file and paste the text below

[Automatic Proxy]
AutoProxyEnable=1
AutoConfigScriptEnable=1
AutoConfigScript= http://proxy.domain.com/wpad.dat

(This would match the config you specified in the manual VPN connection)
  • You should not have to make any changes to the Customs actions


It is always good to brand your CMAK connection with official corporate images so it looks more official.
Other than the phone book bitmap the users will see and interact with the other graphic screen and icons.
(You will need a 330x140 .bmp, a 16x16 .ico and a 32x32.ico)

  • Use the default Help File
  • Specify any additional text to be displayed on the logon screen
  • Specify a license agreement files (if you need one) or leave it blank

You can include additional file in the package if you want -this could be custom executable you might want to use with connection scripts
  • Select Advanced Customizations
  • Select the .cms filename
  • Select the section name - Connection manager
  • Select the Key - Connection Type
  • Specify a value of 1

(This instructs the package to use a direct internet connection as opposed to using a dialup connection first before starting the VPN - think old school dial up modem)

  • Finish off the wizard.

The CMAK files is now saved in C:\Program Files\CMAK\Profiles\Windows 7 and Windows Vista\
You will only need to distribute the .exe file.  Once the exe is installed the connection should be available form the Dial-up and VPN connections

Troubleshooting SSTP Certificate Issues
Your production SSTP VPN should always be using a public CA for issuing the certificate.  During testing or lab implementation one would typically be using a certificate issued by the internal PKI or a self signed certificate.

Revocation Check
The SSTP client will, by default, do a certificate revocation check during the initial negotiation phase.  If the CRL check cannot be completed successfully the connection is refused with the following error:

Error 0x80092013:  The revocation function was unable to check revocation because the revocation server was offline.


This is probably because your CRL is on internal server that you do not have access to yet.

You can disable this check by changing the following registry entry:


Registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\Parameters

Registry entry: NoCertRevocationCheck
Data type: REG_DWORD

Change the value from 0 to 1 to disable the revocation checking.

Certificate Chain
If you are testing you SSTP client from a non domain joined machine and you are using an internal PKI certificate you might also run into the following problem.

Error 0x800B0109:  A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.



To resolve the issue the PKI certificate(s) need to be exported and installed on the client machine.  It has to be installed in the computer store.




Complete TMG VPN deployment guide Part I - Planning

Complete TMG VPN deployment guide Part II - Server side deployment steps
Complete TMG VPN deployment guide Part III - Configuring VPN on Windows
Complete TMG VPN deployment guide Part IV - Configuring VPN on Mac OSX
Complete TMG VPN deployment guide Part V - Configuring VPN on iOS and Android

Complete TMG VPN deployment guide Part II

Continuing in the series of creating TMG based VPN to support multiple platforms I am going to cover the steps required on the TMG array.

Server Side Deployment steps

Configuring TMG VPN
TMG provides a 6 step guide for doing all the required configuration.  The 6th being optional.

From the TMG management Console select Remote Access Policy (VPN)



Step 1 - Configure Address Assignment Method
This allows you to specify how the VPN client will be issued a client IP address.  You have two options.  TMG can allocate them a client IP based on a defined static address pool that is managed by TMG.  The alternative is for TMG to act as a DHCP relay agent and allocate an IP out of an existing DHCP scope.  For this to work you obviously need to have DHCP available on the relevant network and subnet.

In an array configuration you will have to have an IP range for each node of the array.  Each node should have enough IPs to accommodate the number of allowed VPN users.
Click on the Advanced button to set DNS and WINS


Step 1-2 - Enable VPN Client access
Click Enable VPN Client access.
Click Apply to activate the change

Step 2 Specify Windows Users
Add the relevant user groups.
Note that you will not be able to directly select these group when creating the access rules.  I would suggest creating correlating TMG user sets (Toolbox - Users - New)


If you were using EAP as the authentication method you would need to use RADIUS.  This would then be used instead of the specified groups.

Step 3 - Verify VPN properties
This is where you select the protocols to be used.  For now I will only select PPTP.  Once I am happy everything is configured correctly I will come back and also enable SSTP



Step 3-2 - Remote Access Configuration
You need to enable the network from where you want VPN clients to connect from. The default is External.




Step 4 - View Firewall Policy for the VPN Clients Network

This will simply take you to the Firewall policy page.

  • From the Tasks pane click Create Access Rule
  • Specify a name
  • Select allow
  • For Initial testing -  leave the default option of "All outbound traffic"
  • Enable Malware Inspection
  • In the Sources screen Click Add - Networks - Choose VPN clients
  • For initial testing - on the destinations screen add Internal
  • In the user sets window remove all users and replace it with the user sets created in Step 2



Step 5 - View Network rules

This will simply take you to the Network Rules pages

  • If the is an existing rule for VPN edit it as follows or create a new one
  • VPN to Internal
  • Sources - VPN Clients
  • Destination - Internal
  • Network Relationship - NAT
  • Use Default IP for NAT

Apply all the setting and wait for the configuration to be applied across all array nodes.


Additional Steps
At this point you should have a TMG configuration that you can test against.  Given the design goal we will at the very least have to revisit Step 4.  Setting the VPN access rules is where the security comes in.  You can have multiple access rules so you can really apply very granular access.


Configuring SSTP
In step 3 we did not select SSTP as a protocol. To do so there are a few things we need to do first.

Request a Certificate - This is a standard SSL web server certificate so the same process applies here.  Since I am designing the VPN to accomodate non corporate Windows machines I will be using a public CA to avoid certificate issues. Request and install the certificate before proceding with creating the listener.

Create a listener

  • From the TMG Management Console
  • Select the Firewall Policies Node
  • Select Toolbox form the right hand pane
  • Expand Network Object
  • New - Web Listener
  • Name it SSTP VPN
  • Require SSL
  • Select the External Network
  • Click Select IP addresses
  • Select Specify IP addresses in the... and add the single IP you want to use
  • Click Select Certificate 
  • Choose the certificate that was installed earlier
  • Select HTTP authentication - Check Basic


You can now go back to the VPN configuration and click Verify VPN properties
Check Enable SSTP
Click Select Listener and choose the listener created earlier.






Complete TMG VPN deployment guide Part I - Planning

Complete TMG VPN deployment guide Part II - Server side deployment steps
Complete TMG VPN deployment guide Part III - Configuring VPN on Windows
Complete TMG VPN deployment guide Part IV - Configuring VPN on Mac OSX
Complete TMG VPN deployment guide Part V - Configuring VPN on iOS and Android