Monthly Archives: October 2004

VPN over SSL is only acceptable

Companies have different ways of implementing and securing their corporate networks. The ways to secure a corporate network are too numerous to mention here, let alone add any substance to. There are a variety of vendors providing copious amounts of networking and security hardware.

I have a customer that is using an SSL based VPN solution, to allow access for it’s employees and partners from offsite locations. This is one of those technology solutions that looks fabulous on the proposal from the vendor to an infrastructure group, but leaves a little to be desired when it comes to using it on a day to day basis.

Take for instance, a Juniper Networks product formerly called NeoTeris. The premise is simple, install the device in your “Public Zone” and give it access to your corporate network. Configure it to authenticate against a Windows Domain server. Employees hit a website, secure.mycompany.com, log in with their username and password, and then it’s just like being on the corporate network without any special software. Well, not exactly.

There some limitations to this approach… Mostly related to performance, but some as it relates to functionality. The implementation of this system involves the download of an applet that routes traffic via SSL to and from the remote server. When access remote applications (SQLNet, JDBC, VNC, ssh, Windows Share, etc) the most notably drawback is latency. The network packets are being processed by an embedded java applet before being routed over SSL, which for those who are familiar with those two technologies you’ll understand why they aren’t well suited to quick, instantaneous packet forward. Throughput is minimized as it appears (I don’t know if this is, in fact, true) as if the applet is chunking data into packets according to a rigid configuration, rather than using the great TCP/IP feature of ratcheting.

The features are somewhat limited in that because a VPN system has just placed you on the remote network, you are required to configure applications port by port. For most applications this is acceptable, as you connect through them to a certain port, and life is good. There are some applications that change up their ports, and come configured by default to “move to another port” or are built to do so (you can’t turn it off). Because one must configure the ports of the system individually, a user of the SSL based system has no chance of using these applications because they couldn’t possibly guess the port ahead of time.

Overall it’s an application that provides remote access for a great number of people, with a great provisioning model, works for most applications, and is alright for occasional home based use. My experience stretching one customers installations to the limits to do my work for them, indicate that it’s not very suitable for remote workers. Remote workers that expect their remote applications and access to a corporate network be a similar experience to their commuting peers, will be disapointed with VPN over SSL. Companies should know that if their needs are limited, this is a good solution. If you have remote workers who might expect a good remote experience, they should stay away from VPN over SSL.

6 weeks and some new digs

For those paying attention (there are a few of you out there), you’ll notice that my blog (formerly nicholas goodman, consultant extraordinaire) has been folded into a new bayon blog.

bayon, my small boutique BI consulting firm, may invite other people to contribute to the world of Oracle, BI, Grid Computing, etc.

You may also have noticed that there has been a significant gap in time since my last post. The upside of my recent relocation from Boston, MA to Seattle, WA is that I’m in a beautiful new city with so many outdoor activities to chose from. The downside is, that for the past 6 weeks I’ve been surviving my projects, moving, etc.

Hope to get the observations flowing soon enough.