IPFW vs PF (knowledge article)
tommyboy180 last edited by
FreeBSD platform is a great platform for firewalls. As far as i know, FreeBSD has 3 firewall apllication for building a great firewall : IPFW, PF and IPF. hmmmm, i only will explain the IPFW and PF firewall. IPF and PF is almost same.
* IPFW : FreeBSD’s primary firewall is called IPFW (Internet Protocol Firewall). IPFW is composed of two parts: a kernel-level packet filter engine and a userland utility for controlling firewall functionality. IPFW has been part of FreeBSD since FreeBSD 2.0. IPFW went through a major overhaul as part of FreeBSD 5 development. This “new” IPFW became known as IPFW2. However, for the sake of sanity, we will refer to IPFW2 simply as IPFW.
* PF : OpenBSD utilizes a firewall mechanism called PF (packet filter). Like FreeBSD’s IPFW, PF is made up of a kernel-level packet filter and a userland utility for control of the firewall functionality. Unlike FreeBSD, PF is exposed via a device node, /dev/pf. PF is a newcomer to the OpenBSD world. Before using PF, OpenBSD utilized a firewall called IPFilter. I dont know why IPFilter removed from OpenBSD. maybe a licensce trouble. The end result was that IPFilter was removed from OpenBSD. PF was created to fill the void left by IPFilter. PF has been designed from day one to integrate cleanly into OpenBSD, and as such, is very usable and flexible.
There are big differences between IPFW and PF. If you had ever using both IPFW and PF, you will find the differences. IPFW is list-based while PF is much more object oriented. PF configuration is broken into many parts, but IPFW generally a shell scripts with rules processed in order. but, both firewall supports statefull and stateless processing of connection.
In IPFW, the first rule in a ruleset that matches a packet “wins.” That means, if a ruleset has a rule to allow traffic to port 80 before a rule that denies all traffic, the packet destined to port 80 will be allowed. In PF, the exact opposite is true; the last rule that matches “wins.” In the same example, the packet to port 80 would be denied by the firewall. If you really need to have a packet match a rule and then be processed in PF, you can use the quick keyword to force the issue. (you can read my blog about PF)
In IPFW, denied packets are logged through the syslog facility. In PF, denied packets are logged to a special interface called pflog0. This interface is actually a BPF (Berkeley Packet Filter) interface that allows utilities like tcpdump to sniff logged packets directly. This feature can be used by IDS engines and monitoring tools to analyze the firewall’s activity without having to interact or affect the firewall processing.
PF implements Network Address Translation (NAT) and Quality of Service (QoS) directly into the firewall. In IPFW, these features are provided by other programs. In general, there is no functional difference. The integration in PF makes administration a bit easier as all configuration is done in one file.
PF performs more aggressive optimization than IPFW. In PF, large lists of rules are compressed into a table (of course you must read the PF manual first). So while the configuration file for PF may still have list-like properties, the core processing engine of PF treats the rules more efficient. This ultimately results in a tree data-structure for the rules making even huge rulesets rapidly searchable.
PF also has the capability to reassembly and normalizing fragmented packets before sending them through the firewall. This prevents fragmentation attacks behind the firewall. This is a great feature of PF, as it prevents other applications on the firewall (like an IDS sensor) from having to deal with fragments.
Seems that PF is a weapon weapon for building a firewall. If you need the flexibility and scalability, use PF. However, for smaller-scale deployments, such as a small or home office, IFPW’s simple interface and simple administration may be your choice.
Back to you again, just choose PF or IPFW as your firewall in a FreeBSD machine or in your networks.
cmb last edited by
ipf and pf aren't even remotely "almost the same" heh
pf and ipfw are likely the best two available, though ipf is good as well it's less capable in several ways.
We actually use pf and ipfw, though ipfw only with captive portal (for its abilities at layer 2). ipfw is just as scalable and mostly as flexible as pf, some unusual comments in that article.
original source of the post here: http://cipitunk.wordpress.com/2007/07/07/ipfw-vs-pf/
tommyboy180 last edited by
Yup. Thank you for citing original source.