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.