To demonstrate how the concepts introduced might be implemented in a real-world scenario, we will return to the example network introduced in the beginning of the chapter. Some very specific requirements were outlined:

• We need redundant firewalls, and this requires implementing CARP.
• Finally, we wanted to introduce some redundancy into our FTP server, and have at least two separate servers. This requires implementing server load balancing.

Assume that we have a LAN network for local traffic, and also assume that we have a separate DMZ network for the FTP server.

Assume we have a subnet of 192.168.1.0 for the LAN network, and a subnet of 192.168.2.0 for the DMZ network. The FTP server's IP address is 192.168.2.10.

There are various ways we could go about implementing the changes we want, but implementing a CARP group is more difficult than implementing either server load balancing, so a case can be made for implementing the CARP group last. Thus, we will implement the changes in the following order:

1. Server (FTP) load balancing
2. CARP setup

Our first step is to set up FTP server load balancing. As mentioned earlier, our DMZ has a subnet of 192.168.2.0 and the FTP server's IP is 192.168.2.10. We have decided that the redundant FTP server will be assigned an IP of 192.168.2.11, and additional redundant servers will be added as needed. We don't have to assign an IP address for the virtual server, as it will be the WAN IP address. Thus, our IP assignments look like this:

One issue we should consider before we move ahead with configuring load balancing is how we are going to synchronize the redundant FTP servers. We have two broad alternatives:

• Cluster the redundant FTP servers
• Run a utility on the FTP servers to ensure that the file systems remain synchronized

Note that if we cluster the FTP servers, the cluster will appear to other entities as a single server. There are many FTP servers that support clustering, and they have their own load balancing and high availability capabilities. In this case, pfSense can deal with the FTP cluster as if it was a single server, and we don't have to implement load balancing in pfSense.

If we choose not to cluster the server, however, then we have to find a means of synchronizing the servers. Fortunately, if we're using Unix or Linux, there is a widely-used utility called rsync that can be used; rsync has also been ported over to Windows, so if our FTP server is running on Windows, it's a potential solution, although there are many other file synchronization programs available for Windows. For the purposes of this exercise, we'll assume we decided not to create an FTP server cluster and thus we will use pfSense's load balancing capabilities.

To begin load balancing configuration, navigate to Services | Load Balancer. On the Pools tab, click on the Add button. We enter an appropriate name in the Name field (for example, FTPPOOL). The Mode field should be set to Load Balance. The Port value will be set to 21 (the default port for FTP). Then, under Add Item to the Pool, we begin entering FTP servers in the Server IP Address edit box, clicking on Add to pool after we enter each IP address to add it to the pool. Since there are only two servers, 192.168.2.10 and 192.168.2.11, this does not take long. After we have entered all the servers, we click on the Save button at the bottom of the page.

The next step is virtual server configuration. On the main Load Balancer page, we click on the Virtual Servers tab, and then click on the Add button. On the Virtual Servers configuration page, we type an appropriate name (for example, FTP), a brief description in the Description field, and we enter the WAN IP address in the IP Address field. We enter 21 in the Port field, and we specify FTPPOOL as the Virtual Server Pool (if FTPPOOL is the only pool, then it will be the default value and we don't have to change anything). Since we don't see any issue in using TCP as the Relay Protocol, we leave this unchanged and click on the Save button. Then, we click on Apply Changes on the main Load Balancer page.

We now need to create a firewall rule to allow traffic to pass through the WAN interface to the FTP server pool. First, we create an alias for the FTP servers, which should help if we add servers in the future. We navigate to Firewall | Aliases and click on the Add button. On the Aliases configuration page, we enter an appropriate name in the Name field (for example, FTPSERVERS). We leave the Type set to Host(s) and, under the Host(s) section, we enter the IP addresses for the FTP servers. Then we click on the Save button, and from the main Aliases page we click on Apply Changes.

To create the firewall rule, we navigate to Firewall | Rules. On the WAN tab, we click on one of the Add buttons. All of the default values in the first section can be kept as they are (unless we have an IPv6 network and want to change the Address Family to IPv6 or IPv4 + IPv6). We keep Source as any, but in Destination, we select Single host or alias in the Destination drop-down box and enter FTPSERVERS in the adjacent edit box. We enter a brief description in the Description field, and then click on the Save button and click on Apply Changes on the main Rules page.

This completes the pfSense portion of our FTP load balancing pool. We still need to implement synchronization so that the files (including user account data) are kept identical on both servers. It is beyond the scope of this discussion to cover this topic, but as mentioned earlier, rsync is one possible solution. By utilizing rsync, implementing synchronization can be done as easily as entering the following line in our crontab file:

1 0 * * * rsync –az 192.168.2.10::ftp/   /var/ftp/

If entered into the crontab file on 192.168.2.11, this will cause the cron scheduler to execute rsync at one minute past midnight every day, and copy the FTP tree on 192.168.2.10 to /var/ftp.

Even if we haven't yet implemented synchronization, we will want to verify that  the FTP server pool is functioning, so we navigate to Status | Load Balancer and check both the Pools and Virtual Servers tabs to verify that both servers are up  and running.

The final task is the setup of a CARP failover group, and this requires some consideration. Three interfaces will require CARP virtual IPs: the LAN and DMZ interfaces. We are going to have to add an interface for pfsync on each firewall. Assume also that we are going to make the CARP virtual IPs match the original interface IP assignments (192.168.1.1 for the LAN and 192.168.2.1 for the DMZ) to make the transition easier. pfsync will be on its own network. We can summarize the IP assignments for our failover group as follows:

As you can see, PFSYNC is the only interface on the failover group that doesn't get a virtual IP, as it is not accessible by the outside world, but is only there to allow the firewalls to exchange configuration data.

Since the virtual IPs for the LAN and DMZ are identical to the current IPs for those interfaces, we must change them before we create the virtual IPs, since pfSense will not allow us to create virtual IPs that match currently assigned IPs. Thus, we navigate to Interfaces | LAN, scroll down to the IPv4 Address edit box, and change this value to 192.168.1.2, clicking on the Save button when we are done. Then, repeat this process with the DMZ interface, only we change the IPv4 Address to 192.168.2.2.

Since we are going to have to add the PFSYNC interface anyway, we navigate to Interfaces | (assign), select one of the available interfaces in the Available network ports drop-down box, and click on the Add button. We select Static IPv4 as the IPv4 Configuration Type and set the IP address to 172.16.1.1. The Enable Interface checkbox also needs to be checked. Then, we click on the Save button and now that we are done configuring interfaces, we click on the Apply Changes button.

We begin configuration by navigating to Firewall | Virtual IPs and clicking on the Add button to add the first of our virtual IPs. We will set up the LAN IPs first, so for Type we select the CARP radio button, and then select LAN in the Interface drop-down box. We type in 192.168.1.1 in the Address(es) edit box and select 24 for the subnet mask. We type in a password in Virtual IP Password; the VHID Group should be 1 if we haven't added any CARP virtual IPs before. The Advertising Frequency should be set to 1 and 0 for the Base and Skew respectively. We enter a brief description in the Description field and click on the Save button.

We then repeat this process for the three remaining interfaces. The IPs entered in the Address(es) field for each interface must correspond to the virtual IP listed in the table (192.168.1.1 for LAN, and 192.168.2.1 for DMZ). The Virtual IP Password value can be different for each virtual IP, and the VHID Group must be unique for each one (it should automatically increment). On the primary firewall, the Advertising Frequency Base and Skew should always be 1 and 0.

Next, we navigate to System | High Availability Sync to configure pfsync and XML-RPC. We make sure the Synchronize states checkbox is checked, and select PFSYNC as the Synchronize Interface. For the pfsync Synchronize Peer IP, we enter the LAN IP of second firewall number, or 192.168.1.3. Under XML-RPC Sync, we enter this IP again, and in the Remote System Password fields, we enter the admin password. In the Select options to sync section, we check everything, and then click on Save.

Finally, we must alter the DHCP settings. Since the DMZ is primarily for resources that need to be accessible from the internet, such as the FTP server, and those resources tend to have static IP addresses, there's a good chance the DHCP server won't be activated on the DMZ; thus, we only have to be concerned with DHCP settings for the LAN. Thus, we navigate to Services | DHCP Server and click on the LAN tab. Under Servers, we set the first DNS server to the CARP LAN virtual IP. Under Other Options, we set Gateway to the LAN virtual IP as well. We set the Failover peer IP to the actual LAN IP address of the other firewall (192.168.1.3). Then, we click on the Save button at the bottom of the page.

Now, we have completed configuration on the primary firewall, but we must repeat the process on the secondary firewall. We need to create a PFSYNC interface and create the same virtual IPs on the secondary firewall. When we configure pfsync, we set the pfsync Synchronize Peer IP to the LAN IP of first firewall, or 192.168.1.2 (this IP should also be used in the first field under XMLRPC Sync). The NAT manual outbound rules should not have to be changed, because the primary server should overwrite the NAT settings later. The DHCP settings will have to be changed; the first DNS server and the gateway should be set to the LAN virtual IP, and the Failover peer IP should match the IP address of the primary firewall (192.168.1.2).

Once we complete configuration of the second firewall and connect it to the network (and to the first firewall), our CARP setup is complete, and all that remains is to verify the CARP group's functionality, using the steps outlined in section on CARP configuration. We navigate to Status | CARP and see CARP is up and running. There may be a button on one of the firewalls labeled Enable CARP. If so, we will need to click it to get CARP to run. If it is working, we likely still want to test it in some likely failure scenarios. If it is not working, then we need to do some troubleshooting; this is the topic of the next section.