Add routes on VPN connect with Powershell and Task Scheduler

At my company we use a Microsoft ISA server for our firewall/VPN server. To be able to access the servers at my company via VPN required me to do one of two things:

1. Use default gateway of the remote network
2. Add static routes each time I connect via VPN

Option number one has the drawback that in such a scenario all my traffic would be directed through the VPN connection. Since my company has a very restrictive security policy which allows me to access only a couple of servers (TFS, SQL server, …). That effectively means that when connected to the VPN I can not use the internet or any other network resource.

Option number two requires that you add each of the routes to the routing table every time you connect the VPN. This can not be done via a batch script since the IP of the gateway changes on each connect.

So I thought to my self that there should be a better way to do this. With some basic Googling I quickly came up with an elegant solution. The first step towards the solution was a piece found on this blog. The blog discribes the very same problem that I was facing and provides a simple Powershell script that handles the routes. This Powershell script although it does what is need efficiently didn’t completely satisfy me.

Why? Well simply because I lazy and don’t like having to click on a power shell script on the desktop every time I make a VPN connection.

Doing some more Googling brought me to a Technet page that described how to use the Windows Task Scheduler to trigger the Powershell script execution on each VPN connect. Modifying the snippet I created this command which is executed in the Powershell command prompt.

schtasks /create /F /TN "VPN Connection Update" /TR "Powershell.exe -NonInteractive -command C:\vpn.ps1" /SC ONEVENT /EC Application /MO " *[System[(Level=4 or Level=0) and (EventID=20225)]] and *[EventData[Data='VPN NAME']]"

In this command change the path to your script, and change the last part where it says VPN NAME to the name of your VPN connection. This will ensure that the Task scheduler executes your script only and only when you connect that specific VPN connection. The complete explanation of the settings in the command can be found on before mentioned Technet page.

So I was almost there with the solution but the script it self did not satisfy me because I had to add multiple route and ensure that the routes are not already existing. I modified the original script to this version.

# ---------------------------------------------------------------------------------------
# Initial version: http://www.webboise.com/windows-powershell-script-for-adding-ip-routes-across-a-vpn/
# by Chris @ 30.9.2008
# ---------------------------------------------------------------------------------------
# Modified version: https://simpleverse.wordpress.com/2010/10/06/add-routes-on-vpn-connect-with-powershell-and-task-scheduler
# by Luka Ferlež @ 6.10.2010
# ---------------------------------------------------------------------------------------
#
#
# Add IP routes across a VPN via a DHCP assigned IP address
#
# Configuration
# ---------------------------------------------------------------------------------------
# Route IP address
$ips = @("10.20.1.0", "10.20.100.0", "10.23.2.0")
# VPN connection IP
$vpnIP = "192.168.90."
# ---------------------------------------------------------------------------------------
#
# Get the IP address of the VPN connection
$vpnip = ipconfig | findstr $vpnIP
# ---------------------------------------------------------------------------------------
#
# If we don't have an IP address on the VPN, error and quit
if (!$vpnip) {
"You do not have an IP address on the VPN"
exit
}
# Trim any leading/trailing whitespace
$vpnip = $vpnip.Trim()
# ---------------------------------------------------------------------------------------
#
# Split the contents of $vpnip in to an array
$vpnip = $vpnip.Split(" ")
# ---------------------------------------------------------------------------------------
#
# Find out the depth of our IP address in the array
$bit = $vpnip.Length - 1
# ---------------------------------------------------------------------------------------
#
# Get out just our IP address on the VPN
$vpnip = $vpnip[$bit]
# ---------------------------------------------------------------------------------------
#
# Delete routes if existing
foreach($ip in $ips) {
$hasRoute = route print | findstr $ip
if($hasRoute) {
"Deleting route " + $ip
route delete $ip
}
}
# ---------------------------------------------------------------------------------------
#
# Add whatever routes we need
foreach($ip in $ips) {
"Adding route " + $ip
route add $ip MASK 255.255.255.0 $vpnip
}

This script allows you to simply add the necessary routes at the top of the script, and the script will process them, enjoy.

Microsoft Windows release cycle

First of all be for you start reading I’m not an employee of Microsoft and this text represents my opinions and is not representative of official Microsoft policy.

Yesterday I have been at a Microsoft where several of us have among other seen the M2 build of Windows 7 Client. Now I’m not going to write about what we have seen, Windows 7 features and etc. since I’m not at liberty to do so because of an non disclosure agreement. But there was an interesting discussion on the new Microsoft release cycle for Windows Client operating system. Microsoft has set that after the release of Vista a new release cycle for Windows OS to be 2-3 years cycle release to release. Latest information from Microsoft that can be found on the Internet say that the release of Windows 7 client will be on track with that release cycle with the commercial release date somewhere in fall/winter 2009 or beginning of 2010, internal information from Microsoft have the target of the first availability of RTM set somewhere in summer of 2009.

Microsoft has decide that they will no longer do large changes from release to release like they have done when moving from Windows XP to Windows Vista, rather they will the releases of Windows will be developed in a somewhat incremental fashion. The release will be far from service packs, but we can expect less service packs (Windows XP had 3), rather just one service pack for each version with the major release following soon after. This is a simply due to the requirements of the consumer market that requires a new version of a product with new shiny glittering features that every one will want to have, something like what Apple is doing with MacOS. Now this speed of releasing new OS versions is something that is a requirement of the consumer brings problems to the enterprise market that certainly does not have the need and resources to switch to a new versions of an OS every 3 years or so.

This was the discussion that arose how will the enterprise market react to this change in OS releases, since we who work with enterprise user are aware that our users are sometimes still using Windows 98 and Windows 2000 operating system and most of them are using Windows XP and have no will/need to upgrade to either Windows Vista or the upcoming Windows 7. Microsoft should considered this when they have decided to shift to the new development and release cycle. The way I see the situation now is that they have not considered this or that they have and deiced that their enterprise user will be able follow the new cycle, or that they will skip a release and then wait for the next one.

There is one more problem with the faster release cycle and for the enterprise user it is not a small one when it comes to the enterprise user. Unlike the average Joe consumer the enterprise customer emphasizes ROI and the resource that the company needs to spend on upgrading their software and possibly hardware infrastructure which also accompanied by the expense of training the user and the traditional drop in productivity until the users get accustomed to the new OS. This poses a big risk and big investment to the enterprise user too big in my opinion for them to take the change likely. Another change that the enterprise user will not take lithely is that with the faster release cycle the support periods for the products on the fast track will be shorter which will force the enterprise to change the OS and etc because support is for the enterprise user what the shiny user is for the consumer.

So for the enterprise user from now on they have these two options:

1. Take the risk and upgrade every 3 years
2. Upgrade every 6 years with no updates in the mean time
3. Hope that Microsoft will change their policy

Maybe there has come a time to split the development of Windows into 2 separate tracks, one for the consumer market and one for the enterprise market.

Windows Consumer track

This track should cover the Windows for the average Joe which would be released on 2 – 3 year basis and would include all the latest glittering features that we all like including all the multimedia, game and etc. features that a consumer needs. This edition of Windows would be concentrated on the showstopper features and would be limited to only a 5-6 year support period, since the users will be more likely to change to OS in the meantime be it with new hardware or simply a change of software on the same hardware.

1. Windows Client
2. Windows Home Server

Windows Enterprise track

This track should cover the Windows for the large enterprise customers which would be released on 5 – 6 year basis and would include the latest security and stability features and also increased testing and compatibility checking that is extremely important to the enterprise customer. This edition of Windows would be concentrated to be able to support a longer usage life span and would be on a 10 year support period, since the users will be unlikely to change to OS in the meantime as the cost of doing so are high and the change it self does not bring enough added value to the enterprise customer.

• 1. Windows Enterprise Client
  2. Windows Server

So one day we might finally wake up in a world where enterprise and consumer markets don’t mix with support and release dates but will share the minimal common features that are need to reduce the development and testing costs for each of the OS versions.