One of the quickest and easiest ways of building a secure virtual private network (VPN) is through the use of the Windows Routing and Remote Access Services (RRAS). No special hardware or extra software is normally needed, and the latest Windows Server 2003 implementation offers enhanced support for NAT (Network Address Translation) protected networks plus a NetBIOS proxy to make it easier to navigate around remote networks. New quarantine facilities have also been added - to bar access where clients are poorly configured – together with useful scalability enhancements through network load balancing.

What's needed
Windows servers can be used for both site-to-site and site-to-client VPN deployment with, in both cases, at least two network interfaces required. One connects the server to the local network, the other to the Internet – typically via a router.

Although an existing host system can be used, a dedicated server is to be recommended as a static public IP address is normally required on the Internet side. Fortunately, that's not as bad as it sounds as, by default, the RRAS software will filter out everything other than VPN traffic, making the VPN server reasonably secure even when located outside normal firewall defences. Where a firewall is employed, however, the appropriate ports need to be opened, to enable the VPN protocols through (details can be found in the RRAS documentation).

The other interface simply requires a local IP address. However, this will need to be on a different subnet to that of the remote network and any remote clients. If it isn't, the software will be unable to differentiate between local and remote traffic and the VPN simply won't work.

Putting it all together
As with most other Windows Server 2003 services, RRAS has to be explicitly enabled with the usual wizard on hand to help with initial configuration. Using this, you decide first on the type of VPN to configure – either site-to-site or site-to-client - then the network interfaces to use. You're then asked whether you want to assign client addresses using an existing network DHCP server or dole them out from a list reserved solely for remote VPN access. Lastly, you can choose to use RADIUS for client authentication or leave it all up to Windows.

That's about all that's required at the server end. Once finished the wizard will install RRAS as directed with support for both the Point to Point Tunnelling Protocol (PPTP) and the more secure Layer 2 Tunnelling Protocol (L2TP) combined with IPSec and DES encryption. PPTP is the easiest to work with as it uses pre-shared encryption keys rather than digital certificates, although in Windows Server 2003 the same facility has now been added for L2TP/IPsec. Some care, however, is needed as, although fine for a site-to-site VPN, enabling pre-shared keys on a Windows client can be tricky and for maximum security, a public key infrastructure is still recommended.

The VPN server is managed via an MMC (Microsoft Management Console) snap-in, located in the Administrative Tools folder. Through this simple remote access, policies can be configured to control access based on client MAC address, time of day, protocol and so on. Access can also be managed on a per user basis (by default, all users are denied remote access) plus with Windows Server 2003 it's possible to quarantine clients that fail to meet pre-set hardware/software requirements, using the separate Connection Manager Administration Kit (CMAK).

What the client sees
No extra software is needed for a site-to-site VPN, but for individual PCs to create encrypted tunnels a VPN client is required. Fortunately with Windows 2000 Professional and XP, a client is included as standard, with clients for other platforms also available.

With Windows 2000/XP, it's a simple matter of running the New Connection wizard and providing the name of the VPN server (if accessible using DNS) or it's IP address. A dial-up ISP connection can be established first, if required, and by default the Windows software will try to create a PPTP tunnel first then L2TP/IPsec, although either can be forced, if necessary. Assuming this is successful the client is then able to access the remote network, more or less, as if working locally.

We say more or less because, prior to Windows Server 2003, locating resources could be problematic since NetBIOS naming information isn't propagated over the VPN tunnel. That meant configuring local DNS and WINS servers or using IP addresses rather than names, something the new NetBIOS over TCP/IP (NetBT) proxy in the 2003 implementation helps resolve. That aside, it's still a good idea to use mapped drives rather than continually browse for information, especially where inexperienced users are concerned

Finally, it's important to appreciate that most VPN tunnels will have far less bandwidth compared to a local network. It's advisable, therefore, to install and run applications locally and to copy large files to the local disk to work on. Not forgetting, of course, to copy them back again when finished.