nat master
authorbycn82 <bycn82@web>
Sun, 23 Nov 2014 03:06:16 +0000 (03:06 +0000)
committerCharlie Root <root@leaf.dragonflybsd.org>
Sun, 23 Nov 2014 03:06:16 +0000 (03:06 +0000)
docs/ipfw2/index.mdwn

index e45d525..4244a9a 100644 (file)
@@ -11,34 +11,34 @@ bycn82
 [[!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 which supports Layer2 to Layer4. It is comprised of several components: 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.
+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 which supports Layer2 to Layer4. It is comprised of several components: 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.
 
-I am re-writing it from scratch for DragonflyBSD and call it IPFW2. This IPFW2 will be in modular design, all the functionality are originally from loadable modules and should be not that difficult for normal users/developer to create a module in order to meet their own requirements.
+I am re-writing it from scratch for DragonflyBSD and call it ipfw2('ipfw too'). This ipfw will be designed in modular, all the functionalities are originally from loadable modules and should be not that difficult for normal users/developers to create a module in order to meet their own requirements.
 ## Brief notes on design
-Before users start to use the IPFW2 utility to add rules, the IPFW2 kernel should be enable/loaded into the kernel. by running below command
+Before user starts to use the ipfw utility to add rules, the ipfw kernel module should be loaded into the kernel by running below command.
 
         kldload ipfw
 
-the fundamental framework is loaded now, it can support the default rules only. continue run below command
+the fundamental framework is loaded now, it can support the default rules only. And continue run below command
 
         kldload ipfw_basic
 
-the basic IPFW2 module is loaded into kernel now,together with all the basic functionality. in order to user more function which is implemented in other modules, users can run below command
+the basic module together with all the basic functionalities have been loaded. If user wants more functions which implemented in other modules, for example, the 'layer2' module in order to filer the layer2 traffic, so user should run below 
 
         kldload ipfw_layer2
 
-so the 'layer2' module will be loaded, for example in this scenario, user can start to fire below command 
+and the 'layer2' module is loaded now, for example in this scenario, user can start to fire below command 
 
         ipfw add allow all from any to any layer2
 
-it means user want to add add rule which allow all the layer2 traffic. when user fire the command in the console, actually in the back-end, it will do below things.
+it means user want to add add rule which allow all the layer2 traffic. when user fire the command in the console, actually in the back-end, below steps will be done.
 
-1. ipfw retrieve the module name list from the kernel
+1. ipfw retrieve the module list from the kernel
 2. ipfw load the module accordingly
 3. ipfw start to parse the parameters 
 4. inject into the kernel
 
-In the kernel space, when the traffic comes, it will filter again the rule, in each ipfw_insn has unique module + opcode. it will automatically link to the filter function which will be registered during the module was loaded.
+In the kernel space, when the traffic comes, it will filter again the rules, in each ipfw_insn has unique module + opcode. it will automatically link to the filter function which will be registered during the module was loaded.
 
 ## Compare with FreeBSD's ipfw
 Comparing to the IPFW from FreeBSD,this IPFW for DragonflyBSD is:
@@ -47,11 +47,11 @@ Comparing to the IPFW from FreeBSD,this IPFW for DragonflyBSD is:
 
 Every feature/function needs to be identified by an ID, but there are only 8bits space to store the ID, so theoretically it can support 256 features/functions in maximum.
 
-In this IPFW for DragonflyBSD, the space for ID are the same, so also 8bits, but one space for each module and it has 8bits for module ID, so so theoretically it can have 256 modules and 256 features/functions in each module, so 256*256 feature/functions in maximum.
+In this ipfw for DragonflyBSD, the space for ID are the same, so also 8bits, but one space for each module and it has 8bits for module ID, so so theoretically it can have 256 modules and 256 features/functions in each module, so 256*256 feature/functions in maximum.
 
 ### Much more concise
 
-In this IPFW for DragonflyBSD, the rules 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 readable. but actually "ipfw add allow ip" is much more concise. and another example "ipfw add allow ip from 1.1.1.1 to any" cannot be better than "ipfw add allow from 1.1.1.1". because "from any " and "to any" are actually useless.
+In this ipfw for DragonflyBSD, the rules 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 readable. but actually "ipfw add allow ip" is much more concise. and another example "ipfw add allow ip from 1.1.1.1 to any" cannot be better than "ipfw add allow from 1.1.1.1". because "from any " and "to any" are actually useless.
 
     #1. ipfw add allow all 
     #2. ipfw add allow icmp from 1.1.1.1
@@ -59,19 +59,18 @@ In this IPFW for DragonflyBSD, the rules are much more concise. for example, the
 
 ### Much more flexible
 
-It supports concise mode and full mode which is same as IPFW in FreeBSD in user angle of view.
+It supports concise mode and full feature mode which is same as ipfw in FreeBSD in user angle of view.
 
 
-# Configuration
 # Modules
 Some modules are exists in the FreeBSD's ipfw,e.g. the dummynet and in-kernel NAT. they are "action modules" providing the functionalities which will be applied to the traffic whom successfully passed all the filters.
 
-Some modules are "filter modules" which is new in this ipfw. And every "filter module" comes with a kernel part and user-space part. the kernel part need to be loaded manually, and the user-space part will be loaded automatically when user fires the ipfw command if it is needed to be loaded.
+Some modules are "filter modules" which is new in this ipfw. And every "filter module" comes 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 ipfw command if it is needed to be loaded.
 
 ## Filter Modules
 When the ipfw was loaded, it comes with 2 opcodes in order to support the default behavior of the ipfw. so below 2 opcodes are embeded in the ipfw.ko
       accept
-      deby
+      deny
 by firing command `kldload ipfw', the default ipfw will be loaded. and all other modules are relying on this module.
 ### Basic Module
 By firing command `kldload ipfw_basic', the basic module will be loaded. and this module brings all the basic functionalities lists below.
@@ -106,6 +105,7 @@ This modules is focusing on the connections. for example to limit X packets per
 ## Action Modules
 ### Dummynet
 ### NAT
+Libalias is the library used to do masquerading and IP address translation (NAT).
 ### LOG
 
 # Development