How to install pfSense in DigitalOcean

Inspired by this post, I’m basically re-creating it with copy/paste commands instead of images of the commands and updating the partitioning portion as I found some steps the original author took are no longer required.

Create your droplet

  1. Login to your DigitalOcean Dashboard and create a new droplet
  2. Select ‘FreeBSD 11.1 x64’ as your droplet image
  3. Select the data center region of your choice
  4. Check mark ‘Private Networking’ and ‘IPv6’ if you want it
  5. Add your SSH key
  6. Enter a hostname
  7. Click ‘Create’

Once the droplet has been created boot it up, grab the public IP and SSH into it as root.

Note: If you don’t SSH in as root put “sudo” in front of all of the commands after step 7

  1. Go to
  2. Select ‘AMD64 (64-bit)’ as the architecture
  3. Select ‘USB Memstick Installer’ as the installer
  4. Select ‘VGA’ for the console
  5. Pick which ever mirror you want
  6. Right click the ‘Download’ button and choose ‘Copy Link Location’
  7. On your SSH connection to your droplet run the following command:
    cd /tmp
    curl -O <URL FROM STEP 6>
    # Example
    curl -O
  8. Disable SWAP
    swapoff -a
  9. Enable debug mode for GEOM, more info on why here
    sysctl kern.geom.debugflags=0x10
  10. Write the ISO of pfSense to /dev/vtbd0
    gunzip <PFSENSE DOWNLOAD> | dd of=/dev/vtbd0 bs=512k
    # Example:
    gunzip -c pfSense-CE-memstick-2.4.4-RELEASE-p1-amd64.img.gz | dd of=/dev/vtbd0 bs=512k


  11. You can now reboot the droplet and the the pfSense installer will start

Go back to the DigitalOcean interface, select your droplet and open the console window

  1. Once the installer starts hit <ENTER> to accept the copy right notice
  2. Choose ‘Install’
  3. Choose ‘>>> Continue with default keymap’
  4. Choose ‘Manual’
  5. Delete everything listed EXCEPT for vtbd0, vtbd0s2 and vtbd0s2a
  6. Highlight vtbd0 and press ‘C’ and choose ‘OK’
  7. Select vtbd0s1 and press ‘C’
  8. Change the mount point to “/” and choose ‘OK’
  9. Choose ‘Finish’
  10. Choose ‘Commit’
  11. The installation will now progress, once complete choose ‘No’ and ‘Reboot’

Once the droplet reboots you’ll be at the initial configuration wizard for setting up pfSense. Since this is deployment specific I will leave it to you to configure.

Palo Alto firewall displays “Session timed out” when you try to login

If you are getting this error message read this article first BEFORE you try to rebooting your firewall.

Screen Shot 2015-01-25 at 09.33.11

I ran into this problem recently with a Palo Alto PA-200 series firewall. I tried to login via the WebUI and would get the error “Session timed out”. I could SSH into the firewall and the internet was working. I’ve had this problem before and a quick reboot of my PA-200 solved the problem. Not so this time.

This time when I rebooted the firewall it did not come back up. Well not fully at least. I could PING and SSH it and load the WebUI (still getting the “Session timed out” error when trying to login) but all network traffic stopped flowing. This was bad.

I did some searching online and found that the issue can occur if you run low on disk space on your Palo Alto.

I logged into my PA-200 via SSH and ran the following:

[email protected]> show system disk-space 

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             1.9G  1.9G  0M   100% /
/dev/sda5             6.6G  1.3G  5.1G  20% /opt/pancfg
/dev/sda6             1.9G  752M  1.1G  42% /opt/panrepo
tmpfs                 1.3G   67M  1.2G   6% /dev/shm
/dev/sda8             2.4G  1.4G  874M  62% /opt/panlogs

You can see the problem. The root (/) volume of the PA-200 was out of disk space.

I reviewed the following Palo Alto KB’s:

Neither of them helped. They didn’t clear up any disk space on the root volume.

To fix the problem I had to call Palo Alto support. They generated a support key which allows them and only them access to the root file system on a Palo Alto device. Form there they cleared out a few logs in /var/log that were eating up all of the disk space. The main problem was /var/log/secure. If you’re familiar with Linux systems you’ll know that log gains entries for all successful and failed login attempts. In the Palo Alto’s case it was all of the successful and failed logins via SSH.

Once Palo Alto cleared out those logs files we gave our PA-200 another reboot and it came back up as per normal.

Then came the part where we wanted to prevent this from happening again. I knew for a fact we had never created a rule that allowed access to the PA-200’s SSH service and there was no way someone internally was hammering the PA-200 trying to break into it. Fortunately I had a really good support rep on the phone that knew exactly where to look. Management Profiles.

If you login to your Palo Alto via the WebUI and go to ‘Network’ and ‘Interfaces’ you’ll see a column labelled ‘Management Profile’. In our case we had a management profile assigned to our public interface that allowed for SSH. This is how the internet in general was accessing our PA-200’s SSH service. That’s not the best part though. The best part is traffic that is allowed via a Management Profile isn’t logged so you can’t even tell this is happening by looking at your traffic logs. Awesome right?

We changed our management profile to only allow ICMP (pings) and called it a day.

I’ve been told Palo Alto is aware this is an issue but it only really affects the PA-200 since it has the smallest hard drive. Palo Alto isn’t making it a priority to fix it by implementing something as simple as logrotate or even truncating the log after 50mb is written to it.

If you have this exact problem I really hope you have you have an active Palo Alto support contact. If you don’t you’re screwed. Palo Alto is the only one who can access the root file system.

I’m hoping they will eventually fix this problem in future PanOS releases.

LifeSize Express 220 dropping calls at 45 seconds on the dot

I recently deployed a LifeSize Express 220 in a school with a Satellite internet connection and a Cisco PIX 515 firewall running 8.0(4).28 and kept running into the strangest problem when making calls.

No matter if I was calling out or someone was calling in we’d be able to talk with video or audio only for exactly 45 seconds (per the call timer built into the LifeSize unit) and then the call would drop.

Initially I thought it had something to do with xlate, sip or h323 timeouts and the ‘inspect h323’ configuration that is set by default in the PIX firewall. Turns out it was a bit more then that.

Turns out the issue is a known one in how Cisco ASA/PIX firewalls running an OS older than 8.2.x inter-fear with LifeSize network traffic.


The solution as described in the video is:

  1. Go to https://<IP of your LifeSize>/support
  2. Login with the default credentials “cli” and “lifesize”
  3. Click ‘Enable’ next to the VSAT option
  4. Your LifeSize will now reboot

This will resolve the issue for you as long as the remote end of your call doesn’t have the same Cisco PIX/ASA with older firmware. If they do they will need to enable VSAT on their end or upgrade their firewall firmware.

I’m still going to leave the ‘no inspect h323’ configured on my PIX just in case.

If your curious how to change that default /support/ password I’ve read you can do it via SSH. I’ll eventually post how to do that since I’m curious myself.

Additional references: