Atomic
|
PC Authority
|
CRN Australia
|
iTNews
|
PC Authority Business Centre
|
SC Magazine
|
careers
Servers
PCs and components
Notebooks
Storage
Printers
PDA/Phone
Software/Applications
Security
Networking
Internet/Comms
Site Map
|
Newsletter
|
RSS
Search
all categories
Servers
PCs and components
Notebooks
Storage
Printers
PDA/Phone
Software/Applications
Security
Networking
Internet/Comms
Home
Breaking News
category
Servers
PCs and components
Notebooks
Storage
Printers
PDA/Phone
Software/Applications
Security
Networking
Internet/Comms
marketplace
compare prices
browse
Reviews
Features
In the labs
Downloads
A-List
Labs Winners
Recommended
newsletter
Register your email for our weekly roundup of business news, product reviews and articles that matter to business.
about us
advertise
contact us
magazine
how we test
Site map
Feedback
Home
>
Networking
> Setting up a Virtual Private Network (VPN)
Setting up a Virtual Private Network (VPN)
By Steve Cassidy
Email to a friend
Print this story
The devil is inside hardware VPNs. I can’t think of a single area of computing that’s as nasty as the VPN for wrong-footing well-intended technical managers.
This lamentable state of affairs was highlighted recently by someone who asked the charmingly simple question: “Where do I look for materials to help me set up my first VPN?”. The standard answer is that many technical authority figures like to wield to avoid being bothered by troublesome newbies is “off with you, read the relevant design documents and all will be revealed”, thus condemning the unsuspecting implementer to burial beneath a documentation tonnage equivalent to around half-a-dozen PhD theses.
Most design documents that relate to establishing a robust VPN don’t concern themselves with finding a good supplier, getting the right Internet connection or diligently training your users. In fact, they’re all about the strengths and weaknesses of various encryption algorithms, and in-depth critiques of VPN technologies that lie just around the corner, which never deliver any verdict on what we have available today.
I can now spot these simple souls, honest tradesmen with a basic job to do, who’ve been forced to negotiate this nightmarish combat zone. I was once stopped by a senior man at one of my client’s offices and asked whether the VPN I’d just put in for him “used IPSec”, as if this were some brand of petrol he’d prefer to have in his car.
The multi-talented ‘firewall’
Let’s get this canard out of the way as quickly as possible – yes, the boxes that operate VPN tunnels between sites are also called “firewalls”, but there’s nothing about the other jobs a firewall can do that makes it inherently suitable as a builder of VPNs. It’s just that one particular gateway in every LAN tends to collect all traffic-related tasks, and firewalls tend not to be fully occupied by keeping people out, so they’ve naturally ended up as the place to do such work (with certain exceptions). No, it’s not obligatory that your web-traffic firewall must also be your VPN endpoint terminus firewall. No, a “personal firewall” software application doesn’t qualify, even though various software vendors have been striving to get into this business.
Hardware VPN components
So let’s look at your archetypal twin-site, twin-device VPN. What does it need to contain? Each endpoint – I’m going to use that term instead of “firewall” to focus on the VPN architectural aspect – has a collection of IP addresses, some that define its position inside your LAN and some that define its accessibility from the rest of the planet. Ideally, each location participating in a VPN would have a globally visible, static IP address, but this isn’t an ideal world and it’s quite likely that a standard consumer Internet access contract won’t give you one. Don’t try struggling with dynamic or unrouteable IP addresses at both endpoints of your VPN – that’s a recipe for disaster. Almost all the VPN projects I’ve set up (or rescued) required a change of ISP to get the services required to support the biggest endpoint job.
VPN configuration
Each endpoint also has a management interface, and the most common way to deliver this is via a little website that appears on the internal Ethernet port of the box in question. There are some boxes that are simpler and you set them up via Telnet; there are others that are more complex and build the configuration in a program running on your PC, then bulk-upload it to the endpoint box. Since these endpoints also act as firewalls, there are usually heavy limitations on these management interfaces. I won’t identify the client who bought some firewalls to make a VPN and sent them off to each branch still in their boxes, confident they could log in to configure them from their external interfaces across the net. Needless to say, if a firewall were to allow such access when it starts up, virginal and factory fresh, it would be compromised by malware in a matter of minutes.
Inside the management interface then, reached from a simple, clean PC located within your network, is where you set up the attributes of your new VPN. Astute readers will have spotted that if you set up the two endpoints fresh from their boxes, each one will start out with the same internal IP address, which means you inevitably have to change the IP address of each device while being logged into it at its old address. All endpoint devices and firewalls can cope with this perfectly well – you just have to be ready to change the IP address of the PC from which you’re accessing them to match, to remain within the subnet that the devices are prepared to converse with.
Once you have the same VPN parameters in both endpoints and you’ve configured the LAN and WAN sides of each device to match the LAN and WAN IP ranges in each site, you’re ready to ship one of the endpoint devices to the remote office that comprises the far end, and try your first baby steps to a two-location hardware VPN.
Software VPNs
On to my summary of software VPN network designs. This isn’t going to be a simple roll call of product designs, inventors, RFCs or IEEE standards subcommittee designations. We’re an awful long way from the cosy meeting rooms of those standards committees, stuck in a world in which the majority of home PCs already have a virus or trojan infection; where wireless networks that are alleged to be secured take five minutes to crack so long as traffic keeps moving through them; and where identity theft is rapidly becoming the most frequently encountered criminal intrusion into our lives. The global slowdown in passing through airports, plus what appears to be a steep increase in hotel-based working, has put pressure back on to implement software VPNs mounted on the user’s laptop, so let’s have a look at your options.
1. Software VPN client to hardware product
This is the method of choice for larger networks afflicted with roaming users. A dedicated gateway device receives connections across the Internet from machines set up with the matching software client, generally by the central networking support group of the big corporation in question. The methods of hand-shaking and authentication can be elaborate, verging on the paranoid. RADIUS is the buzzword here, which covers a whole universe of ways of verifying that the guy connecting from a software client really is “one of us”, and what the user sees happening at their end is nothing to the blitzkrieg of lookups, key exchanges, proxy configurations, licence checks, and access rights assignments that then ensue at the far end.
2. Software VPN client to software product
With most of these systems, the laptop user runs a small local utility that sets itself up with a local private Ethernet address and then makes a connection through the Internet (however that may be presented – wired, wireless or cellular) back to the office LAN. The actual difference is that the end point for that connection isn’t the firewall or router that forms the remote LAN’s border device: it’s actually a full remote server that runs the company’s normal server operating system, but with an extra service installed dedicated to the business of receiving calls from VPN clients. With the dedicated hardware option, it’s generally the case that one very smart gateway device handles all the work, but in this case the gateway simply hands traffic on to the server that then handles authenticating the remote user and spoofing their traffic, so that the rest of the LAN users think they’re talking to a local machine.
I hate this option, not because there’s anything wrong with the design in theory, but because of what actually happens in practice. This design is frequently chosen by middle-sized businesses, because their tech team doesn’t fancy scaling the learning curve of a dedicated hardware device, or because they’re religious about following the Microsoft One True Way. Most commonly, these guys look rather askance at the admittedly difficult-to-master Internet and firewall standards, and hence make use of as few features in their Internet gateway as they can get away with.
3. Software VPN client and single Small Business Server
Here, the notion that a server makes a good recipient for VPN traffic is pushed about as far as it’s possible to push it. In a small business, (which I’d define as fewer than ten machines, although some truly boggling design documents on Microsoft’s site punt numbers like 100), so the story runs, it’s best to have every single job the company needs running inside one box. So you have – take a deep breath now – DHCP, DNS, AD, SQL, Exchange, ISA (Proxy), VPN and AV (anti-virus), file and print, and quite possibly a stunning OpenGL 3G screensaver, all hammering away at once, with all the LAN’s users dependent on every single one of those services (except perhaps the screensaver).
In one way, I absolutely love this design philosophy, because without it I wouldn’t have nearly so many clients, poor wretches who’ve fallen foul of one or another of these dodgy assumptions. But at another, less cynical level, I think it’s completely awful.
None of this has yet got around to talking about actual VPN products. You can always say with some degree of truth that all VPN client software does the same job: it tunnels through the net to shake hands with the exposed address of the gateway. But there’s a good deal of usability testing that you’ll need to undertake before you plump for any specific product. Systems that work well at home don’t always work so well for genuine roaming users.
As I’ve mentioned in the past about hardware-mediated VPNs, so far nobody has come up with a VPN client that knows how to preserve the integrity of a file you’ve opened for editing remotely, without the protection afforded by Terminal Services or Citrix Metaframe. Beware the creeping budget-buster – that sudden, horrid realisation that your “remote working project” needs a whole new technology platform to actually operate safely, over and above a VPN pipeline and some laptops – which has scuppered many a hopeful project manager.
Email to a friend
Print this story
SPONSORED LINKS
The new E-Series Projector from Sony. It's brighter than you think.
Related Features
No Related Features
A LIST - the best of the best
Printers
Brother HL-4040CN
Networking
Clearswift MIMEsweeper CSW250
Storage
HP StorageWorks Ultrium 1840
Servers
Evesham SilverEDGE 1000SL
Servers
IBM System X3550