Date: Wed, 15 Dec 99 22:11:02 PST From: Ken Harrenstien <klh@netcom.com> To: freebsd-net@freebsd.org Cc: klh@netcom.com Subject: ipfw feature requests Message-ID: <CMM.0.90.4.945324662.klh@netcom3.netcom.com>
next in thread | raw e-mail | index | archive | help
Trying this list because I'm not sure whether the bug report mechanism
should be used for feature requests...
IPFW is an amazingly useful and impressive piece of work.
Nevertheless, while wrestling a bit trying to write a new ruleset for
a 4-interface (!) firewall/gateway, I came up with the following
wishlist. A cursory inspection of netinet/ip_fw.c suggests that these
might be possible to implement without too much pain, if TPTB decide
they are worthy...
[1] Provide some way to easily match packets that originate from or
are destined for the local host, regardless of the IP address.
Some approaches:
[a] Add "local" as an acceptable keyword for <src> or <dst>.
Thus "deny all from not local to local" suppresses attempts to contact
the gateway as a host, while allowing packet forwarding to continue.
[b] Add "local" as a pseudo-interface name, to match packets that have
no interface. Thus "out recv local" would match packets
originating from the local host. I wish this could also be used
to catch packets destined for the local host, but unfortunately
"in xmit local" won't work as "xmit" can only be used/checked with
"out" packets, sigh...
[c] Allow boolean negation of each interface specification; then you can
say "not any" which would be synonymous with "local" per [b].
Note that this feature would be very handy in general as it can
be used with all of the existing interface specs.
[2] Add a keyword such as "unreg" or "rfc1918" for <src> and <dst>
that would refer to all RFC1918 "unregistered" addresses, specifically
10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. (NATD has something
like this, by the way.)
[3] Consider allowing more negation possibilities in general, e.g. for <proto>
and <ifc> as well as <src> and <dst>. <ports> and some of the
options might also be candidates, but I realize this could get
out of hand. "not <ifc>" per [1c] would be the most useful for me.
Obviously none of these add new capabilities per se; they would just
reduce the number of rules necessary (and thus gain a slight measure
of both efficiency and clarity).
If these suggestions would be better sent somewhere else, just let me
know where.
Thanks!
--Ken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CMM.0.90.4.945324662.klh>