keep state actually do? Is it useful?
quick affect head rules?
head statements for a group?
make, it complains about -I(TOP).log body in my rules but the body of the packet isn't getting logged.
interface/32, 0/0 or 0/32, and it doesn't work!
/usr/ucb/cc./usr/include/ia32/sys/reg.h:300: error: parse error before "upad128_t" when I compile IPF, why?
Darren Reed is the author of IP Filter. There have been many others who have helped him along the way. See the HISTORY file in the IP Filter source code for details.
http://coombs.anu.edu.au/ipfilter/ (or http://coombs.anu.edu.au/ipfilter/)
or see mirrors at:
http://coombs.anu.edu.au/ipfilter/#Mirrors
http://www.obfuscation.org/ipf/ is the official tutorial. Someone named Guido Van Rooij also wrote some documentation.
It comes as part of FreeBSD 2.2+, NetBSD 1.2+, Solaris 10+, and Open Solaris.
It has also been tested on Solaris SPARC/x86 2.3 - 9, SunOS 4.1.1 - 4.1.4, NetBSD 1.0 - 1.4, FreeBSD 2.0.0 - 2.2.8, BSD/OS-1.1 - 4, IRIX 6.2, OpenBSD 2.0 - 2.9, HP-UX 11.00 (IPFilter 4.x), and QNX Port*. Check the website for more information on the starred items.
Yes, it is allowed, so long as the IPFilter code is not placed under the GPL or any similar licence.
The IPFilter licence requires you to acknowledge that your product is based upon IPFilter. This is the same whether or not it is free, for sale, open source or closed source. In short this means somewhere in the documentation about your product (i.e Credits, etc), it needs to have an attribution to IPFilter and its author.
If you do not wish to include this, or have more specific questions or wish to licence IPFilter under different terms than the public licence, please feel free to email Darren Reed at darrenr@pobox.com.
NOTE: The above is directly from Darren.
See I-5
See I-5
Take a look at the Development Status Page for information on current releases. This contains what works and doesn't work with a specific release. The goal is generally to have all boxes be "OK" or "PASS" when a release is finalized.
Additionally you can find all patches to the current release here.
There is a single mailing list intended for support, general discussion, and anything else related to IPF. You can join by sending mail to majordomo@coombs.anu.edu.au and putting subscribe ipfilter in the body. But PLEASE read the rest of this FAQ before posting.
1) READ THE TUTORIAL (I-3)
2) Search the ARCHIVES (II-5)
3) READ II-3 and II-4
4) Read this entire FAQ!!
5) Optionally (but recommended), read all the man pages: ipf.4 ipf.5 ipf.8 ipfilter.5 ipfs.8 ipfstat.8 ipftest.1 ipl.4 ipmon.8 ipnat.1 ipnat.4 ipnat.5
State your problem very clearly.
Give all error messages.
Give all information
Include as much information as possible. Start with:
# uname -aAlways reply to the list, and remove the original sender, no one wants to get email twice
# isainfo -vk
# ifconfig -a
# netstat -rn
# netstat -i
# netstat -s -P ip
# ipf -V
# ipfstat
# ipfstat -io
# ipnat -slv
Never email anyone on the list directly unless they ask you to. If someone responds to your email on the list, you should reply TO THE LIST. This is for courtesy as well as the purpose of having your problem and solution show up in the archives for other people.
Never send HTML email to the list.
I'm glad you asked! There sure are at http://marc.theaimsgroup.com/?l=ipfilter&r=1&w=2.
Please take advantage of these and search them for your topic BEFORE posting to the mailing list.
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 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
Keep state will also allow ICMP packets related to a TCP or UDP session through. So if you get ICMP type 3 code 4 in response to some websurfing allowed out by a keep state rule, they will be automatically allowed in. Any packet that IPF can be certain is part of a connection, even if it's a different protocol, will be let in.
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 thequickto 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-quickrules (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.
In and out are from the perspective of the actual interface. In means arriving on the interface from the external world, leading into the box for kernel processing. Out 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
Yes, it does, BUT, you may need a source license for BSD/OS. Object modules are provided for use with BSD/OS 3.1.
Any rule that needs to refer to the outside interface should refer to the VIRTUAL interface and NOT the physical interface. For example, if your physical interface is elxl0 and your 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.
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).
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.
See the section for your specific OS.
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).
In short:
Rdr rewrites destination addresses and ports of packets entering an interface.
Map rewrites source addresses and ports of packets leaving an interface.
Bimap does both.
In long:
First and foremost: You probably do not need bimap. Try rdr first.
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 behind the IPF machine, and http requests to the external ip address of the ipf machine can be redirected to that apache server.
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.
Bimap is generall used when you're NAT'ing all outbound traffic to some address range (could be one address), and you have an server that needs to be accessed via a another address, and ALSO has to be able to make outgoing connections (like a passive FTP server) using that same address. Warning: Using bimap when it's not really needed can get you in a lot of trouble. If your NAT'ing outbound connections to the same address as your server gets contacted on, you do not need bimap. Always try rdr first!
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 (i.e. internal host) address. In other words, if your public address is Z and internal host A is talking to external host B, then the traffic from B will have a destination address of A, NOT Z because the destination NAT has already happened. For more information, see IP Filter Flow and this thread.
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.
Firewall Builder - a GUI for making rulesets for multiple firewall packages.
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.
ipf -z -f your_rule_file
If you want to use DNS in the LAN, you need a separate DNS server for the LAN addresses. This server should not be visible outside the LAN. It's possible to run the DNS on the firewall itself, but you need to be very careful with the configuration of both the DNS server itself (e.g. BIND) and ipfilter in order to prevent a hole big enough to drive through. A few things to remember. Do not allow zone transfers across the firewall; instead, set up the DNS server as a master for your internal hosts (e.g. 192.168.x.x) and as a forwarder (and forward only mode) for external names which can not be resolved. RTFM on your DNS server.
It might be, but if the packets come in periodic bursts from only a few machines, it is probably nothing more than a misconfigured Cisco distributed content director trying to find the shortest routes to your machine. You can eliminate the log clutter with a rule like:
block in quick on ext-interface proto tcp from any to firewall port = domain flags SA
It is possible to filter the loopback interface on every platform except Solaris and HP-UX.
In most cases, do nothing. There is no law (for the most part) against port scanning. If you notice EXCESSIVE activity from a certain IP (i.e. multiple days or large bandwidth), then you can report it to the ISP that owns that IP address... other than that, there's not much you can do. There's no harm in some portscans... and it's a waste of your time to go after them. You could spend all day every day to track down all the people who port scanning you (especially if you have a large network), and blocking their IP's would make your ruleset inefficiently long. Additionally, if you run a webserver, or any public service, you'll likely block some valid IP's since many IP's are dynamic. The best defence is to secure your network, have a secure ruleset that you've tested in-depth.
For queries from the firewall machine itself, you can the open ports for replies to archie queries:
pass in quick proto udp to ext-interface from any port = 1525 to firewall port > 30000 keep state
pass in quick proto udp to ext-interface from any port = 191 to firewall port > 30000 keep state
From NATed machines behind the firewall, you either need to modify one of the ip-filter proxies so it works with archie, or to have your users use an archie site which returns replies on the querying port, such as archie.rediris.es.
quick affect head rules?
Essentially thequick, like thepassorblock, affects the default action for the group if nothing in the group matches. Any head rule, quick or otherwise, causes immediate recursion into that rule group. For example:
block in quick on de0 all head 100
descends into group 100, seeking further matches. If nothing matches inside and group 100 returns, theblock in quickaction specified in its head rule above is taken.
If something inside group 100 does match, that rule's action is taken instead. If that inner matching rule doesn't havequick, thequickbit is unset, and if nothing else inside group 100 matches it returns to its head, but with the action(s) specified by the inner rule -- specifically, thequickbit is now off and overrides the original head rule'squick. So in that case, rule processing continues past the above head rule, because a rule in that group matched and set "not quick" as part of the processing actions to do. If the head rule is notquickthen if no rules match, the end result is not aquickrule.
You can use:
map foo0 0/0 -> 0/32 proxy port ftp ftp/tcp
This says "map everything to my external IP address." Unfortunately there is no way to say 0/32 -> 0/32 yet, so either use the above rule, or you can have yourip-up(see the pppd manpage) edit youripnat.confeach time you get a new IP.
Most people send them to the IP Filter mailing list, and this is perfectly fine. If you do not feel comfortable doing this, feel free to send them to Darren directly.
There is no simple MIB, but there are perl and shell scripts available to read various ip-filter statistics into MRTG. See http://www.18james.com/utilities.html#mrtg for more information on IPF and MRTG.
There are two numbers represented in statetop, each number represents the state of one side of the connection. The meanings of the numbers follow:
Number Name Comment 0 TCPS_CLOSED closed 1 TCPS_LISTEN listening for connection 2 TCPS_SYN_SENT active, have sent syn 3 TCPS_SYN_RECEIVED have sent and received syn 4 TCPS_ESTABLISHED established 5 TCPS_CLOSE_WAIT rcvd fin, waiting for close 6 TCPS_FIN_WAIT_1 have closed, sent fin 7 TCPS_CLOSING closed xchd FIN; await FIN ACK 8 TCPS_LAST_ACK had fin and close; await FIN ACK 9 TCPS_FIN_WAIT_2 have closed, fin is acked 10 TCPS_TIME_WAIT in 2*msl quiet wait after close
Some additional notes:
States < TCPS_ESTABLISHED are those where connections not established
States > TCPS_CLOSE_WAIT are those where user has closed
States > TCPS_CLOSE_WAIT && < TCPS_FIN_WAIT_2 await ACK of FIN
All comments are Darren's taken straight fromip_compat.h
Editipf_state.hand look for the lines:
#ifndef IPSTATE_SIZE # define IPSTATE_SIZE 5737 #endif #ifndef IPSTATE_MAX # define IPSTATE_MAX 4013 /* Maximum number of states held */ #endif
IPSTATE_MAXshould be approx. 70% ofIPSTATE_SIZEand both numbers should be prime. The exact values you need depend highly upon the situation, but do NOT go crazy. Numbers in the 6 digits are very excessive. If you are having trouble with your state tables check out section IV-12 first.
For very high-traffic installations this will need to be tweaked. A good number to start with is 10 connections per workstation and adjust from there. Other things that might need tweaking depending on your situation isNMBCLUSTERSandNAT_SIZE.
Just as a guide, here's some of the other #defines and what they mean:
NAT_SIZE- Size of the hash table for NAT rules
RDR_SIZE- Size of the hash table for RDR rules
NAT_TABLE_SZ- Size of the hash table which holds all active MAP/RDR entries
HOSTMAP_SIZE- Table for holding the mapping of internal hosts to external IPs for consistency purposes when talking to a specific remote host
Not with IP Filter itself. But the code is there to allow an external program to do this.
Additionally Andrei Syrovenko wrote a utility calledrmstatethat does just that. His code is hosted at http://www.andy.in.ua/ipfilter/rmstate-1.1.tgz. We mirror his software here. Note that it is NOT guaranteed by Andrei Syrovenko, Darren Reed, Phil Dibowitz, Jason Lingohr or anyone else, nor is it part of the official IPF codebase.
The program takes only one argument: the source IP address of the entries that should be removed from the state table. Additionally, it will only work with ipfilter 3.4.26 and later, or 4.1.29 and later.
A lot. There have been cases where there have been more than 45,000 rules without noticeable performance loss. The important thing when dealing wih large numbers of rules is to use groups. When properly written and organized you can have tons of rules.
The solution seems a bit counter-intuitive at first, but it's actually quite simple. Setup a redirect on your internal interface, like this:
rdr int-interface ext-address/32 port 110 -> int-address port 110 tcp
rdr int-interface ext-address/32 port 25 -> int-address port 25 tcp
Remember that this is only if the services are on the firewall. If the services are on machines behind the firewall see IV.8.
Unfortunately, I've never used it myself. At this point the best I can do is give you the syntax:
map ext-interface int-address/24 -> ext-address/32 proxy port 500 ipsec/udp
Unfortunately, I've never used it myself. At this point the best I can do is give you the syntax:
map ext-interface int-address/24 -> ext-address/32 proxy port 1720 h323/tcp
Unfortunately, I've never used it myself. At this point the best I can do is give you the syntax:
map ext-interface int-address/24 -> ext-address/32 proxy port 7070 raudio/tcp
head statements for a group?
It is not possible to do this in the 3.x version of IP Filter, however this is a feature of 4.x (currently in beta).
Yes and no. A bridge won't do address translation - it's not supposed to. However, you can use IPNat's proxies to allow connections across the statetable. For example, you could use the FTP proxy as follows:
map 0/0 -> 0/0 proxy port ftp ftp/tcp
To enable FTP across your bridge. Remember that at this time, the IPF FTP proxy does not support EPSV Passive connections, only plain PSV.
This question isn't as simple as it sounds. It takes an understanding of filtering, ICMP, UDP, ping, and traceroute. Here are some of the basics to get you started. Remember that if you are keeping state on all outgoing ICMP, then outgoing pings will automatically work.
Ping uses ICMP. Specifically it entails an ICMP type 8 code 0 (herein refered to as ICMP 8/0) packet (called "echo request") being sent to the target, and an ICMP 0/0 packet (called "echo reply") being sent back to the original host. To allow pings out one might do:
pass out quick proto icmp from any to any icmp-type 8 code 0 keep state
or if you didn't want to use keep state you could do:
pass out quick proto icmp from any to any icmp-type 8 code 0
pass in quick proto icmp from any to any icmp-type 0 code 0
Traceroute requires ICMP 11/0 and 3/3 (TTL expired and Port unreachable respectively). You will let to need to let these in to your network to allow outgoing traceroutes. Additionally, UNIX traceroute requires UDP packets (to the target) to ports greater than 3000. So you will need to let those in or out of your network to let UNIX traceroutes in or out of your network. Microsoft'stracertutilitiy does not use UDP. For more information, see various discussion in the mailing list archives.
A utility called "ipscan" will get built if you build the ipfilter package from a download. With this, you can match on the first 16 bytes of a packet.
A sample config would be:
# Track ssh connections (i.e do nothing)
#
ssh : (), ("SSH-") = track else close
#
# Things which look like smtp to be tracked else closed.
# Client can start with EHLO (ESMTP) or HELO (SMTP).
#
smtp : ("HELO ", "**??."), ("220 ", "....") = track else close
#
and then in ipfilter rules, use:
pass out proto tcp from any to any port = 22 keep state scan ssh
pass out proto tcp from any to any port = 25 keep state scan smtp
At this point, it's more about ensuring that a particular kind of services appears to be initiated over a praticular port.
Darren is still developing this new code to do more things. Eventually it will integrate differently into ipfilter rather than just via "keep state" rules.
As of IP Filter 4.x and later, you can set variables in your ipf.conf and ipnat.conf as follows:
int_iface = "hme0";
ext_iface = "iprb0";
dmz_ip = "192.168.1.0/24";
int_ip = "192.168.2.0/24";
And then you can use those variables anywhere by prepending them with a dollar sign:
pass in quick on $int_iface from $int_ip keep state
Variables can contain other variables, and may also be referenced with${variable}syntax.
Try addingflags Sto each one of your TCP rules that haskeep statein it.
What might be happening is you're getting state entries for more than just the first packet of each connection and your state table is filling up. Previous versions of IPF did this when a packet arrived slightly out of window - it would not associate it with the state entry. The solution was to only add a state table entry for those packets with a SYN flag.
This should no longer be required. However, many users will tell you it is a good security practice to useflags Swith TCP rules anyway.
See above.
This is done because depending on your ruleset, a new rule added may not be affective based on old rules, and also because the script reads in the entire ruleset anyway, so it will prevent duplicates. The script usesipf -Fawhich flushes rules but not state table entries. To flush state table entires useipf -FS.
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 = 113Solaris users, see VII-1
See above.
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.
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.
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).
You probably have anipf.confrule that looks something like:
block return-rst in on ext-interface proto tcp allA 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 allwhich will send RST only to SYN packets.
block return-rst in on ext-interface proto tcp all flags S
Add a second ftp proxy rule to your ipnat.conf:
map ext-interface firewall-ip/32 -> firewall-ip/32 proxy port ftp ftp/tcp
It isn't possible to map ports on ICMP packets. Hence, once a state table entry is set up to a particular target, only one machine can ping that target until the state table entry expires.
For TCP and UDP, portmapping allows simultaneous connections to external targets from multiple machines in the LAN.
There will supposedly be a workaround for this in the 4.x series.
There may be many reasons for this including that mentioned in question 1 of this section. However, there are other possibilities such as you have a very busy firewall and you're filling the state table. For this you have a few options: you can enlarge the state table, tweak some IPF values, or both. See the III-25 for details on enlarging the state table. Here are some values to tweak though.
ipf.fr_tcpidletimeout=7200
ipf.fr_tcpclosewait=120
ipf.fr_tcplastack=120
ipf.fr_tcptimeout=240
ipf.fr_tcpclosed=60
ipf.fr_tcphalfclosed=300
ipf.fr_udptimeout=90
ipf.fr_icmptimeout=35
These values will be in very different places depending on your OS, such as/etc/rc.sysctl,/etc/sysctl.conf, or/etc/system.
log body in my rules but the body of the packet isn't getting logged.
You need to use the -b command line option to ipmon.
The IPF How-To gives a good explanation of this. The client will try to connect to the server's internal IP address because that's the way passive FTP works: the server tells the client its IP address in the payload and the client connects to it.
The solution is to explicitly tell your FTP server what to report as its IP address, and give it a range of ports to give out as well. You will then need to redirect traffic from those ports on your IPF box to the FTP server. Each FTP server is different, and you'll need to read the manual for your specific software, but to give an example, you can specificy this information in WU-FTPd's configuration file as follows:passive ports 0.0.0.0/0 32768 49151
passive address your.pub.IP.addr 0.0.0.0/0
At the time of writing, it's been reported that Microsoft IIS's FTP server is not capable of being configured this way. However, most Unix FTP servers should have an option for this somewhere.
If you use a rule like:
rdr x.x.x.x port 80 -> y.y.y.1,y.y.y.2,y.y.y.3 port 80 tcp round-robin
You will get an error likemissing fields - 2nd port (,). This is because you can't put more than two hosts on a single round-robin line. You need to reformat it like this:
rdr x.x.x.x port 80 -> y.y.y.1,y.y.y.2 port 80 tcp round-robin
rdr x.x.x.x port 80 -> y.y.y.3 port 80 tcp round-robin
or better yet like:
rdr x.x.x.x port 80 -> y.y.y.1 port 80 tcp round-robin
rdr x.x.x.x port 80 -> y.y.y.2 port 80 tcp round-robin
rdr x.x.x.x port 80 -> y.y.y.3 port 80 tcp round-robin
The two examples above act exactly the same, but notice that the second example is much easier to manage. If one of your servers goes down, it's very easy to take it out of the loop quickly with the second example. In the first example, if y.y.y.1 or y.y.y.2 goes down, and you take that line out, you loose two hosts.
When troubleshooting problems with ipnat remember that rules are process by network size. So a /32 rule will always be applied before a /24 rule, etc. Therefore a ruleset like:
map ext-interface x.x.x.x/24 -> y.y.y.y/32 proxy port ftp ftp/tcp
bimap ext-interface x.x.x.a/32 -> y.y.y.y/32
bimap ext-interface x.x.x.b/32 -> y.y.y.y/32
The proxy rule will never get matched. Therefore, if you need your bimap rules to be /32, then your proxy rule will need to be /32 to as well. Albeit a pain, the following is the only way to fix the problem:
map ext-interface x.x.x.a/32 -> y.y.y.y/32 proxy port ftp ftp/tcp
map ext-interface x.x.x.b/32 -> y.y.y.y/32 proxy port ftp ftp/tcp
...
bimap ext-interface x.x.x.a/32 -> y.y.y.y/32
bimap ext-interface x.x.x.b/32 -> y.y.y.y/32
This way the proxy rules will match instead of getting skipped over.
interface/32, 0/0 or 0/32, and it doesn't work!
These special aliases do not work in IPF rules, or in IPNat rdr rules. They only work in IPNat's map and bimap rules.
Chances are you are using IPF as a loadable kernel module. If not, then you want:
ipf -D
Which will disable the filter. However, if you are using a loadable kernel module, that option is not available to you. You can unload the module, but it will get reloaded the next time the device associated with IPF is accessed. So your best bet is to switch to an empty rulset:
ipf -s
That assumes your other ruleset actually is empty. Alternatively, you could unload the modules, and then mv the modules out of the way. This is a bit ugly, but it will work as a temporary way of keeping IPF out of the way for testing.
The Cisco VPN Concentrators are often configured to expect a source port of 500 in addition to the destination port of 500. Since NAT, by default, changes the source port, this breaks. Add a line like so:
map le0 from x.x.x.x/24 port=500 to ip.of.vpn/32 -> a.b.c.d/32
to your ipnat.conf.
If you try to remove an entry from an ippool and getremove_pool:SIOCLOOKUPDELNODE: No such file or directory, you're running an older version of IP Filter 4. This bug is fixed in recent versions.
At the time of writing, this bug was in the IP Filter included with Solaris 10. If y ou are using this version your options are upgrade to the open-source version of IP Filter, or file a bug with Sun.
First, are you using portmap in your ipnat (see III-6)? If not, then you will be limited to the number of external IP addresses you have to NAT to PER DESTINATION (see below for more info).
However, some implementations of VPN will require a unique source address, and thus you will still only be able to have a number of NAT'd VPN sessions equal to the number of external IP address you have to NAT to PER DESTINATION (even if you use portmap).
In other words, if you have 10.0.0.0/8 internal and you have only one external IP address 1.2.3.4, then you have only one VPN connection TO EACH VPN DESTINATION, so you could have hundreds of VPN sessions as long as they were to different destinations.
But, if you have 10.0.0.0/8 internal and you have x.x.x.x/26 then you have have 64 VPN connections PER destination with as many destinations as you want.
From Darren: This will be because both packets match different rules. Matching the same rule packets will get the same address. I will include the ipsec proxy in 3.4.21 which will help with this.
IPF logs as local0 so you'll want something to the effect of:
local0.debug /var/log/ipf.login your syslog.conf. NOTE: There has to be atleast one TAB in that line, not just spaces.
ipmon -oI, why not?
You can only use one ofipmon -oIandipmon -s. Just do atail -f filenamewhere filename is whatever syslog logs ipf stuff to.
Are you running *BSD or SunOS? Check your kernel configuration, make sure you have "options IPFILTER_LOG"
If you're seeing log entries like:Mar 22 13:45:45 gateway ipmon[94]: 13:45:44.302938 xl2 @0:1 SYou've recently upgraded IP Filter on your FreeBSD system. FreeBSD installs ipmon in /sbin while IP Filter installs ipmon in /usr/sbin. Thus you are still using the old version of ipmon with your new version of IP Filter. Delete
Feb 20 17:29:47 gateway ipmon[94]: 17:29:47.377435 xl2 @19:10241 L
/sbin/ipmon.
Sure! Instead of invoking ipmon with the-soption, just specify a filename:
ipmon filename
Plus any other options you want. Alternatively, if you want to use syslog, don't specify a filename, and use-s.
This is a "feature" of Solaris' STREAMS-based TCP/IP stack. Basically you have to add a rule allowing the TCP Reset to leave. So let's say that you want to return-rst on ident, port 113, so that sending mail doesn't give long delays, and IRC works:
#return-rst for identThe first rule just blocks with return-rst, the second rule allows packets out from port 113 with the RESET flag.
block return-rst in quick on ppp0 proto tcp from any to any port = 113
pass out quick on ppp0 proto tcp from any port = 113 to any flags R/RSFUP
/usr/ucb/cc.Sun has a compiler usually installed in /usr/ucb/cc. Unfortunately, it's a really expensive compiler that doesn't ship with Solaris by default. Fortunately, since Solaris 8, they've included gcc for you on the Solaris Companion CD (/opt/sfw), it's a package calledSFWgcc. In Solaris 9 this is now on the main installation CDs and is in /usr/sfw.
If you're using an older version of Solaris you can get gcc from SunFreeware.com.
Note that you need to comment out the "For SUNWSpro" lines in the Makefile and uncomment the "for GCC" lines in order to compile with gcc.
You're most likely trying to use an IPF modules compiled as a 32-bit binary. You need to compile it as a 64-bit binary, so you must either use the cc with SUNWspro, or GCC 3.0 (see VII-5). GCC 2.x will NOT work. SUNWspro is available from Sun, you can get a demo license (please READ what you can and cannot do according to the demo license).
Type isainfo -vk.
GCC 2.x cannot make 64-bit executables, but GCC 3.x can. The following procedure for compiling a gcc 3x is provided by Aaron Jackson:
# gunzip -c gcc-3.2.2.tar.gz | tar xvf -
# mkdir objdir
Note that objdir should NOT be in the source directory.
# cd objdir
# ../gcc-3.2.2/configure --enable-languages=c --prefix=INSTALL_PATH
NOTE: INSTALL_PATH is where you want to install gcc. This should NOT be in the gcc source dir, objdir or any dir that contains an previous install of gcc.
# make bootstrap
# make install
You should then be able to use this new GCC to compile a 64-bit version of IP Filter. In order to do this, you'll need to change the Makefile from:
XARCH64="-m64 -mcmodel=medlow"
to:
XARCH64="-m64"
Sun's Forte Compiler can make 64 bit modules. This compiler is not standard with the OS, you have to buy it separately. However, there is a "try-and-buy" version which you can install, and use for a limited time. You can get this time limited version on cdrom or you can download it from Sun.com. Note that the download is very large. Please READ what you can and cannot do according to the demo license.
Some generous individuals have made available precompiled IPF binaries for 64-bit machines. Try http://www.maraudingpirates.org/ipfilter/. You can also try using GCC 3.x (see VII-5).
First select "ipfx", and install that subpackage. When pkgadd completes, rerun pkgadd and then install the "ipf" sub-package.
No. IPF on Solaris only operates as a Layer 3 device (router). This means you need distinct subnets for each host interface.
Solaris's/etc/systemis consulted when booting, so you can modify IPF kernel parameters there, for example:
* * ipf: adjust the default tcp timeouts downward so that * idle (dead) and half closed states get killed off quicker. set ipf:fr_tcpidletimeout = 172800 set ipf:fr_tcphalfclosed = 7200 * * ipf: adjust the state table sizes so we have enough buckets. * IPSTATE_MAX (=fr_statemax) should be ~70% of IPSTATE_SIZE * IPSTATE_SIZE (=fr_statesize) has to be a prime number set ipf:fr_statemax = 7000 set ipf:fr_statesize = 10009 * * ipf: adjust the NAT table sizes so we have enough buckets. * generally you have fewer than 127 rules in ipnat.conf * so no need to waste memory for more. set ipf:ipf_nattable_sz = 10009 set ipf:ipf_natrules_sz = 127 set ipf:ipf_rdrrules_sz = 127 * * note that the timers run "2 ticks to a second", so * for example, written below is the following: * set ipf:fr_tcpidletimeout = 172800 * this sets the tcp idle connection timeout to * (172800/2) / 3600 = 24 hours. *
Solaris8 on Sparc is straightforward, however, doing this on Intel requires a tweak. Here's instructions for both platforms:
That should be it.
- Get Squid-2.4STABLE1
- Get and apply the 6 patches at http://www.squid-cache.org/Versions/v2/2.4/bugs/
save these as the-patch-filename.patch
$ for file in `ls *.patch`
> do
> echo "applying patch $file..."
> patch -p0 < $file
> done
- Edit out the ipv6 struct as described in http://marc.theaimsgroup.com/?l=ipfilter&m=99557783205895&w=2
Now for Solaris 8 on Sparc you are ready to go:
# ./configure --enable-ipf-transparent ; make
But for Solaris 8 on x86 you need two more steps...
- First solve the va_args issue with gcc 2.95.2 on x86
# diff -c src/client_side.c.orig src/client_side.c
*** src/client_side.c.orig Thu Jul 19 17:41:12 2001#
--- src/client_side.c Thu Jul 19 17:41:45 2001
***************
*** 37,42 ****
--- 37,45 ----
#if IPF_TRANSPARENT #if HAVE_SYS_IOCTL_H + #if defined(va_start) /* dirty hack. sol7/8 x86 + gcc 2.95.2 */ + #define _SYS_VARARGS_H + #endif #include <sys/ioctl.h> #endif #include <netinet/tcp.h>
- Next solve the #define free issue (WTF?)
# diff -c src/squid.h.orig src/squid.h
*** src/squid.h.orig Thu Jul 19 17:38:57 2001 --- src/squid.h Thu Jul 19 17:40:26 2001 *************** *** 403,411 **** #ifndef malloc #define malloc + #endif ! #ifndef free ! #define free + ! #endif #ifndef calloc #define calloc + #endif --- 403,411 ---- #ifndef malloc #define malloc + #endif ! //#ifndef free ! //#define free + ! //#endif #ifndef calloc #define calloc + #endif#
- Now finally for Solaris8 x86 you can
# ./configure --enable-ipf-transparent ; make
The loopback interface on Solaris is a "fake" interface. You cannot filter it, nor can you snoop it. This is for performance reasons.
Virtual interfaces in Solaris are very similar, to filter on them, use the physical interface instead.
UPDATE: As of Solaris 10 Update 6, you can now do this. Setset interfcept_loopback true;in/etc/ipf.confor/etc/ipf6.confbefore all rules in the file. Thanks to Simon-Bernard Drolet.
There are three possiblities here: 1) using Solaris curses, 2) using ncurses from the Solaris Companion CD 3) using ncurses you compile yourself. For all three of these methods make sure the following is set (3.4.22 and on already has this):
STATETOP_CFLAGS=-DSTATETOP
Once that's done, pick one of the three methods above. The easiest way is to use Solaris curses. For that method, in the Makefile change:
STATETOP_LIB=
to say:STATETOP_LIB=-lcurses
And that will do it.
If you don't want to use Solaris curses and would prefer to use ncurses, install the ncurses package on the Solaris 8 Companion CD or from any other source of your choice and then change your STATETOP_INC line to read:
STATETOP_INC=-L/opt/sfw/include
and set:
STATETOP_LIB=-L/opt/sfw/lib -R/opt/sfw/lib -lncurses
Adjust accordingly if your ncurses libs/includes are in a different place.
If you want to use ncurses but are using Solaris < 8, or just don't want to use the Companion CD verion of ncurses for some reason, then adjust the STATETOP_INC line to read:
STATETOP_INC=-I/usr/local/include
And set STATETOP_LIB to be:
STATETOP_LIB=-L/usr/local/lib -R/usr/local/lib -lncurses
Note that these are usual locations for the include and library files. If you installed them in other places, you'll need to specify the appropriate path's.
NOTE: If you are using gcc 3.1+, you may need to uninstall either curses, or ncurses. Having both may cause conflicts during compile.
According to SunSolve many of these tunnels use a ton of space in the stack, so you should increase your stack size. To find out what it is do:echo 'lwp_default_stksize/D' | adb -k /dev/ksyms /dev/mem
Solaris 2.6 and above in 32-bit mode default to 0x2000 while Soalris 7 and above in 64-bit mode default to 0x4000. Try doubling this number. To set it, add a line to/etc/systemlike this:
set lwp_default_stksize=0x4000
and reboot. You may also use decimal values (0x4000 = 16384 and 0x8000 = 32768). For more information on tuning kernel parameters click here, and for more information on lwp_default_stksize click here.
Thanks to James McPherson and Darren for this information.
Try disabling hardware checksumming. Edit/etc/systemand add the line:
set ip:dohwcksum=0
and reboot. (Thanks to Ben Rosenblum and Hans Werner Strube).
There are no official IP Filter binaries. However some kind people have made their binaries available for download. NOTE WELL: The following sites are NOT OFFICIAL. The binaries there are NOT supported by Darren Reed, Phil Dibowitz, OR the authors or owners of the sites (unless they state otherwise).
From Darren Reed: "If you're using IPFilter on Solaris9, you might want to make sure you apply patch 112233-02 (or later) to fix a problem with the kernel attempting to prevent too much stack being used (and causing the system to crash.) This is particularly fatal when using IPFilter with ip.tun* and ESP+AH."
Read INSTALL.Sol2 in the source directory. Solaris 7, 8, and 9 are often called 2.7, 2.8, and 2.9, and the same Sol2 file works for all of the releases.
/usr/include/ia32/sys/reg.h:300: error: parse error before "upad128_t" when I compile IPF, why?
The problem is that the Solaris headers changed across updates of Solaris 9 and you are using a GCC from before the change on an updated system. (i.e. a GCC built for Solaris 9 <= 12/03 on Solaris 9 >= 4/04).
You can either rebuild GCC for your version of the system (it works, even using a GCC built for the previous version), or see apply a fix to your headers: http://groups.yahoo.com/group/solarisx86/message/6617.
First you need to compile IPFilter to support it. Do this by uncommenting the followig line in the top level Makefile:
#COMPIPF=-DIPFILTER_COMPILED
Then build, and install the ipf LKM with that included. Then you need to build the ipf rules LKM. Probably the easiest way to do that is this:
cd ip_fil4.1.1
ipf -cc /etc/opt/ipf/ipf.conf
make solaris
You will then have to go searching for a file called "ipfrule" under the SunOS5 directory, somewhere - e.g.:
SunOS5/sparc-5.6/ipfrule
That is the LKM with the compiled filter rules. Copy this to /usr/kernel/drv to get it to load.
From Darren:
"Very significant. I did do some benchmarking of this, originally but I forget what the performance measurements were, now.
"The improvements in performance come from two areas. The first is that the packet matching is now all in C, rather than using intermediate structures. The second is that rather than compare each field, one at a time, in each rule, it sorts the fields to be matched for each rule as an optimisation and only does comparisons when the matching is different."
If you get an error like this:
gcc -I. -g -I../.. -D_BSD_SOURCE -DSOLARIS2=9 -c ../../lib/debug.c -o debug.o
../../lib/debug.c: In function `debug':
../../lib/debug.c:30: error: `__builtin_va_alist' undeclared (first use in this function)
../../lib/debug.c:30: error: (Each undeclared identifier is reported only once
../../lib/debug.c:30: error: for each function it appears in.)
*** Error code 1
make: Fatal error: Command failed for target `debug.o'
Current working directory /home/phil/build/ip_fil4.1.7/SunOS5/i386-5.9
*** Error code 1
make: Fatal error: Command failed for target `sunos5x86'
Current working directory /home/phil/build/ip_fil4.1.7
*** Error code 1
make: Fatal error: Command failed for target `solaris'
Then you're probably using gcc 3.3 or later, try 3.2.x. See the README for gcc 3.3 on var_args problems for details.
For pfil, do:
CC=gcc make -f Makefile.gcc
And for ipf, edit the Makefile and uncomment the right CC line, and then:make solaris
Jeff Earickson maintains a How-To on the subject. You can find it here.
Solaris 10 has deprecated the classic SYSV-style init scripts. Instead, you now need to use svcadm to control services. See Sun's Configuring Solaris IP Filter docs.
It does for 11.x. It does not work for 10.x. Read this.
Recent versions of IPF support Bridging on FreeBSD. Flemming Laugaard shares this procedure for setting up Bridging. Set these in your kernel conf:
options IPFILTER
options IPFILTER_LOG
options NMBCLUSTERS=65535
options BRIDGE
And then in sysctl.conf:
net.link.ether.bridge=1
net.link.ether.bridge_ipf=1
net.link.ether.bridge_cfg=em1,em2
net.inet.ip.forwarding=1
Replacing em1 and em2 with your interfaces. Then put your rulset in place, and that should be it.
Rene van Hoek points out that you'll also want to set "net.link.bridge.pfil_bridge" to disabled if you don't want all your states to be listed (and filtered) twice. See this thread for more detials.
Set the kernel option:
options IPFILTER_DEFAULT_BLOCK
and recompile your kernel.
Generally, the most recent IPF release will be found in both FreeBSD STABLE and FreeBSD CURRENT.
First you have to install the system sources, see the FreeBSD Handbook if you didn't choose to do this at install time. After installation, the IPF source will be in /usr/src/contrib/ipfilter/. Take care to ensure that comments in various documentation files apply to the particular version of FreeBSD you are running since IPF supports many FreeBSD versions and the operating system has changed significantly over the past few years.
IPF is compiled and installed as part of the regular "make world" and "make kernel" procedures. See the FreeBSD Handbook for more on these.
If you want to rebuild and reinstall only the ipf and ipnat shipped with the sources you have installed, do this:
cd /usr/src/sbin/ipfThe ipl kernel module is (re)built as part of the kernel building procedure as described in the FreeBSD Handbook.
make clean all install
Note that, if version skew between your running system and the source you have installed causes the compile to fail, it is best to upgrade the entire system with either a binary or source upgrade.
First, create a set of filter rules appropriate to your application and save them in /etc/ipf.conf.
Then load the ipl loadable kernel module (these are called "KLD"s in FreeBSD):
kldload iplThen load your rule set into ipfilter:
ipf -Fa -f /etc/ipf.conf
No. IPF can be enabled after boot by loading the ipl loadable kernel module as above, or just by configuring it to load at startup as in the next answer.
First, create a set of filter rules appropriate to your application and save them them the file /etc/ipf.conf.
Then, set the following variables in the /etc/rc.conf file:
ipfilter_enable="YES"and reboot. The startup scripts will load the ipl kernel module (if it is not already in the kernel) and pass the rule file to the ipf program.
ipfilter_program="/sbin/ipf -Fa -f"
ipfilter_rules="/etc/ipf.conf"
ipfilter_flags=""
Note, however, if you are running FreeBSD 4.5+, the switches inipfilter_programaren't needed, just put/sbin/ipf(Thanks to Adrian Portelli).
Add the following lines to your custom kernel configuration file:
then compile and install the kernel using the procedure described in the FreeBSD Handbook.options IPFILTER options IPFILTER_LOG
First, create a set of NAT rules appropriate to your application and save them in the file /etc/ipnat.conf.
If not already loaded, load the ipl loadable kernel module:
kldload iplThen load your rule set:
ipnat -f /etc/ipnat.conf
First, create a set of NAT rules appropriate to your application and save them in the file /etc/ipnat.conf.
Then set the following variables in the /etc/rc.conf file:
ipnat_enable="YES"and reboot. The startup scripts will load the ipl kernel module (if it is not already in the kernel) and pass the rule file to the ipnat program.
ipnat_program="/sbin/ipnat -CF -f"
ipnat_rules="/etc/ipnat.conf"
Note, however, if you are running FreeBSD 4.5+, the switches inipnat_programaren't needed, just put/sbin/ipnat(Thanks to Adrian Portelli).
Dummynet is closely tied to ipfw(8) and is not supported by IPF. Darren suggests the use of the ALTQ traffic shaper instead. It is possible to use IPFW and IPF together, e.g. using IPFW for dummynet and IPF for filterning and NAT, see below.
IPF and IPFW are close enough in speed that it is not an issue. As far as which is better, this is something only you can answer. Each is different and appropriate for it's own application. Asking this indicates you have not done enough research into these two tools. Find out as much as you can about both, try both, and decide which is best for you.
No. You can run them both on a single machine. However, you must take care to ensure that one package's rules do not interfere with the other's. Note that the packages get access to rules in the order in which they were loaded, e.g. if IPFW is compiled in the kernel and IPF is loaded as a module, IPFW "sees" packets before IPF.
Yes. How much depends much more on your particular situation than any intrinsic issues. People who have done this have reported that it does not meaningfully impact overall firewall performance.
The sysctl(8) interface to the kernel allows setting some of the values on a running system under net.inet.ipf in the tree. You can use the /etc/rc.sysctl file to set these values at boot time.
David lets us know that this values used in sysctl are in units of the slow timmer (500ms), so it's half-seconds, not seconds.
According to FreeBSD problem-report kern/34801, ipfilter doesn't support RFC 1323 window size extensions. This became more problematic with the new net.inet.tcp.recvspace default of 65536 in FreeBSD 4.5+. You can drop recvspace down one to 65535 or to 32768 by using:
sysctl net.inet.tcp.recvspace=32768Dropping it merely one (to 65535) will do the trick, however having it a multiple of the page size, is supposedly better for performance. Thus you might try to use 32768.
Installing IP Filter from source on FreeBSD can stick an extraipfilter_flags="-E"in/etc/rc.confwhich enables IP Filter for the second time thus generating a few errors. Taking out the above line will fix the problem.
From FreeBSD 4.8 onwards, you can simply setipv6_ipfilter_rules="/etc/ipf6.rules"
in your rc.conf, and of course put rules in the file, and voila.
Upgrade IP Filter kernel source and build/install new binaries. In the IP Filter source directory:
./BSD/kupgradeRecompile the kernel with new version of IP Filter:
make netbsd
make install-bsd
cd /sys/arch/`uname -m`/confReboot, and you should be all set.
config mykernel
cd ../compile/mykernel
make depend
make
mv /netbsd /netbsd.old
mv netbsd /netbsd
NetBSD 1.5.3 onwards support ipfilter with IPv6 out of the box. Simply place your rulesets in /etc/ipf6.conf and run /etc/rc.d/ipfilter reload to activate. You will also need to have IPv6 enabled in the kernel, the key directive is "options INET6". See NetBSD documentation on compiling a custom kernel if you are having problems with this.
You need to increase the VM kernel allocation. Compile a custom kernel and increase the vm.nkmempages value. The default is 4096, and doubling it should be more than ample for very large rulesets. Thanks to Gene.
Set the kernel option:
option IPFILTER_DEFAULT_BLOCK
and recompile your kernel.
If you are using OpenBSD 3.0 or higher, you will notice that IP Filter no longer comes with OpenBSD. To install IP Filter on OpenBSD 3.0+ see question 4. If you are using OpenBSD < 3.0 then read on.
The following procedure assumes that you've at least configured your kernel. If you have not, check out http://www.oreillynet.com/pub/a/bsd/2000/10/31/OpenBSD.html for information on that.
# gunzip -c ip_fil3.4.21.tar.gz | tar xf -
# cd ip_fil3.4.21
# BSD/kupgrade
# make openbsd
# make install-bsd
# cd /sys/arch/foo/compile/kernel
# make depend
# make bsd
# cp /bsd /bsd-original
# cp bsd /bsd
# reboot
Note that the last two steps prior to rebooting make a backup copy of your current kernel to /bsd-original and then copy the new kernel into place.
Pat Lougheed wrote a webpage on upgrading IP Filter in OpenBSD that goes more into depth. At the time, the procedure was a little uglier. As of now you can ignore steps 10-12 provided you're upgrading to atleast 3.4.21. You find his page here.
In order to run IP Filter you'll need to add the following to your/etc/rc.conffile:
ipfilter=YES
If you'd like to use IP NAT as well, then additionally add:
ipnat=YES
OpenBSD no longer comes with IP Filter as of version 3.0. However, you can still use it! You have two options, 1, you can use the ISOs of OpenBSD3.x + IPF created by Darren Reed here (and also mirrored by locations listed here) or you can install IP Filter into your existing system. To install IP Filter into your existing OpenBSD 3.x system, simply follow the directions in the OpenBSD/README.3_0 file located in the IP filter 3.4.23 or later installation directory.
In OpenBSD < 3.0, you can only filter in the in direction. However, in OpenBSD 3.0+, you can filter in both direction.
IPF 4.x runs on Linux. Recent versions even run on 2.6.x kernels. Darren tests on SUSE 9.1 (as of this writing), but it should work reasonably well on any distro. There have been many confirmations of successfully running it on CentOS/RHEL 4.
IPF 3.4 was succesfully ported to RedHat 4.2. It is expected to work reasonably well with any 2.0.31+ kernel, on a non-glibc system. It does not work with any other later release of Linux.
Also note that, for Linux version 2.2.x see IP Chains, and for Linux version 2.4.x and above see IP Tables.
The following are HowTos that have been written for some distributions:
No, thank you. The current URL is easy, and all my big projects are in the phildev.net domain. I feel it's very easy to find right now, not only is it linked to from the IP Filter webpage, but if you plug IPF FAQ into google, this copy is the second hit.
No thanks. I'm set.
That depends on a lot of things. Sometimes a few times a month, sometimes once every few months. Usually an update gets in here once a month or so. However as of this update (01/11/02), I'm going to start revamping the HowTo, so there may not be updates as frequently. If an important question gets sent my way, I'll add it though.
Email phil@ipom.com and make sure that "IPF-FAQ" is in beginning the subject line. I'd also appreciate it if the subject reflected what the contents of the email is such as "IPF_FAQ: IPF and FTP clarification" or "IPF-FAQ: Typo correction."
There are many possibilities. I may be saving it because I feel it's better suited for an area in the HowTo. I may not feel it's valid for the FAQ. I may not have had time to update the FAQ. I try to respond to every submission and let you know what's going on though. Keep in mind I work full-time as a Sysadmin, I volunteer for many open-source projects, I run quite a few websites, am involved in local LUGs, I keep up the IPF FAQ, I have a girlfriend, etc., so it may take me time to update the FAQ.