Failover with CARP in PFsense: Part 1
Failover with CARP in PFsenseCommon Address Redundancy Protocol (CARP) is a protocol which allows multiple hosts on the same local network to share a set of IP addresses. Its primary purpose is to provide failover redundancy. It was developed as a non-patent-encumbered alternative to Virtual Router Redundancy Protocol (VRRP), which is defined in RFC 2281 and 3768 and was quite far along towards becoming an IETF-sanctioned standard.
It is also an alternative to the Hot Standby Router Protocol (HSRP). It manages failover at the intersection of the link layer and IP layer of the OSI model. Each CARP group has a virtual MAC address, and the CARP advertisements are sent out with this as the source address, which helps switches determine which port the virtual MAC address is currently at.
One of the main purposes of CARP is to ensure that the network will keep functioning even when a firewall goes down because of errors or planned maintenance activities such as upgrades (failover). CARP works by allowing a group of hosts on the same network segment to share an IP address. This group of hosts is referred to as a “redundancy group”. The redundancy group is assigned an IP address that is shared among the group members. Within the group, one host is designated as the master and the other as backups. The master host is the one that currently holds the shared IP; it responds to any traffic or ARP requests directed at it. If the master goes down, one of the backups will inherit the IP address. The handover from one CARP host to another may be authenticated, essentially by setting a shared secret, much like a password. The master then sends out CARP advertisement messages via multicast using the CARP protocol (IP Protocol 112) on a regular basis, and the backup hosts listen for this advertisement. If the advertisements stop, the backup hosts will begin advertising. The advertisement frequency is configurable, and the host which advertises the most frequently is the one most likely to become master in the event of a failure.
CARP is rather similar to VRRP, with a few significant differences:
The CARP protocol is address family independent, with the OpenBSD implementation supporting both IPv4 and IPv6.
CARP has an “arpbalance” feature that allows multiple hosts to share a single IP address simultaneously (in this configuration, there is a virtual MAC address for each host, but only one IP address).
CARP uses a cryptographically strong SHA-1 keyed-hash message authentication code (HMAC) to protect each advertisement.
Some synchronization is required, an at least in the case of PF firewalls, pfsync can handle it. If it is done properly, active connections will be handed over without noticeable interruption. The purpose of pfsync in this context is to act as a virtual network interface specially designed to synchronize state information between PF firewalls. In order to ensure that pfsync meets the packet volume and latency requirements, the initial implementation has no built-in authentication. An attacker who has local link layer access to the subnet used for pfsync traffic can add, change, or remove states from the firewalls. Therefore, it is strongly recommended that a dedicated, trusted network be used for pfsync. This can be as simple as a crossover cable between interfaces on two firewalls.
Failover with CARP: Configuration
Here is a simple example CARP configuration:
sysctl -w net.inet.card.allow=1
ifconfig carp1 create
ifconfig carp1 vhid 1 pass password carpdev em0 \
advskew 100 10.0.0.1 netmask 255.255.255.0
This does the following:
Enales receipt of CARP packets (the default setting)
Creates a carp(4) interface (carp1)
Configures carp1 for virtual host #1, enables a password, sets em0 as the interface belonging to the group, and makes the host a backup die to the advskew of 100 (assuming the master has an advskew less than 100). The shared IP assigned to this group is 10.0.0.1/255.255.255.0.
Failover with CARP in PFsense: Part 2
Failover with CARP in PFsense
In the previous article, I briefly discussed the advantages of using CARP with PF, as well as the difference between CARP and other protocols commonly used for redundancy. In this article, I will outline a hypothetical CARP implementation involving two redundant firewalls.
Keep in mind CARP addresses are virtual addresses. Unless you always have console access to all machines in your CARP group, you will almost always want to assign an IP address to the physical interfaces in order to be able to communicate with the host and be absolutely sure with which machine you are interacting. The convention is for the IP addresses assigned to the physical interface to belong to the same subnet as the virtual, shared IP address. In fact, the kernel will by default try to assign the CARP address to a physical interface that is already configured with an address in the same subnet as the CARP address. You can override this by specifying a different interface in the carpdev option in the ifconfig command string you use to set up the CARP interface.
A Hypothetical Two-Firewall CARP Setup
In this example, fw0 and fw1 will be the two firewalls. fw0 will be the master and will be used exclusively as long as it is up and running properly. fw1 is to be used only if fw0 goes down. They update and exchange state information over the CARP interface, if2. Both firewalls have a physical external WAN interface (if0), an internal LAN interface (if1), and two virtual interfaces for CARP: cp0, bound to if0, and cp1, bound to if1. Here is a brief overview of the network interfaces:
if0 is the external internet interface, and will only be sending CARPv2 broadcast packets to the other CARP firewalls. It will not be accepting any connections for any services.
if1 is the internal LAN interface. This will be used to broadcast CARPv2 packets to the other firewalls on the internal LAN.
if2 is the CARP synchronization interface. It is used to transfer the state information between the master (fw0) firewall to the backup (fw1) firewall. The link between the two interfaces can be a crossover cable or a secured switch. If you only have two firewalls and they are close to each other, a crossover cable is a good idea. As I noted in the previous article, keeping the CARP sync traffic on its own network is a good idea so no one can snoop on it.
cp0 is the external virtual CARP interface which will be bound to the physical network interface if0. It will be the public IP that will be moved from the master to the backup when the firewalls fail over. The cp0 IP in this example will be 50.87.147.42. This is the IP that will be answering any public services the network hosts.
cp1 is the internal CARP interface which will be bound to the physical network interface if1. It will be the internal IP that is moved from the master to the backup when the firewalls fail over. The cp1 IP address in this example will be 192.168.10.1.
In the previous article, I briefly discussed the advantages of using CARP with PF, as well as the difference between CARP and other protocols commonly used for redundancy. In this article, I will outline a hypothetical CARP implementation involving two redundant firewalls.
Keep in mind CARP addresses are virtual addresses. Unless you always have console access to all machines in your CARP group, you will almost always want to assign an IP address to the physical interfaces in order to be able to communicate with the host and be absolutely sure with which machine you are interacting. The convention is for the IP addresses assigned to the physical interface to belong to the same subnet as the virtual, shared IP address. In fact, the kernel will by default try to assign the CARP address to a physical interface that is already configured with an address in the same subnet as the CARP address. You can override this by specifying a different interface in the carpdev option in the ifconfig command string you use to set up the CARP interface.
A Hypothetical Two-Firewall CARP Setup
In this example, fw0 and fw1 will be the two firewalls. fw0 will be the master and will be used exclusively as long as it is up and running properly. fw1 is to be used only if fw0 goes down. They update and exchange state information over the CARP interface, if2. Both firewalls have a physical external WAN interface (if0), an internal LAN interface (if1), and two virtual interfaces for CARP: cp0, bound to if0, and cp1, bound to if1. Here is a brief overview of the network interfaces:
if0 is the external internet interface, and will only be sending CARPv2 broadcast packets to the other CARP firewalls. It will not be accepting any connections for any services.
if1 is the internal LAN interface. This will be used to broadcast CARPv2 packets to the other firewalls on the internal LAN.
if2 is the CARP synchronization interface. It is used to transfer the state information between the master (fw0) firewall to the backup (fw1) firewall. The link between the two interfaces can be a crossover cable or a secured switch. If you only have two firewalls and they are close to each other, a crossover cable is a good idea. As I noted in the previous article, keeping the CARP sync traffic on its own network is a good idea so no one can snoop on it.
cp0 is the external virtual CARP interface which will be bound to the physical network interface if0. It will be the public IP that will be moved from the master to the backup when the firewalls fail over. The cp0 IP in this example will be 50.87.147.42. This is the IP that will be answering any public services the network hosts.
cp1 is the internal CARP interface which will be bound to the physical network interface if1. It will be the internal IP that is moved from the master to the backup when the firewalls fail over. The cp1 IP address in this example will be 192.168.10.1.
0 comments:
Post a Comment