In a networking industry that is currently a bit devoid of new concepts, one novel approach to secure remote access stands out from the crowd: SSL-based VPNs. The idea is straightforward: instead of using IPSec, which generally requires expensive hardware at the central office and specialised software to be installed on each client, why not use a mechanism – SSL – that is already incorporated in most client computers, since it comes free with packages like web browsers and email clients? Also, since SSL uses web protocols to operate, issues with remote users being the wrong side of firewalls that don't permit (say) IPSec or PPTP packets out to the Internet simply vanish when you use SSL instead. The FirePass (in our case a FirePass 1000) is F5's take on SSL VPNs. The unit is a turquoise 1U rack-mount device, with an LCD display, a serial console port and three Ethernet interfaces on the front panel. The back of the unit houses just the mains socket and the on/off switch. The Ethernet ports are, from left to right, the DMZ, LAN and WAN interfaces. The box itself ships with set of rack-mount brackets, an Ethernet cable and a (US) mains cable, along with a CD that contains just the documentation for the unit (180-odd pages of PDF). Note at this point that the FirePass is _not_ a firewall in the traditional sense of the word. It sits alongside a corporate firewall, not in place of it – and in fact you would put the FirePass inside your existing firewall, and permit the required connections through the existing firewall so that the FirePass can deal with them. Step one is to plug in and turn the box on. Although under the surface the FirePass is a Linux-based PC (apparently Red Hat, from what we noticed in the startup logs), you don't connect a monitor; fortunately you get visual indications of what's going on via the LCD panel, and the unit gives audible beeps in certain sequences when important things have happened (e.g. it's shutting down, or it's finished rebooting). If you connect a terminal or a PC with terminal emulation to the console port, you can see the boot messages flying past, which gives you an indication of progress (in fact, the majority of the time it takes to start up is the power-on memory test of the 512MB internal RAM). Into the DMZ
To set up the unit, you can either use the terminal interface or access the management web interface. It took a little trial and error for us to figure out that you should connect your management PC to the WAN port in order to set up the initial IP configurations, since the manual said to connect a PC to the FirePass but didn't give any clues as to which hole to stuff the plug into. Configuring the interfaces' addresses is okay if you're a networking specialist (and you can figure out that interface "eth0" is the WAN port, "eth1" is the LAN port and "eth2" is the DMZ) but we found it annoying that as well as giving it the IP address and network mask we also had to dredge our memories for how to calculate broadcast addresses (come on, F5, your software should do that itself – Linux's ifconfig command does, after all). Once you've configured the IP parameters, you can go ahead and use the box itself. Management is all done via the web interface (though if you muck things up completely, the serial console is there to get you out of trouble, and to help you do some basic diagnostic stuff like examining low-level IP configurations and using simple network tools such as traceroute and ping). When you get started, you'll need to install the appropriate licences in order to enable the box's various functions. This is an automated process, as the unit connects to F5's headquarters over the Internet and pulls down its various authorisation information; once this is done, a quick reboot (again – the setup process is simple enough, but the box does have a penchant for rebooting to make changes) and you're ready. The FirePass system uses a collection of so-called "Webifyers" to act as the interface between the remote client computer and the corporate application. There are a number of Webifyers, including: • My Files: allows the remote user to browse the corporate Windows LAN from afar and work with his or her files. • My Desktop: complete remote control of a user's desktop (not unlike the My Terminal Services option, below). • X-Windows: rather like My Desktop, but interfaces to an X-Windows-capable Unix system rather than a Windows computer. • My NFS: like My Files, but for Unix-style NFS filesystems. • My Intranet: allows browsing of internal corporate Web servers that wouldn't normally be accessible from outside. • My Email: gives POP/SMTP/IMAP access to internal mail servers via a Web interface. • My Terminal Services: an interface to Windows Terminal Services sessions. • Host Access: provides Telnet or IBM-specific (TN5250/TB3270) access to minicomputers and mainframes. • AppTunnels: while all of the Webifyers listed above are effectively proxy services, AppTunnels is more of an application-specific pass-through mechanism that allows more low-level access to applications like Oracle, POP mail servers, and such like (you'd use this if there wasn’t an application-specific Webifyer for a particular application). • SSL VPN: the biggest cop-out of all, which lets you run a general, catch-all VPN connection just like a traditional IPSec one but using SSL instead; you'd only really use this if you had weird and wonderful proprietary stuff that wasn't dealt with by the Webifyers we've already mentioned. Configuring the Webifyers is pretty straightforward thanks to a sensibly designed web interface. We played with a number of them, to see how simple they were to fly. We tried out the Host Access module using a Linux-based remote host, connecting using the SSH protocol. Everything worked a treat, though the default text size and colour were a little hard on the eyes. The Email interface can be configured with the user's personal details (full name and return address) or told to prompt the user for this information when they first connect; when each user connects, he or she is asked for their mail server ID and password, and they're presented with a perfectly acceptable Web interface onto their mailbox. Next, My Files. You configure a set of mappings in the FirePass, in which you're basically allocating shortcuts to Windows file shares. You can either use explicit share names (e.g. a common public folder) or incorporate the user's group/user ID (e.g. if each user's personal folder is named something like \users\<username>). When the user connects, they're told the various items they can access, and if authentication is required they're asked for the appropriate user ID and password. Once they've entered the information, they're given a Windows Explorer-style interface onto their filestore; a neat touch is that any files they transfer can be automatically zipped on the way, in order to speed the transfer up. Then came Terminal Services. Selecting this option in the client screen prompted us for the hostname to connect to, and the type of connection (it supports not just Windows Terminal Services but also Citrix Metaframe and VNC servers). When you're configuring the user's settings in the admin screen you select their default screen size, and this is used when they come in and connect. For Terminal Services connections the user's PC downloads a plug-in, but it's not huge and took only a few seconds in our test. It's a wonder
All in all, we found the FirePass a wonderful piece of kit. The Webifyers, despite having a silly name, all appeared to work without a hiccup, and although some of the functions (such as Terminal Services and the SSL VPN function) require a software download, which can mean the administrator having to bugger about allocating installation keys to users, this isn't an onerous task and it's not something you have to do every day. The range of features is good, the integration of the unit with existing network systems (RADIUS, Windows domain servers, DigiPass, etc, etc) is extensive, the logging/monitoring/stats/diagnostics side of life is excellent … it's just, generally, a fabulous piece of kit. Another one for the Christmas list then.


Boxes of this type sit inside the corporate firewall, and provide a more secure means of accessing internal applications than simply allowing services such as Terminal Services or POP/SMTP through on a port-by-port basis. For proper security, you'll want to understand how digital certificates work, and apply them to your SSL security policies.