IP Filter FAQ

III. COMMON QUESTIONS ABOUT IP FILTER

1. What does keep state actually do? Is it useful?
2. What is with this last match stuff?
3. What is "in" and what is "out"?
   
4. Does IP Filter actually work on BSD/OS? What do I need to make it work?
5. I'm using PPPoE (or some other virtual interface/tunnel), how should I write my rulesets?
6. So, if 'map a.b.c.d/M -> w.x.y.z/32' does NAT for all protocols, why do I need a 'map a.b.c.d/M -> w.x.y.z/32 portmap'
7. Well, after reading the answer to III-6, do I have to have the first rule if I have the second rule?
8. How do I upgrade IPF?
9. I have a dynamic IP address, how can I do NAT?
10. What's the difference between MAP and RDR?
11. When does NAT happen in relation to filtering?
12. Are there any GUI's or other aids?
13. Are there any log analyzers?
14. How do you clear accounting stats?

1. What does keep state actually do? Is it useful?

   From Darren:
   First, yes, it is useful. What it does is allows you to only allow TCP packets through your firewall which are recognised as being part of an established connection rather than just arbitary TCP packets which can be used to perform "stealth scanning". In terms of rules, the following:
   pass in proto tcp all
block out proto tcp all
block in quick proto tcp all flags S
pass in quick from any to any port = smtp flags S
pass out proto tcp from any port = smtp to any

   can be replaced by:
   block in proto tcp all
block out proto tcp all
pass in quick proto tcp from any to any port = smtp flags S keep state

   keep state automatically matches packets going in the reverse direction (usually out) or on other interfaces without needing explicit rules.
   
   For UDP, it will automatically allow packets in which are the "reverse" of packets that have already been allowed through, without needing to allow too many packets through. For example, the following could be used for DNS clients:
   block out proto udp all
block in proto udp all
pass out proto udp from any port > 1024 to any port = 53
pass in proto udp from any port = 53 to any port > 1024

   which allows through a LOT of unwanted packets. This can be effectively replaced with the following:
   block out proto udp all
block in proto udp all
pass in proto udp from any to any port = 53 keep state


2. What is with this last match stuff?

   Some firewalls use last match theory, while others use first match. Neither is better, it's purely taste. By default, IP Filter is last match, and you can change that if you want to. So what does that mean. Let say you have the following rules:
   pass all
block in proto tcp from any to any port = 25
block all

   What you have here is essentially a 'block all' firewall: the first two rules don't do anything. When a packet comes in, lets say from 1.2.3.4 port 2000, to 2.3.4.5 port 79, the filter is going to do this: Does this packet match 'pass all'? Yes, it does, let's keep that in mind. Does this packet match 'block in proto tcp from any to any port = 25'? No. Does this packet match 'block all'? Yes it does, so I can forget whatever else it's matched so far and keep this one in mind. Oh, that's the last rule, let's go with that one. So, even if the first rule specifically allowed all port 79 (finger) traffic in, it still wouldn't actually get in. Let look at one more example:
   block in all
pass in from 1.2.3.4 to any
block in proto tcp from 1.2.3.4 to any port = 25

   Now, let's say a packet comes in from 1.2.3.4 headed to our SMTP port (25), what happens? It get's blocked, because rule 3 is the last rule to match that packet.
   
   Now, if you want to CHANGE this behavior, you simply add the quick to your rules, so:
   pass in quick from 1.2.3.4 to any
block in quick proto tcp from 1.2.3.4 to any port = 25
block in quick all

   Now notice I moved the 1st rule and made it the last rule. If I didn't, nothing would get through because of thequickkeywork. You can mix and matchquickand non-quick rules (although in general it's not advised), but basically what IPF does is when it hits a rule that matches the packet, if thequickkeyword is there, it takes that action without looking any further.

3. What is "in" and what is "out"?
   

   In and out are from the perspective of the actual interface. In means arriving on the interface from the external world, eading into the box for kernel processing. Oout means exiting the interface headed into the external world, having already been processed by the kernel.
   
   Let's look at a packet traversing your firewall from the inside out...
   
   This packet, call it a port 80 SYN from your browser, goes:
   (Your workstation)-->(int_if)[OS_kernel](ext_if)-->(internet)
   IN on int_if
   and thru the kernel, then
   OUT on ext_if
   
   The SYN+ACK reply from a 'net webserver on port 80 goes (internet)-->(ext_if)[OS_kernel](int_if)-->(Your workstation)
   IN on ext_if
   and thru the kernel, then
   OUT on int_if

4. Does IP Filter actually work on BSD/OS? What do I need to make it work?

   Yes, it does, BUT, you may need a source license for BSD/OS. Object modules are provided for use with BSD/OS 3.1.

5. I'm using PPPoE (or some other virtual interface/tunnel), how should I write my rulesets?

   Any rule that needs to refer to the outside interface should refer to the VIRTUAL interface and NOT the physical interface. For example, if you're physical interface is elxl0 and you're PPPoE interface is ppp0, then all you will see on elxl0 is PPP Frames which IP Filter can't understand anyway. Those frames will get unwrapped and 'come in' on ppp0 as IP packets which IP Filter can then read and filter.

6. So, if map a.b.c.d/M -> w.x.y.z/32 does NAT for all protocols, why do I need a map a.b.c.d/M -> w.x.y.z/32 portmap

   Well, the first one will do NAT for you. However it will ONLY try the source port requested, so if two machines on your network request a connection to the same place with the same source address, one of them will fail. However, if you have the portmap statement first, then if the source port is in use, it will try another source port in that range (you can specify a range instead of auto).

7. Well, after reading the answer to III-6, do I have to have the first rule if I have the second rule?

   In general, yes, but it depends. The portmap rule will only work for TCP and UDP. They will not work for any other protocol such as ICMP, ESP, etc. The other rule matches all other protocols, so generally you want both.

8. How do I upgrade IPF?

   See the section for your specific OS.

9. I have a dynamic IP address, how can I do NAT?

   You'll need to make your map rules look like this: map ppp0 10.0.0.0/8 -> 0/32

   The 0/32 tells IPNAT to use the current IP address for the ppp0 interface as the address to map to. Next, "ipf -y" must be run each time the interface is brought up with a new IP address to synchronise the address if currently being used. Check your ppp dialer for instructions on how to run something each time a new connection is made (DHCPd has something similar for DHCP connections, incase you are not using dialup).

10. What's the difference between MAP and RDR?

    Map rewrites source addresses and source ports of packets leaving an interface, while rdr rewrites destination addresses and destination ports of packets entering an interface.
    
    Map is generally used for NAT'ing (masquerading) clients behind the machine running IPF, thus you can have many clients accessing the internet via a single IP address. Rdr is generally used to allow internet hosts to access servers behind the machine running IPF. As an example, apache could be running on a server logically "behind" the IPF machine, and http requests to the external ip address of the ipf machine can be redirected to that apache server.

11. When does NAT happen in relation to filtering?

    Incoming packets enter the interface, get NAT'd, get filtered, then (if they get through the filter) get passed onto the kernel for processing. Additionally outgoing packets get filtered then NAT'd:
    
    interface --> NAT --> filter --> OS --> filter --> NAT --> interface
    
    This is important to keep in mind when writing your ruleset because your rules need to use the translated address.
    

12. Are there any GUI's or other aids?

    First let me say that you should really learn to write regular rulesets for IP Filter. They are made to be nearly plain english. Being able to write the rules yourself will also give you a better understanding for what is going on. That said...
    
    Filter Language Compiler - A tool written by Darren (the auther of IPF) that generates rules for the various packages which perform packet filtering from a common language.
    ISBA - GUI for managing IPF
    

13. Are there any log analyzers?

    Yes. Two I know of, probably more. There's a perl script called plog that comes with the IP Filter source code under the perl directory. Also available is fwanalog.

14. How do you clear accounting stats?

    ipf -z -f your_rule_file