pfSense in production with HA

If you work with or have an interest in IT networking and haven’t already heard of pfSense then you must go here and be amazed:

http://www.pfsense.org/

Basically (well, it is by no means your 'basic' BT home hub), pfSense is an Open Source routing platform, stateful firewall, IDS/IPS, Proxy, VPN gateway..... In fact... It can probably do everything!

I have been using pfSense on the office network and on the production network in the data centre for nearly a year so have got to play with it a fair bit.

Its basic set up simply asks you what interfaces you want to use for what (LAN, WAN, +more) and from there you can point your browser at the web GUI and start building your proper configuration.

The following is an example of one of my production HA configurations. I will walk you through it and try to give an overview of what's required to achieve this type of set up using pfSense 2.1.

You should be able to make sense of the diagram pretty easily. The data centre where this set up resides provides two WAN feeds into the rack. This is provided by their own Cisco HSRP set up and a pair of 6509's. (Big modular Cisco switches for those that don't know). Each of the colocated customers in this datacentre will have their own VLAN that pipes their routable subnet to their rack.

Those two feeds come into the WAN interfaces of my pfSense boxes and thats where the DC's network ends and mine begins.

Understanding High Availability

Our aim with this set up is to remove the single point of failure that is the LAN's default gateway. For sake of explanation... Take your home network for example, your router's IP address may be 192.168.0.1, this will most likely be the default gateway your PC is configured to use in order to communicate outside of the local subnet. Obviously... If a rouge piece of space junk comes crashing through your roof and lands on your router, no more default gateway for your PC's.

The same applies when you scale up to the enterprise IT world, hosted environments or building networks... If the default gateway dies, things stop talking beyond their local subnet.

"So to solve this problem, we need to add a second default gateway right?"

Hey presto! Yes, we need to double up on our default gateway, in this case pfSense. However, the basic fundamentals of networking & routing dictate that we can't give a host two different default gateways and obviously we can't give our second pfSense the same IP as the first.. That doesn't work! Doh...

Common Address Redundancy Protocol

Or 'CARP' as you may have heard it called is BSD's implementation of a gateway redundancy protocol. Read up here.

It works in very similar fashion to Cisco's HSRP or VRRP from the IETF. It uses virtual addressing and an Active/Passive cluster set up in order to present a single IP to the network. The passive cluster member can then assume the role of hosting this virtual address in the event that the master node fails.

The configuration of the master node is syncronised in real time to the cluster slave. Looking at my diagram again, this means if I felt like hitting pfSense A very hard with a 10lb sledgehammer, pfSense B instantly assumes ownership of the VIP (Virtual IP) that I am using as the LAN's default gateway address. The servers on the LAN are none the wiser, since they are still talking to the same default gateway address as before.

The same applies to incoming WAN traffic. Virtual 'CARP' IP's are also used on the WAN interface and therefore the second node takes ownership of them as well so everything continues as normal.

The above picture is one of two Dell Poweredge R610's that I use in a CARP configuration in a production environment. 1 interface is for the WAN, 1 is for a dedicated PFSYNC interface and the remaining two are configured as a bond for the LAN, the bond is split between two switches on the LAN side for further redundancy.

PFSYNC is used to synchronise the states and other aspects of the pfsenae master configuration to the slave. Obviously this is vital to the seamless failover between the master and slave. Inconsistent states or configuration will result in a disastrous failover. 

Support

Even though pfSense doesn't have the heavy weight support of big player like Cisco and Juniper etc... I find that it's community is excellent and as such have had no problems finding answers to my questions on their forums and the numerous guides and walkthroughs online.

But to be honest, if you can get even a basic grasp on what needs to happen in order to acheive high availability at the network perimeter then a simple guide such as the following as should point you in the right direction.

https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_(CARP)

Until next time....

Tom