OpenVPN service dependency service failed to start (Error 1068)

Problem: I wanted to start OpenVPN as a service so that I could use a Windows Server 2003 as a router for an OpenVPN connection. The service would not start even though I set it to start automatically from the Services app in Administrative Tools, claiming error 1068: The dependency service or group failed to start.

There's a lot of people complaining about this error out there, but I could not find a better answer around than reinstalling the OpenVPN software. I am not a big fan of reinstalling without getting to the bottom of the problem - it means you haven't learned anything useful for the next time you encounter the problem.

Investigation: In the process of setting up OpenVPN, I had installed a previous version of it some time ago, and then reinstalled at a later time to get the latest version. By examining the system event log, I discovered that together with an error message (event 7001) for an unsuccessful start of the OpenVPN service, there was also an event ID 7000 stating that "The TAP-Win32 Adapter V8 service failed to start". Funny, since my TAP virtual adapter that came with the (latest) OpenVPN installation was marked V9, not v8. That nailed it:

Solution: The OpenVPN service referenced an older version of the TAP virtual adapter than the one now installed. I changed the following registry value:

HKLM\System\CurrentControlSet\Services\OpenVPNService\DependOnService

...from "TAP0801" to "TAP0901", rebooted and the OpenVPN service had already connected by the time I was logged in.

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.

CheckPoint VPN keepalive kills the tunnel

I had the strangest experience when setting up a CheckPoint VPN device the other day. The tunnel built fine, but sometime between a few seconds and 1-2 minutes after coming up fine, it logged a "no proposal chosen" and went dead again. I researched every parameter with no luck, until I came to a checkbox on the last screen of the CheckPoint's VPN tunnel wizard stating something like "Keep this tunnel alive." Naturally I had wanted to keep the tunnel up, so I had checked it.

Funny thing, not until I cleared it again, the tunnel became rock stable. So, as long as you don't ask it to, it keeps your tunnel alive. I guess it just does not like being pushed around...

How to talk to a remote device that only talks to local network devices

I was asked to find out how to spare an engineer the trip to his customer abroad only to do a five minute's upload job to a device that was talking TCP/IP. The device was on a subnet that had a VPN site-to-site connection to his office, however, the device did not have a routing entry making it aware of the subnet on the other side of the VPN tunnel.

Because of limitations to the device, configuring the needed routing entry into the device was not an option, even if we were able to telnet into the device from a Remote Desktop session on a Windows computer on the same subnet.

Solution: The solution was to create a simple PPTP VPN dial-in access on that Windows computer, so that the engineer's computer could receive an IP from the same IP pool as the device he wanted to control. Yes, it meant creating a PPTP VPN tunnel back through the established site-to-site VPN tunnel, but it would work.

Caveat: Only trouble was, it didn't. Setting up a simple Routing and Remote Access server in Windows Server 2003 is a simple task, still, it just did not work. What I found after scratching my head pretty sore was that the firewall in the site-to-site VPN device on my side (the one responsible for the "outer" tunnel) was blocking all traffic that did not originate from my subnet. The PPTP GRE protocol packets from the remote site did not look like they were talking to established traffic from my side, and hence was blocked, effectively blocking the creation of the PPTP tunnel within the site-to-site tunnel. To make it work, I had to open the firewall on the site-to-site device to allow full traffic flow while running the PPTP tunnel.

After that it worked, but was quite slow, probably due to the double encrypted, double tunneled packets.

Narrow-masked site-to-site VPN caveats on a Checkpoint device

I consider myself to be relatively experienced in setting up site-to-site (LAN to LAN) VPN tunnels, and to pinpoint what is wrong if the tunnel does not come up, but working today with a technician on the other side of the Atlantic to set up such a link turned out to be a challenge.

We had agreed on all cryptographic parameters, on what private subnet to be used on each side of the tunnel and of course the preshared key. The guy in the other end seemed experienced enough, but going over and in a structural manner fiddling each parameter to try to find a match did not give the break. The scenario was quite funny:

Scenario: Tunnel clears phase 1 of the negotiation, meaning that the preshared key and the IKE parameters are a match on both sides. In phase two, some discrepancy makes a "no proposal chosen" message appear in the logs on the Checkpoint.

Strange: Even though the tunnel did not come up on the Checkpoint side, it did on mine. I was able to ping devices on his side, but he was not able to ping my side.

Solution: After having tested virtually everything, the guy on the other side mentions that his device has defined a class B private network on the interface. The tunnel definition, however, was to be for a much narrower range, a 29 bits mask (255.255.255.248). Although it would be shooting sparrows with a cannon, we broadened the tunnel definition to match his device's network interface, and voilla, it worked! It seems to be a limitation of the Checkpoint device this guy was using (or a limitation of knowledge on how to configure this device correctly) - I have without trouble set up dozens of other links with a narrower tunnel IP range than what the device is running on its network interface.

Caution: If someone else experiencing a similar problem is reading this, my advice would be first to check any firewall that might be blocking traffic (it was my first guess). If you can temporarily isolate vulnerable parts of your network while testing your new tunnel, I would first bring up the tunnel with the firewall completely off.

MTU too large, communication stalls (under research)

I have been researching this problem for some time now, found a workaround, but no problem reason and no good permanent solution:

Environment and problem: LAN1 is connected to LAN2 via a LINUX PC with two network interfaces, running NAT in both directions. On LAN2, a VPN device has a site-to-site VPN tunnel over the internet to a remote LAN3. When computers on LAN1 tries to talk to computers on LAN3, it works well on some computers, while on others, all comms stalls after a few packets. There are other LANs connected to LAN2 via the same VPN device where the problem never occurs.

Clue: When connecting to LAN2 over a VPN client from a remote location, the communication to LAN3 always works.

Technical details: Using the Ethereal Wireshark network protocol analyzer, a bunch of TCP DUP ACK messages occurs around the time of the freeze.

Workaround: On computers where this is a problem, if the MTU value of the network interface used is modified to 1300 (or 514 hex), the problem goes away. This is done here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ID for Adapter
For a reference on this value, see Microsoft Knowledge Base art. no. 314053.

Potential negative effects of workaround: Smaller MTUs cause more network overhead because smaller and thereby more network packets must be transmitted, all with their own network packet header. In practice though, I could see no negative effect in my case.

Problem cause: Not found. The MTU that should have been used for the overall transfer should have been determined by the lowest MTU given by any router along the path the packets take. My assumption is therefore that some router "out there" is set up with a MTU larger than the network packet size it can actually handle (is this possible?). It works for the first few packets, then the router gets overloaded and freezes.

Permanent solution NOT found: A permanent solution where the MTU value of each client computer is untouched has not been found. Given that my assumption is right, a permanent solution can only be found if the router working under false MTU conditions can be identified and accordingly modified.

Further research: I want to try setting the MTU of the interfaces on the LINUX computer that routes between LAN1 and LAN2 to 1300. If my theory holds, this should lower the overall packet size so that the problem goes away. Since traffic load between the two LANs are never significant, it is acceptible in my case to live with that, even though it does not address the problem at the router that I assume is causing the real problem.

UPDATES ON MY RESEARCH WILL (may) FOLLOW