NOTE: update 22 Mar 2010 - The Shrew.net client supports Win7 now, and seems to work flawlessly. It’s a much better option if you don’t already have a need for Cygwin. 

To get Cisco VPN working on an x64 Windows 7, you need:

• Cygwin - a wonderful set of tools to emulate a linux environment on windows
• OpenVPN - to provide a virtual TAP network adapter
• VPNC - the VPN Client

• Download cygwin http://www.cygwin.com/setup.exe installer and save to your hard drive (don't just run it directly)
• Right-click on the setup file, and 'Run as administrator'. This may not actually be neccesary but it makes me feel good.
• Accept defaults except for local packages directory - I changed that to c:\cygwin\packages.  Saving stuff to my desktop is annoying.
• Choose a mirror to download packages from.  Choose something physically close to you.
• Choose the following additional packages to include:  (choose them by clicking on the word 'skip' in the 'New' column)
  • Devel > gcc-g++: C++ Compiler
  • Devel > make: The GNU version of the 'make' utility
  • Libs > libgcrypt: A general purpose crypto library based on the code from GnuPG
  • Libs > libgcrypt-devel: A general purpose crypto library based on the code from GnuPG (development)
  • Libs > libgpg-error: A library that defines common error values for GnuPG
  • Perl > perl: Larry Wall's Practical Extraction and Reporting Language
• The rest of the cygwin install process is pretty obvious; just a couple more mouse clicks.

• Download the latest OPENVPN release candidate from http://openvpn.net/index.php/open-source/downloads.html
• The version I downloaded was: http://openvpn.net/release/openvpn-2.1_rc19-install.exe
• Save it to your hard drive somewhere you can find it.
• Make sure to run the installer as an administrator and in windows vista compatibility mode:  (this IS neccesary!!)
  • Open up windows explorer to that location.
  • Right click on the file you saved, and select 'properties'
    • Select the 'compatibility' tab
    • In the Compatibility mode section, check the box 'Run this program in compatibility mode for:', choose Windows Vista (service pack 2)
    • In the Privilege Level section, check the box 'Run this program as an administrator'
    • OK/Apply the settings.
• Now run the installer.  Agree to the license agreement. 
• Uncheck all of the options EXCEPT for: 'TAP Virtual Ethernet Adapter', and 'add shortcuts to Start Menu' (in case you want to add another vpn connection)
• Install to default location.
• The installer should have created a TAP adapter in Control PanelNetwork and InternetNetwork Connections.  It's probably called Local Area Connection 2.  You NEED to rename it to something without a space in the name and something you'll remember.  I called mine 'CiscoVPN'.

• Download the latest release of vpnc from : http://www.unix-ag.uni-kl.de/~massar/vpnc/ I got http://www.unix-ag.uni-kl.de/~massar/vpnc/vpnc-0.5.3.tar.gz
• Save the file to a convenient temporary location, such as c:\cygwin\tmp
• Right click on the Cygwin Bash Shell shortcut (should be on your desktop and/or start menu) and select 'Run as administrator' to open up a cygwin bash command prompt.  IT IS CRITICAL THAT YOU RUN THIS AS ADMINISTRATOR OR YOU WILL FAIL AT CERTAIN POINTS IN THIS PROCESS SILENTLY!!!
• Now extract the contents of the file and change to the extracted folder:

$ cd /tmp
$ tar xvfz vpnc<tab>
$ cd vpnc<tab>

• Now, compile it with make:

$ make
$ make PREFIX=/usr install
$ mkdir /var/run/vpnc

• For or some reason my own Cygwin install did not put /usr/sbin into the 'path' environment variable.  Not sure why that is.  You could add c:\cygwin\usrs\bin into your system path via advanced system properties in Windows, but here's how I fixed it:  I edited my .bashrc file (found in your 'home' directory: /home/<username>/.bashrc ), and added these two lines:

export PATH=${PATH}:/usr/local/bin
export PATH=${PATH}:/usr/sbin/ 

• You'll want to logout out of the bash shell and login again to have that take effect.  REMEMBER TO 'RUN AS ADMINISTATOR'
• You can check to make sure you can 'find' vpnc with this command:

$ which vpnc
/usr/sbin/vpnc

• This is the bit that's broken in Win 7, or perhaps all x64 bit OS.  The script in question is: /etc/vpnc/vpnc-script-win.js.  I've posted my updated script here: Note that I added a bunch of debugging information to the script.  You can make it much quieter by removing or commenting out the two echo commands inside the run function definition on lines 17 and 19.
• The script supplied with vpnc relies on the execution of the "route print" command to extract the default gateway on this computer.  For some reason the results of that command do not format the default gateway information in Win 7 x64 in the expected manner (perhaps other versions as well - I've seen references to this problem with Vista x64).
• To fix the script, you need to replace the function getDefaultGateway with this one I hacked together:

function getDefaultGateway()
{
    var output =   run( "route print 0.0.0.0"  ) ;
    var pos = output.indexOf("0.0.0.0          0.0.0.0      ") + 30;
    var gw = output.substring(pos,pos+15); // max length of ip address
    gw = gw.substring(0,gw.indexOf(" ")); // trim at first space...
    echo("Default Gateway: [" + gw + "]");
    return gw;   
}

• I suck at regular expressions so I didn't try to use them for this.  If you're better with regular expressions than I am feel free to post a comment with an improved function. 
• I also found it neccessary to add a smal pause to the script before adding the internal routes. Without the pause, the 'route add' commands were not adding correct routes in every case. 

echo("Pausing for 4 seconds to allow the adapter to register itself correctly and therefore correct routing inferences made. You may need to supply a longer delay.");
 WScript.Sleep(4000); 

• I put that sleep command just before line: if (env("CISCO_SPLIT_INC")) { 
• I also noticed that after disconnecting (ctrl-c), there were still stray routes in the route table.  I'm not sure that it matters because the route to the main vpn gateway is properly removed, but I went ahead and added some code to remove all of the routes added by the script when disconnecting:

run("route delete " + env("VPNGATEWAY") + " mask 255.255.255.255");
 
 //remove internal network routes
 if (env("CISCO_SPLIT_INC")) {
  for (var i = 0 ; i < parseInt(env("CISCO_SPLIT_INC")); i++) {
   var network = env("CISCO_SPLIT_INC_" + i + "_ADDR");
   run("route delete " + network );
  }

• Alternatively, I've posted an updated file here: Just copy that to your /etc/vpnc folder.

• You need to convert your old Cisco .pcf file into a config file for vpnc in order to get the shared secret included in that file carried over correctly, and to make sure you have the ip address of the vpn gateway, etc.  So, first copy your existing cisco .pcf file into somewhere convenient.  /tmp is pretty convenient. Then run the pcf2vpnc utility:

$ cd /tmp
$ pcf2vpnc <old Cisco filename>.pcf /etc/vpnc/<profilename>.conf

• <profilename> is whatever unique name you want it to be.  Note that we're saving the new configuration file to /etc/vpnc.  You could always copy the created file to that location later.
• Now, edit the file it created with your favorite unix friendly editor.  Windows Notepad is no good.  Go download Notepad++ right now; I'll wait.  Got it? OK. Open the file /etc/vpnc/<profilename>.conf
• You'll need to add a few items to the file:

Interface name <NameOfTheInterfaceYouPickedEarlier> # mine is: CiscoVPN
Interface mode tap
Pidfile /var/run/vpnc/<uniqueName>.pid # need a unique one per profile, so may as well use <profilename>.pid
Local Port 0  #auto selects a port
NAT Traversal Mode force-natt
No Detach

• You really shouldn't do it, but you can also enter your password in this config file if you don't mind that password being there in plain text. The syntax for that is:

Xauth password <yourpassword>  # You've got a secure computer, right? Really? Are you sure?

• If you have any trouble, you can add a debug flag to your config file:

Debug 1     # valid values: 1-3, 99.  99 = everything, including authorization information (passwords), so be careful

• Actually there's not much to put together, you just need to use your shiny new vpnc command:

$ vpnc <profileNameWithoutExtension>

• You could drop that command into an executable file to save a few keystrokes.  I'll leave figuring out how to launch the cygwin bash shell and executing that command from a windows batch file (and so an icon on your desktop) up to you.  

I hope this works for you, but I can't guarantee anything!  Feel free to post comments with your experiences.

Update 10 Aug 09:

I have had issues with routing within the network if the vpn concentrator provides me with a new IP address.  I'm not sure exactly why that happened or what to do in order to fix the routing - I'm not a network routing guru.  I did figure out how to work around this issue though.  In Control Panel\Network and Internet\Network Connections I went to the TCP/IPv4 settings and switched to dhcp ('obtain an IP address automatically, Obtain DNS server address automatically).  These settings are overwritten when connecting to the vpn again, but for some reason making that change clears out something so that when connecting via vpnc the routing works again.  For today anyways. :)

Cheers, 

Allan

Here's the blurb from ELMAH'S site:  

 ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.
Once ELMAH has been dropped into a running web application and configured appropriately, you get the following facilites without changing a single line of your code

I don't know about you, but this is very exciting for me - exactly the type of thing that I've been encouraging folks to somehow get onto their development schedules. Things like this help drive quality to the next level by not only giving you tools to diagnose problems better, they increase the visibility of problems by orders of magnitude. No longer are errors hidden away in some error log on the server which isn't easily accessed by the average dev. RSS feeds of the latest error reports to drop on your iGoogle homepage! That's the bomb! 

As with anything like this, be careful what you ask for, because you could easily be innundated with error reports to the point where you may have a hard time absorbing the information. But its a SUPER motivator to fix those seemingly benign issues that wind up generating the bulk of your exceptions... 

I'd love to hear about anyone's experience with this or similar tools, or if it inspires you to brew up something similar for your other (non .net) projects.

I really liked the analogy given by a commenter (James) on Rob's article, drawing on his experience as an electrician - specifically as an electrician's apprentice (I can relate - that's my background).  The point that I took home was - rules can only get you so far, but it's the rules and guidlines that the 'newbies' learn in their first few years, combined with the experiences lived through in those years that give people the knowledge and widsom to deal with things that the rules don't cover or when it's 'safe' to compromise rule X in order to achieve the goal at hand.

So, think twice when faced with the common choice between doing it right or doing it quick.  Are you really qualified to decide when to cut corners? 

I'm not ashamed to admit that I love to watch Mike Holmes' 'Holmes on Homes' show on the Home and Garden network.  His motto is: "If you're going to do it - do it right the first time".  His show is all about how much effort and waste and heartache happens when contractors cut corners (too much).  His genuine passion for doing things right really resonates with me.

I stumbled across another quote the other day that seems to fit in this context.  John Wooden is a famous college basketball coach of the 60's and 70's, and in his time was well known for a few sage sayings.  "Be quick, but don't hurry" really captures the great balance we struggle with in software development - the need to deliver value (working software) quickly, but with sufficient quality that we won't regret later.  "Doing it right doesn't" doesn't have to mean "Doing it slow", all the time.  It certainly shouldn't be an excuse for spinning your wheels or not making good progress on your projects.

As a manager of software developers, I would WAY rather deal with the problem of "it's taking too long" rather than "the quality sucks and our customers are coming after us with pitchforks and flaming torches!".  I'm sure everyone would agree that rushing, cutting corners, and dealing with the resulting pain will take longer to get to the end of the job than taking that bit of extra time to do it 'the right way'.  But how do you deal with the crushing realities of hard deadlines and customer commitments (made by you or others)?  What if you just don't have the time to do it the way you want to? 

The challenge of course is trying to figure out where the line is - how far down the path of 'doing it right' do we need to go in this case?  Do I really need to do those unit tests?  How much of the code is worth getting reviewed?  How much should be done by pairs of devs? All of it? really?  Do we need an interface in this case? Is a dependency injection framework overkill for this? Will it take the new folks too long to understand the system if I do it that way? How much regression testing should we do? Do we need usabilty testing?

I don't have answers for those questions because obviously 'it depends'. I can say that I very much default to the answer that you should really really try to 'do it right the first time', and only make decisions to cut those corners in the light of the experience and wisdom of the real journeymen on your team.  No rule can be a replacement for the life lessons learned by those with the battle-scars, but those rules are a darned good starting place for all of the conversations.

In conclusion, I'd like to leave you with another set of rules. :) :)  These ones are by Eric S Raymond, and can be found here: http://catb.org/~esr/writings/taoup/html/ch01s06.html  They are the distilled wisdom of many of the developers who wrote the Unix operating system - some of the real 'elders' and journeymen of our industry. 

1. Rule of Modularity: Write simple parts connected by clean interfaces.

2. Rule of Clarity: Clarity is better than cleverness.

3. Rule of Composition: Design programs to be connected to other programs.

4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

5. Rule of Simplicity: Design for simplicity; add complexity only where you must.

6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.

7. Rule of Transparency: Design for visibility to make inspection and debugging easier.

8. Rule of Robustness: Robustness is the child of transparency and simplicity.

9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.

10. Rule of Least Surprise: In interface design, always do the least surprising thing.

11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.

12. Rule of Repair: When you must fail, fail noisily and as soon as possible.

13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.

14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.

15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

16. Rule of Diversity: Distrust all claims for “one true way”.

17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

 Cheers,

Allan

 1:  Imports MbUnit.Framework

   2:   

   3:  <TestFixture()> _

   4:  Public Class SampleCombinatorialTests

   5:   

   6:      <CombinatorialTest()> _

   7:      Public Sub CanAuthorizeValidAmounts( _

   8:          <UsingFactories("CCType")> ByVal CCType As String, _

   9:          <UsingFactories("ValidAmount")> ByVal amount As Decimal)

  10:   

  11:          Dim result = Payment.Authorize(CCType, amount)

  12:          Assert.AreEqual("success", result)

  13:   

  14:      End Sub

  15:   

  16:      <CombinatorialTest()> _

  17:      Public Sub CannotAuthorizeInvalidAmounts( _

  18:          <UsingFactories("CCType")> ByVal CCType As String, _

  19:          <UsingFactories("InvalidAmount")> ByVal amount As Decimal)

  20:   

  21:          Dim result = Payment.Authorize(CCType, amount)

  22:          Assert.AreEqual("fail", result)

  23:      End Sub

  24:   

  25:      <Factory()> _

  26:      Public Function CCType() As List(Of String)

  27:          Dim list = New List(Of String)

  28:          list.Add("Visa")

  29:          list.Add("MasterCard")

  30:          list.Add("American Express")

  31:          list.Add("DiscoverCard")

  32:          Return list

  33:      End Function

  34:   

  35:      <Factory()> _

  36:      Public Function ValidAmount() As List(Of Decimal)

  37:          Dim list = New List(Of Decimal)

  38:          list.Add(100.0)

  39:          list.Add(Decimal.MaxValue)

  40:          list.Add(0.01)

  41:          Return list

  42:      End Function

  43:   

  44:      <Factory()> _

  45:      Public Function InvalidAmount() As List(Of Decimal)

  46:          Dim list = New List(Of Decimal)

  47:          list.Add(0.0)

  48:          list.Add(Decimal.MinValue)

  49:          list.Add(-0.01)

  50:          Return list

  51:      End Function

  52:   

  53:   

  54:  End Class

  55:   

  56:  Public Class Payment

  57:      Public Shared Function Authorize(ByVal CCType As String, ByVal amount As Decimal) As String

  58:          Debug.Print(CCType & ", " & amount)

  59:          If amount <= 0 Then Return "fail"

  60:          Return "success"

  61:      End Function

  62:  End Class

The Results 

And here's the resulting MbUnit test suite from these few lines of code.

Summary

I hope this post has helped you to see just how simple it is to use MbUnit to harness the power of Combinatorial testing to improve real-world test scenario coverage in your applications.

SIW - System information for Windows.  From their website:

  SIW is an advanced System Information for Windows  tool that gathers detailed information about your system properties and settings and displays it in an extremely comprehensible manner.

I used it today to get ram specs on a server rather than shutting the server down and physically inspecting it.  Very cool tool:

I'm still amazed that my wife Shelley actually married me (26th anniversary this year!).  Both of our children (daughter Danielle, son Noel) have moved out of the house kind of recently so we're experiencing the 'empty nest' thing first hand.  We're now living on the beatiful waterfront of Pender Harbour, which is a bit north of Vancouver, BC in an area called 'The Sunshine Coast', although we lived in Abbotsford, BC for over 20 years.  You can find some pictures of our place here. Our Christian faith is imporant to us, and for many years we've supported and encouraged others to support several hands-on ministries - www.onemileclinic.org, www.partnersforhaiti.org, and the work of Norm and Jen Weir serving people in remote communities in BC. 

I suppose my first post on why I bothered putting up this blog in the first place will probably get kicked off the front page after a while, so I'll put a link to it here.