SQL Tip #1 | VPN Tip #1 | VPN Tip #2

Back Tips

SQL Tip #1

VPN Tip #1

VPN Tip #2

Multiple VPN Client Usage

Cisco VPN and SafeNet VPN coexistance

The following applies to the Cisco VPN Client Version 4.0.3 and SafeNet 8 - although of course it may work for other situations.

Detailed Problem Description

As part of my work, I need to access my customers' networks via VPN. Naturally, they don't all use the same VPN client software, and, equally obviously, the VPN clients are completely incompatible; the Cisco VPN client will refuse to install if the SafeNet client is installed (the reverse isn't true, but they just doesn't work if you try it).

Given that I have a primary PC on which I have my development tools configured, I don't want to set up another PC with all that stuff and switch between them.  However, the solution does require a second PC.

Solution

Since the two VPN clients cannot coexist on the same PC, they must be installed on two different PCs; one on the main PC, and one on a second PC.  We must then configure TCP/IP routing so that traffic that needs to use the VPN on the second PC routes its traffic to that PC, which then passes it through its own VPN.

Sounds simple, eh? Unfortunately, there are some catches.

The first thing to know is that the Cisco VPN Client does not permit routing through it from the local area network.  Fortunately, the SafeNet client does allow such routing.  This simplifies our choice; the Cisco VPN client must be installed on the primary PC, and the SafeNet on the secondary.

Secondary PC configuration

  1. Install the SafeNet VPN client, configure and test it.
  2. Enable IP routing.  On Windows 2000 and XP Professional this is achieved via the registry; create or set the following DWORD value to "1":

    HKLM\System\CurrentControlSet \Services\Tcpip\Parameters\IPEnableRouter

  3. Reboot the PC.

Primary PC configuration

  1. Install the Cisco VPN client, configure and test it. (If you're using Windows 2003 Server, well, you've got trouble my friend... but the answer is here.)
  2. Add the static route for the subnet accessed using the SafeNet VPN to indicate it is reached via the secondary PC, using the command prompt.  In the following example, the secondary PC has an IP address of 192.168.0.100, and the subnet reached via the SafeNet is 172.16.10.0

    route add 172.16.10.0 mask 255.255.255.0 192.168.0.100 -p

    Note the -p parameter makes the addition permanent across reboots.
  3. Stop redirection of ICMP packets (see below).  On Windows 2000 and XP Professional this is achieved via the registry; set the following DWORD value to "0":

    HKLM\System\CurrentControlSet \Services\Tcpip\Parameters\EnableICMPredirect

  4. Reboot the PC.

All traffic destined for 172.16.10.nnn will now be routed via the secondary PC.

Special note on ICMP redirection

"What on Earth...?" I hear you cry.  There is a subtlety to TCP/IP implementation on Windows that screws us unless we make the change outlined above

By default, when Windows TCP/IP sends a packet, it cunningly looks at the route that was actually used and sees if it can be optimized.  That is to say, for example, if sending to address (Z) is done by sending to (X), but (A) sends it to via the local router/firewall (Y), then Windows spots this, and creates an entry in the route table that says, "hey, to get to (Z), go via (Y).

Obviously this is usually a good thing - what's the point in going via point (X) if you need to?  Of course, in our case we HAVE to go via (X), since this does the VPN encryption stuff.

Fortunately, Microsoft (gawd bless 'em) gave us a means to switch off this intelligence, using the registry setting described above.  The symptom if you don't make this change is that the first packet that you send via ping (for example) gets through, but the rest do not, and an entry mysteriously appears in the route table.