Archive for March, 2011

Fortinet SSL VPN interface limitations

Saturday, March 26th, 2011

There seem to be some interface related limitations with the SSL VPN implementation on Fortinet’s FortiGate firewall devices which prevent you from connecting to the Fortinet SSL VPN on the IP address of an interface other than the one which your traffic enters the firewall on.

In other words, even with the appropriate rules configured in the firewall policy to allow your traffic to pass through the FortiGate between the interface that it is received on and the interface which that SSL VPN traffic is destined for, the FortiGate unit doesn’t respond.

I have been able to verify that this bug/feature is present in the latest build of FortiOS 3.0, but haven’t been able to test with any of the FortiOS 4.0 releases yet.

In my case, this was a problem because the WAN interface has a private IP address on it with a block of public IP addresses routed to the unit and in use on the LAN interface. In the end I worked around this by routing a single additional public address to the unit and configuring it as a secondary address on the WAN interface with a /32 subnet mask. The SSL VPN could then be accessed from this public IP address.

Recovering Logical Volumes deleted with lvremove

Sunday, March 20th, 2011

Need to recover an LVM Logical Volume that you deleted by mistake? No problem, luckily LVM archives all of the old Logical Volume and Volume Group metadata in /etc/lvm/archive/ whenever you use something like lvremove to make adjustments to the Logical Volumes.

Before you start, remember that any kind of operation like this is potentially dangerous and so backup anything of importance on the intact Logical Volumes. Also, as a safety net, backup the contents of /etc/lvm just in case and then run “vgcfgbackup” to put an up to date copy of the metadata in /etc/lvm/backup.

Now look for the appropriate file in /etc/lvm/archive. Each LVM operation will create a file in here with the name of the affected Volume Group and an incrementing number. By default on RHEL/CentOS this will be “VolGroup00”, so you will be looking for /etc/lvm/archive/VolGroup00_xxx.vg where xxx is the appropriate increment.

If you open up your chosen file in your favourite text editor you should see a line that starts “description” and has something like “Created *before* executing ‘lvremove -f /dev/VolGroup00/xxx'” on it. You can use this to verify that you have the right file.

The next thing that you need to do is verify that this file has valid metadata and thus will be useable. To do this, you can use the vgcfgrestore command in a test mode that will perform a dry run. Assuming you are trying to restore Volume Group VolGroup00 from VolGroup00_00161.vg, this would look like:

vgcfgrestore VolGroup00 –test -f /etc/lvm/archive/VolGroup00_00161.vg

Which will return something along the lines of:

Test mode: Metadata will NOT be updated.
Restored volume group VolGroup00

Assuming this all went well, you can now re-run the same command but without the “–test” option:

# vgcfgrestore VolGroup00 –test -f /etc/lvm/archive/VolGroup00_00161.vg
Restored volume group VolGroup00

Now run an “lvscan” and you should see your missing Logical Volume(s) have returned, but are inactive. Re-activate them with “lvchange” and you are back in business, just be more careful next time 😉

lvchange -a y /dev/VolGroup00/xxx