IP Filter FAQ

IV. COMMON PROBLEMS WITH IP FILTER (NON-OS SPECIFIC)

1. I have file transfer (FTP or HTTP) and if download speed is more then 100 KB/sec, connection breaks.
2. I have to keep clearing the state table or IPF dies, why?
3. The default ipfboot script flushes the state table. Is this necessary everytime you change some rule or just when that rule has a 'keep state' in it and there are existing state table entries that would be affected?
4. Sending mail is horribly slow!
5. I can't connect to IRC.
6. When I try to load the LKM (if_ipl.o), I get "fr_checkp" (or other) unresolved symbols. (FreBSD, OpenBSD, SunOS)
7. When I do a make, it complains about -I(TOP).
   
8. I'm using rdr for a webserver behind IPF and the world can see it just fine, but the internal machines can't surf to it via the external IP address.
   
9. Long ftp transfers and some other long single-connection sessions fail.
10. I've set up to use the ftp-proxy in my ipnat.conf file, and it works fine from NAT'ed machines, but I can't ftp from the firewall machine unless I put a rule in ipf.conf to pass port 20/tcp in from remote machines. How do I get the ftp proxy to work from the firewall machine too?

1. I have file transfer (FTP or HTTP) and if download speed is more then 100 KB/sec, connection breaks.

   Go add flags S to each one of your TCP rules that has keep state in it. What's happening is you're getting state entries for more than just the first packet of each connection and your state table is filling up... you only want to add a state table entry for those packets with a SYN flag.

2. I have to keep clearing the state table or IPF dies, why?

   See above.

3. The default ipfboot script flushes the state table. Is this necessary everytime you change some rule or just when that rule has a keep state in it and there are existing state table entries that would be affected?

   Yes, you can reload the rules without flushing the state table if you want. This is done in the boot script as a procaution because if you add a rule to block something, but there's an entry for that connection in the state table, it won't get blocked.

4. Sending mail is horribly slow!

   You're probable blocking stuff to your ident port, 113. Change that rule so that you send a TCP reset:
   block return-rst in quick on ppp0 proto tcp from any to any port = 113
Solaris users, see VII-1
   

5. I can't connect to IRC.

   See above.

6. When I try to load the LKM (if_ipl.o), I get "fr_checkp" (or other) unresolved symbols. (FreBSD, OpenBSD, SunOS)

   Make sure you have a kernel that has been correctly patched using the patches supplied with IP Filter, has "IPFILTER" in the config file and is the current kernel you are using.
   
   For FreeBSD/NetBSD, you will need to load if_ipl.o in an rc script (when securelevel is 0) or make sure that securelevel is -1 at runtime.
   

7. When I do a make, it complains about -I(TOP).
   

   You're using the GNU version of make. Use the standard version of make that comes with your operating system.

8. I'm using rdr for a webserver behind IPF and the world can see it just fine, but the internal machines can't surf to it via the external IP address.
   

   For the purposes of explaining this, lets take the following example:
   

   (internet)--->(if0[OS]if1)----|----(httpd on 192.168.0.2)
                                        |
                                        |----(browser on 192.168.0.3)
   

   if0 is some.isp.ip.addr
   if1 is 192.168.0.1
   
   I have a rdr on the external interface, written as:
   rdr if0 0.0.0.0/0 port 80 -> 192.168.0.2 port 80
   
   Now, IPFilter's rdr function does not natively support "bouncing" the connection (i.e. a packet coming in and leaving the same interface). The redirection happens only to packets coming in on the external interface. If you want to surf to 192.168.0.2 from the browser on 192.168.0.3, you can either do so directly via http://192.168.0.2/ (or by a CNAME in your DNS), or by using a "bounce" utility on the firewall to reflect inbound packets on if1 towards 192.168.0.2. By nature neither the OS nor ipf will do this for you. If you search the ipf archives you will find some bounce utilities. The golden RDR rule: rdr works *only* when the packet traverses the firewall (i.e. in one interface and out on another interface).

9. Long ftp transfers and some other long single-connection sessions fail.
   

   You probably have an ipf.conf rule that looks something like:
   block return-rst in on ext-interface proto tcp all
A rule like this will send an RST in response to an out-of-sequence ACK from the other end of a long ftp transfer, breaking the connection. Try replacing your rule with:
   block in on ext-interface proto tcp all
block return-rst in on ext-interface proto tcp all flags S
which will send RST only to SYN packets.

10. I've set up to use the ftp-proxy in my ipnat.conf file, and it works fine from NAT'ed machines, but I can't ftp from the firewall machine unless I put a rule in ipf.conf to pass port 20/tcp in from remote machines. How do I get the ftp proxy to work from the firewall machine too?

    Add a second ftp proxy rule to your ipnat.conf:
    map ext-interface firewall-ip/32 -> firewall-ip/32 proxy port ftp ftp/tcp