ICS (Internet Connection Sharing) disturbed by VPN client software

Setup: [Computer]---[ICS Computer]---[Internet router]---Internet
The ICS Computer runs Vista, Computer runs Windows XP, Windows Server 2000 or any other.
The ICS Computer also has one or more VPN client software packets installed. In my case, the Checkpoint SecuRemote VPN client and AnchorFree HotSpot Shield were installed, but not running at the time where this problem occurred.

Problem: Computer can not browse websites, Skype will not log on, FTP to internet FTP servers will not work. Computer can however ping all destinations, local as well as internet addresses using DNS names or IP addresses.

Obviously, some (ICMP/ping and DNS requests), but not all of the network traffic is correctly passed through the ICS Computer. After having played around with disabling any firewall on Computer and ICS Computer without any improvement, i tried the following:

Solution: I removed the two software pieces known to create virtual network interfaces on the ICS Computer, hence the CheckPoint SecuRemote and AnchorFree HotSpot Shield had to go. Reboot, and voilla, it worked!

Prime suspect: Since the AnchorFree HotSpot Shield was still wanted on the system, I reinstalled it. ICS still works, bringing me to the strong assumption that the CheckPoint SecuRemote was the one that messed things up.

The Nerd's little blowout: I have been working with a variety of VPN software client solutions, like Cisco, CheckPoint, RSA etc.. In my experience, they all have in common that they in various forms deprive you of an unrestricted simultaneous access to other network segments that are normally accessible from your computer. Try connecting a VPN client and at the same time access your local LAN server. You have luck if it works. Try reaching two different remote sites over two different VPN clients at the same time, and you may even see the good old bluescreen of death. Try running ICS to let another computer connect to the internet on a computer where VPN client software is installed - you get ping and DNS and nothing else. Now THAT's why I'd rather have any VPN link over site-to-site VPN on dedicated VPN routers.

Tunnelling a subset of a routed subnet on a Juniper Netscreen

(This post assumes that you have a general knowledge of setting up a Juniper device for VPN tunnelling).

The following chain represents my setup:

(internet) --- [Internet router] --- [Juniper Netscreen] ---(LAN)--- [Router] ---(General 10.0.0.0/24 network segment)---

On the Juniper device*, this means that a route of 10.0.0.0/8 is pointing towards Router. In addition, a default route is pointing towards Internet router, allowing for comptuers on LAN (which has the Juniper device LAN IP set as their default gateway) to reach both the 10.x.x.x computers behind Router and to reach internet destinations.

Now I want to create a VPN tunnel over the internet to some other place, tunnelling to that place's internal network 10.10.10.0/24.

Problem: Because of the route of 10.0.0.0/8 is pointing towards [Router], even packets destined for 10.10.10.x-addresses are routed that way. Normally on a Netscreen device, having set up policies for the VPN traffic is enough to route through the tunnel, but routing entries seem to take presedence over policies.

Solution: Set a Metric higher than 1 (e.g. 10) for the 10.0.0.0/8 route. Then create a route of 10.10.10.0/24 pointing towards the [Internet router] IP address (this would be the same as your default gateway points to, of course a public IP address). The 10.10.10.0/24 route will by default receive a lower metric and therefore have priority over the 10.0.0.0/8 route.

Gotcha: Of course, this means that you will not be able to reach 10.10.10.x computers on the network behind Router. You literally can't have it both ways...

* I have done this on a Juniper Netscreen 5xp, but I would assume this would work on all Juniper devices, for instance the successor Juniper SSG.

DDE on XP/2003

Ever tried porting a DDE app to Windows XP/2003 that you know worked under Windows NT/9x? It just won't communicate. Having found the problem twice and then forgotten again, here's the note on what is (normally) wrong:

The NetDDE services (Control Panel-Administrative Tools-Services) need to be started. Set startup type to automatic (they are disabled by default), and to avoid rebooting the first time, start them as well.