Although there, of course, many resources, here's a quick <snip> from the FreeBSD man page (obviously NOT the Darwin man pg ...) summarizing the ipfw --> ipfw2 diffs ... <http://www.kerneled.com/doc/man/freebsd/man8/ipfw.html> IPFW2 ENHANCEMENTS This Section lists the features that have been introduced in ipfw2 which were not present in ipfw1. We list them in order of the potential impact that they can have in writing your rulesets. You might want to consider using these features in order to write your rulesets in a more efficient way. Handling of non-IPv4 packets ipfw1 will silently accept all non-IPv4 packets (which ipfw1 will only see when net.link.ether.bridge_ipfw=1). ipfw2 will filter all packets (including non-IPv4 ones) according to the ruleset. To achieve the same behaviour as ipfw1 you can use the following as the very first rule in your ruleset: ipfw add 1 allow layer2 not mac-type ip The layer2 option might seem redundant, but it is necessary -- packets passed to the firewall from layer3 will not have a MAC header, so the mac-type ip pattern will always fail on them, and the not operator will make this rule into a pass-all. Address sets ipfw1 does not supports address sets (those in the form addr/masklen{num,num,...} ). Port specifications ipfw1 only allows one port range when specifying TCP and UDP ports, and is limited to 10 entries instead of the 15 allowed by ipfw2. Also, in ipfw1 you can only specify ports when the rule is requesting tcp or udp packets. With ipfw2 you can put port specifications in rules matching all packets, and the match will be attempted only on those packets carrying protocols which include port identifiers. Finally, ipfw1 allowed the first port entry to be specified as port:mask where mask can be an arbitrary 16-bit mask. This syn- tax is of questionable usefulness and it is not supported anymore in ipfw2. Or-blocks ipfw1 does not support Or-blocks. keepalives ipfw1 does not generate keepalives for stateful sessions. As a consequence, it might cause idle sessions to drop because the lifetime of the dynamic rules expires. Sets of rules ipfw1 does not implement sets of rules. MAC header filtering and Layer-2 firewalling. ipfw1 does not implement filtering on MAC header fields, nor is it invoked on packets from ether_demux() and ether_output_frame(). The sysctl variable net.link.ether.ipfw has no effect there. Options The following options are not supported in ipfw1 dst-ip, dst-port, layer2, mac, mac-type, src-ip, src-port. Additionally, the following options are not supported in ipfw1 (RELENG_4) rules: ipid, iplen, ipprecedence, iptos, ipttl, ipversion, tcpack, tcpseq, tcpwin. Dummynet options The following option for dummynet pipes/queues is not supported: noerror. OpenBSD's (Danielt Hartmeier's) pf is really quite neat. Loadable kernel modules aside (yeah yeah, I know the old argument that securelevel is a one-way spinlock, and we've seen the exploits that disprove that), it's well-implemented piece of software. Some of the finer points that really make it nice are the scrubbing features (dealing with duplicate IP fragments with overlapping data), the ability to compensate for weak TCP ISNs when acting as a NATting system, queueing, anchor points for externally generated rules, useful counters.... Rather than go on with glittering generalities, I think I'd like to familiarize myself better with ipfw2 (I haven't looked at it at all, to be honest). Hartmeier's pf has some support for sharing nat and filter states among systems (though I'm not sure how advanced this is at the moment. I think it uses a pseudo device). It can operate in a routing fashion or in a bridging fashion too which is quite handy. Just like Darren Reid's ipf, Hartmeier's pf uses a configuration file (using a yacc parser), as opposed to the ipfw/iptables/ipchains method of using the binary for all configuration -- yes, I've seen the iptables restore format and it's a lot closer to making it maintainable. - -Jeff P.S. I sent in a kernel patch to this list a few days ago and never saw it make the list, is anyone else having problems sending messages to the list? i could've sworn it "ate" one reply that i have yet to see ... P.P.S. I submitted the same patch to Apple's patch form and actually received a bounce! (The submission page is a web form). _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.