Virtual private networks: Have it your way

This month we have a pretty complete look at your options for virtual private networks. The Two Mikes are looking at the two types of VPNs – SSL and IPsec – and I am looking at a tool for managing data traveling over an SSL VPN. Mike Stephenson handled the SSL products while Mike Lipinski reviewed the IPsec products.

While there are, of course, two major types of VPN products – SSL and IPsec – they are not interchangeable and they really don't compete with each other. If you are looking at using a VPN for a secure connection, there are many issues to consider. For example, are you trying to secure a consistent point-to-point connection or are the connections you want to secure ad hoc? This can be a bit controversial because, as you would expect, all the VPN vendors want you to use their products, but one size absolutely does not fit all in this case.

My rule of thumb is: If you want an ad hoc connection, SSL VPN probably is your best bet. If you are looking for a nailed connection, IPsec usually should do the trick. There are exceptions, of course. Sometimes an ad hoc connection really is a nailed link in disguise. In other words, the path is the same, but the connection is on again/off again. You may want to consider IPsec for that, depending on the nature of the connection.

IPsec can be very challenging to deploy. I recently had an experience where we tried to connect a firewall and a router using an IPsec tunnel. The firewall and the router were from the same manufacturer so it should have been a walk in the park, right. Wrong! Emphatically wrong. Both ends – on different continents – struggled for a couple of days and then decided to go router-to-router. It took about 15 minutes once we made that decision.

The trick for deploying IPsec VPNs is cooperation between the two ends of the tunnel. First, you need to decide how deep you want your encryption to go. Do you want to do a true end-to-end circuit or will border-to-border do? In our case, we were looking at connecting from one border to just inside the other. That is preferred to punching a hole in the firewall, but when you can't, you can't.

Second, you need to decide which end will control the parameters on the implementation. Pick one end and let that end determine the configuration on both ends. This greatly simplifies the process. Of course, the person on the end that is setting the parameters needs to know what they are doing but, for our purposes, anyway, we'll assume that as a given.

SSL VPNs are easier to deploy, but are nowhere near as plain vanilla as IPsec VPNs. SSL products have a lot of permutations that you need to consider. For example, do you need a nice web portal for the remote user to connect to? Or, are you going to roll your own portal and just tack on the SSL VPN? This is just one question of several that I'll take up later in my column at the start of the SSL VPN review.

The bottom line is: Do what you need to do to get your particular job done. Never mind vendor hype. All of these products are good, but they are not all interchangeable. Remember that and you'll be well on your way to a solid implementation that fits your application like a glove.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.