See also: f5vpn-login.py, described here, and brought to my attention by sh4k3sph3r3. A CLI FirePass client is quite likely a better solution than separate browser instances, etc.

Preliminaries: Although the F5 FirePass SSL VPN product supports Linux, as best as I can tell, that support is somewhat limited: My understanding is that they officially claim support for 32-bit installs only, and they do not appear to track new distribution releases particularly aggressively. F5 has also been somewhat slow in supporting new browser versions: They announced support for Firefox 3 on October 6, 2008, nearly four months after its release and with only two months to go before Firefox 2 was end-of-lifed. For Firefox 3.6 support, a comment on the post linked above states that you need to request a special hot fix from F5 (which my site has not applied). There is no Google Chrome support that I am aware of.

Further, F5’s automated client installation tools have unfortunately never worked for me on Linux, even when the architecture and browser are in their support matrix. The manual download instruction links are also broken on the FirePass install I connect to.

Solution: Install a dedicated, 32-bit version of Firefox in a supported version; create a single-purpose Firefox profile for VPN use. Add the FirePass client to that browser and the operating system.

For the Firefox install, follow the “Manual Installation” instructions from the Ubuntu Community Documentation site. Install version 3.5 if your site does not have the hotfix mentioned above.

Be sure to create a new Firefox profile in your account for use with the FirePass; however, I recommend modifying the script in the Ubuntu documentation to automatically take you to your FirePass site (https://firepass.example.com/ for the purposes of this post):

#!/bin/bash
exec "\$HOME/firefox/firefox" -P mozilla-build https://firepass.example.com/

Next, download the client components from your F5 site; again, assuming firepass.example.com, retrieve and save:

https://firepass.example.com/vdesk/vpn/nogzip/downloads.php/linux/np_F5_SSL_VPN.so

and

https://firepass.example.com/vdesk/vpn/nogzip/downloads.php/linux/SSLVpn.tgz

Move np_F5_SSL_VPN.so to the plugins directory of the new Firefox installation – ~/firefox/plugins if following the Ubuntu documentation. Based on file layout, it appears that F5 intended for you to extract SSLVpn.tgz at the root of your file system. Instead of following this bad practice, in scratch space and as root, extract the SSLVpn.tgz tarball and manually move the files into place:

cp SSLVpn.tgz /tmp
cd /tmp
sudo tar -xvpzf SSLVpn.tgz
# inspect extracted files here...
cd /usr/local/lib
mkdir -p F5Networks/SSLVPN
cd /tmp/usr/local/lib/F5Networks/SSLVPN
cp -Rp etc svpn var /

Using the bash script above, you should now be able to launch your purpose-built FirePass browser installation and have it “just work” for Network Access. Good luck!

Here’s our in-house procedure for recovery; note that we do not have FlexClone licensed on our filers.

Prerequisites

• An existing VMware ESX infrastructure, connected to a NetApp filer NFS datastore; SnapRestore speeds the recovery process but is not mandatory – see discussion below.
• A backup script or system which coordinates VMware snapshots with NetApp snapshots – perhaps something along the lines of Rick Scherer’s script.
• A dedicated Linux restore VM, at a similar version level to the rest of your Linux VM infrastructure. This VM should have LVM support, but should not have any volume groups (VGs) or logical volumes (LVs) configured – volume group and logical volume names on the VMDK you are restoring from must not conflict with VGs and LVs already in use on the restore system; the simplest way to guarantee this is to simply not have any VGs or LVs.

Restore Procedure

• Restore the VMDK file from the appropriate snapshot to a new location in the datastore. With SnapRestore, this can be done as follows (one line in the filer CLI, restoring from snapshot sv_daily.0 to a new file – again, be extremely careful not to overwrite the current version of the VMDK in your datastore, consider restoring to an entirely different directory in the FlexVol):

  snap restore -t file -s sv_daily.0
-r /vol/vmware04_sis/system.example.com/system.example.com-restore.vmdk
/vol/vmware04_sis/system.example.com/system.example.com.vmdk

  Follow the prompts, verifying the restore path is correct and is not the path to your existing VMDK. Do the same for the flat VMDK file (again, one line, and, as before, use caution to make sure you do not clobber an existing file):

  snap restore -t file -s sv_daily.0
-r /vol/vmware04_sis/system.example.com/system.example.com-restore-flat.vmdk
/vol/vmware04_sis/system.example.com/system.example.com-flat.vmdk

  Without SnapRestore, you can simply mount the NFS export of the datastore on a Linux machine and use “cp” to copy the files out of the snapshot. For flat VMDK files, expect this copy to run for a substantial amount of time compared the nearly-instant recovery SnapRestore offers.

• Manually edit the line below “# Extent description” in the recovered .vmdk file to match the path to the recovered flat VMDK. In this case, it would look something like this:
  # Extent description
RW 20971520 VMFS "system.example.com-restore-flat.vmdk"
• Attach the recovered VMDK to your powered-off restore host. Boot the restore host.
• Once your restore host is up, use “pvscan”, “vgscan” and “lvscan” (each without arguments) as root to examine available LVM components. Then, use the “lvchange” command to activate the necessary volume group (in this case, “VolGroup00″):
  # lvchange -ay VolGroup00
• Mount the appropriate logical volume – for example, LogVol00 in VolGroup00:
  mount -o ro /dev/VolGroup00/LogVol00 /mnt
  Restore files by copying them out of /mnt.

Cleanup

• Shut down the Linux restore host.
• Remove the recovery VMDK – the files restored with SnapRestore or by “cp” above – from the restore host in the VMware Infrastructure Client.
• Delete the recovery .vmdk and -flat.vmdk files in the NFS datastore. Don’t screw up here: Be sure to delete the recovery files only, not the working VMDK.


The CentOS installation tree in that directory does not seem to match your boot media.


The solution? Download the 5.1 DVD iso image, copy its contents to your disk and re-run the “pxeos” command to use that as your installation tree.  I’m not sure if this was an oversight or a conscious change on the part of the CentOS project (or if the yum repository method was never supported in the first place), but it stumped me for a little while, so I thought I’d post it here.