[[!meta title="Ipfw3 Documentation"]] [[!meta robots="index, follow"]] bycn82 2 Mar. 2015 --- [[!toc levels=3]] # Introduction Ipfw is a controlling utility for ipfw/ipacct facilities for FreeBSD 2.0 which released in November, 1994. After 20 years of evolution. it becomes a stateful firewall. It is comprised of several components, e.g. the kernel firewall filter rule processor and its integrated packet accounting facility, the logging facility, NAT, the dummynet(4) traffic shaper, a forward facility, a bridge facility, and an ipstealth facility. It is one of the most advanced opensource firewall. DragonflyBSD is a logical continuation of the FreeBSD 4.x series, DragonFly's development has diverged significantly from FreeBSD's, e.g. a new Light Weight Kernel Threads implementation (LWKT), a lightweight ports/messaging system, In DragonFly, each CPU has its own thread scheduler. Upon creation, threads are assigned to processors and are never preemptively switched from one processor to another; they are only migrated by the passing of an inter-processor interrupt (IPI) message between the CPUs involved. Inter-processor thread scheduling is also accomplished by sending asynchronous IPI messages. One advantage to this clean compartmentalization of the threading subsystem is that the processors' on-board caches in Symmetric Multiprocessor Systems do not contain duplicated data, allowing for higher performance by giving each processor in the system the ability to use its own cache to store different things to work on. The LWKT subsystem is being employed to partition work among multiple kernel threads (for example in the networking code there is one thread per protocol per processor), reducing competition by removing the need to share certain resources among various kernel tasks. The ipfw was rewritten from scratch for DragonflyBSD and named 'ipfw3', it is in modular design, and inherited the "SMP-Friendly" feature of DragonflyBSD's LWKT, it is a lockless and stateful firewall. ## Brief notes on design Ipfw3 was in modular design. all the functionalities are implemented in different loadable modules, it can be loaded when it is required. the core framework of the ipfw3 only comes with default'accept' or 'deny' actions. by triggering below command, the core module will be loaded. kldload ipfw3 the fundamental core framework is loaded now. More basic firewall filtering features like 'filtering based on source IP' are implemented in basic module, so basic module need to be loaded before we start to the features. and below is the command to load the basic module, the basic module is relying on the core framework, so the core framework will be loaded automatically if it is not loaded yet, kldload ipfw3_basic The basic module is loaded now. then the user can start to use the filters which was implemented in the basic module. besides the basic module, there are layer2 module, layer4 module, in-kernel NAT module, dummynet module. Each module contains 2 parts. library in user-space which will be loaded and parse the command line into rules. and kernel space portion will be invoked when the traffic hit the firewall and it will trigger the correct action according to the firewall rules. ## Compare with FreeBSD's IPFW Ipfw3 inherited all feature from FreeBSD's ipfw, and lots of new features are introduced from PF or other rivals. **Much more extensible** Every filter/action needs to be identified using ID, but there are only 8 bits space to store the ID, so theoretically it can support 256 filters/actions in maximum in FreeBSD' ipfw. While in ipfw3, the space for ID are still the same, but one space introduced to keep the module's ID, so theoretically ipfw3 can have 256 modules and 256 filter/action in each module. And in ipfw3, both user-space library and kernel space module are implemented with a simple interface, it is quite easy to build your own filter/module by following the interface. **Much more concise** the rules of ipfw3 are much more concise. for example, the simple rule command like ipfw add allow ip from any to any the "from any to any" actually is just try to make the rule more human-readable. In ipfw3 we support the syntax of FreeBSD's ipfw, but we recommend to use simplified version as below: #1. ipfw3 add allow all #2. ipfw3 add allow icmp from 1.1.1.1 #3. ipfw3 add allow tcp via em0 **Higher Performance** All modern CPUs are having mutil-cores, and each core are running independently. So the LWKT of DragonflyBSD is the best way to fully utilize the CPU power. by duplicating the environment for each CPU, all the CPU can run as fast as it can without any interference. So it is a lockless and stateful firewall. # Modules This IPFW3 is modular, there are two type of modules. "Action Modules" are exists in the FreeBSD's IPFW,e.g. the dummynet and in-kernel NAT. they are providing the functionalities which will be applied to the traffic whom successfully passed all the filters. "Filter modules" are come with a kernel part and user-space part. the kernel part contains all the "check-function" and it requires to be loaded manually, while the user-space part contains all the "parse-and-show functions" and it will be loaded automatically when user fires the ipfw3 command if it is needed to be loaded. So the core IPFW3 module is just a framework, all the feature and functionalities are bring by the modules. more detail and examples of the modules can be found [here](/docs/ipfw2/modules). # Development This section will explain this IPFW3 in developer's angle or views ##PFIL framework The PFIL framework was designed to tidy the kernel, all the packet filters can register it's filter function into the PFIL hook, and the functions in the hook will be triggered when the traffic reach different positions in the IP stack. ##Tunnel between userspace and kernel in BSD,socketopt is the tunnel between userspace and kernel, so in IPFW3, all the operation are warpped in `IP_FW_X`in order to isolated the changes in IPFW3 modules only. ##Performance IPFW3 is a `lock-free` stateful firewall, so everything should have a copy `per-cpu`. By fully use of multiple CPU at the same time,it can have a better performance. # Roadmap Submit log history can be found via https://github.com/bycn82