From these fundamental principles, we can distil a set of best practices for implementing our firewall. Some of these practices are fairly obvious; some may not be quite so obvious:

• When you create your firewall rules, the principle of least privilege should apply. In many cases, firewall rules have been too permissive. You should try to avoid creating pass-through rules which have any in the destination field, or at least limit the range of ports to which these rules apply. pfSense blocks all network traffic by default, and you'll want to take advantage of that.
• You should periodically check your firewall rules and delete rules that are out of date. For example, in our example network, we had a printer on the MARKETING subnet that was to be shared and therefore a firewall rule would have to be created granting access to this printer. If the printer is subsequently decommissioned or moved to another subnet, then the rule granting access to the printer's IP address should be removed. In a corporate environment, finding out what rules should be removed may require network admins being proactive, as different departments may not make an effort to communicate this information. Still, it is an important practice, as deleting unnecessary firewall rules eliminates potential attack vectors.

• An important corollary to these two practices is that all firewall rule changes should be documented. Even if you remember why a rule change was made, others may not remember, especially if the rule change was made in response to an emergency. Documenting rule changes makes firewall management easier and can be helpful in a troubleshooting scenario.
• Firewall rules should be backed up on a regular basis. In a corporate environment, such backups should be maintained offsite. Such backups may prove to be of value if you ever have to recover from a firewall crash or some other catastrophe.
• You should create your rules in a manner that makes them consistent with your organizations written security policy, and when you are done creating them, you should review them to make sure they are consistent  with such policy.
• Eliminate redundant and unnecessary firewall rules, and try to keep your ruleset as simple as possible.
• Patch the firewall with the latest updates on a regular basis.
• You should limit the number of applications running on the firewall in order to maximize CPU cycles and increase network throughput. Any applications that can be run on a dedicated machine (for example, a proxy server) should be moved to another system, either behind or in front of the firewall.
• It's a good idea to perform regular security tests on your firewall; new exploits are being found and the firewall should be tested on a regular basis. This should include testing every interface on both sides of the firewall.
• If your organization is required to comply with the Payment Card Industry Data Security Standard (PCI DSS), you will want to review your policies to make sure you are in compliance with this standard. For example, PCI requirement 1.1.6 requires a complete firewall review every six months. PCI DSS is constantly being updated – as of this writing, the latest version is 3.2, released in April 2016 – so you need to review the latest version of the standard to see if there are any new requirements that affect firewall implementation.
• Enable logging, but only if you are going to actually look at the logs; otherwise, maintaining logs is a waste of both disk space and CPU usage.
• If you have remote users, you should require that they run a personal firewall and/or intrusion detection system on their computer.
• You may also consider running a remote syslog server for logging, to make it more difficult for potential hackers to modify the log files and thus cover their tracks.

Obviously, some of these suggestions may be overkill for a home or SOHO user, so you'll have to decide how many of these suggestions you implement, but avoiding overly permissive rules, deleting outdated rules, and documenting rule changes are definitely good practices that we will want to employ even on home networks. Implementation of the other suggestions will depend on your security needs and level of paranoia.