Date: Wed, 14 Aug 1996 20:44:34 -0700 From: Julian Elischer <julian@whistle.com> To: "Daniel O'Callaghan" <danny@panda.hilink.com.au> Cc: Darren Reed <avalon@coombs.anu.edu.au>, sos@freebsd.org, jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: ipfw vs ipfilter? Message-ID: <32129D22.2C67412E@whistle.com> References: <Pine.BSF.3.91.960815085015.6553C-100000@panda.hilink.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel O'Callaghan wrote:
>
> On Thu, 15 Aug 1996, Darren Reed wrote:
>
> > In some mail from Julian Elischer, sie said:
> > >
> > > sos@freebsd.org wrote:
> > > >
> > > > In reply to Jordan K. Hubbard who wrote:
> > >
> > > > I'm all for it !!
> > > > It leaves the question what to do with julian's redirect code ??
> >
> > I've been unwilling to join this conversation, but here I have to ask;
> > what does "divert" do ?
>
> In fact the divert functionality is already in ipfilter. It simply takes
> a packet and diverts it to a nominated interface (e.g. tun0) rather than
> allowing it to pass through the normal routing tables.
No, that isn't quite what divert does..
divert is a bit more powerful than that
it uses a divert socket type to pass the packets up to the user.
this allows other info to be passed as well..
the main difference is that you can using the divert socket, re-inject the packet
back at the point that it was taken out, and control to a greater extent what
happens to it..
divert sockets are an experiment which may or may not survive
but we have found that they allow us to do things that we couldn't do
using the tunnel interface.
firstly sockets are inherrently packet oriented, so
you can do 'sendto' on them for example to give different
sematics to what happens to the packet after re-injection.
there are other problems that are solved by this approach.
we looked at tun interfaces and decided that it was banging a square
peg into a round hole.
each divert socket can be bound to a differnt port, so you can divert different
packets to different sockets (with tun, how do you do that?)
the man page follows:
DIVERT(4) FreeBSD Programmer's Manual DIVERT(4)
NAME
divert - kernel packet diversion mechanism
SYNOPSIS
#include <sys/socket.h>
#include <netinet/in.h>
int
socket(PF_INET, SOCK_RAW, IPPROTO_DIVERT)
DESCRIPTION
Divert sockets are similar to raw IP sockets, except that they can be
bound to a specific divert port via the bind(2) system call. The IP ad-
dress in the bind is ignored; only the port number is significant. A di-
vert socket bound to a divert port will receive all packets diverted to
that port by some (here unspecified) kernel mechanism(s). Packets may
also be written to a divert port, in which case they re-enter kernel IP
packet processing.
Divert sockets are normally used in conjunction with FreeBSD's packet
filtering implementation and the ipfw(8) program. By reading from and
writing to a divert socket, matching packets can be passed through an ar-
bitrary ``filter'' as they travel through the host machine, special rout-
ing tricks can be done, etc.
READING PACKETS
Packets are diverted either as they are ``incoming'' or ``outgoing.''
Incoming packets are diverted after reception on an IP interface, whereas
outgoing packets are diverted before next hop forwarding.
Diverted packets may be read unaltered via read(2), recv(2), or
recvfrom(2). In the latter case, the address returned will have its port
set to the divert port and the IP address set to the (first) address of
the interface on which the packet was recieved if the packet was incom-
ing, or INADDR_ANY if the packet was outgoing.
WRITING PACKETS
Writing to a divert socket is similar to writing to a raw IP socket; the
packet is injected ``as is'' into the normal kernel IP packet processing
and minimal error checking is done. Packets are written as either incom-
ing or outgoing: if write(2) or send(2) is used to deliver the packet, or
if sendto(2) is used with a destination IP address of INADDR_ANY, then
the packet is treated as if it were outgoing, i.e., destined for a non-
local address. Otherwise, the packet is assumed to be incoming and full
packet routing is done.
In the latter case, the IP address specified must match the address of
some local interface. This is to indicate on which interface the packet
``arrived.''
Normally, packets read as incoming should be written as incoming; simi-
larly for outgoing packets. When reading and then writing back packets,
passing the same socket address supplied by recvfrom(2) unmodified to
sendto(2) simplifies things.
LOOP AVOIDANCE
To avoid having a packet sent from a divert socket rediverted back to the
same socket, use the sendto(2) system call supplying any non-zero desti-
nation port number. This indicates to ipfw(8) and other diverting mecha-
nisms to not divert the packet back to the same socket it was written
from.
Since ipfw checks incoming as well as outgoing packets, a packet written
as incoming may get checked twice. Loop avoidance will be enabled for
both checks.
DETAILS
To enable divert sockets, your kernel must be compiled with the option
IPDIVERT.
If a packet is diverted but no socket is bound to the port, or if
IPDIVERT is not enabled in the kernel, the packet is dropped.
Incoming packet fragments which get diverted are fully reassembled before
delivery; the diversion of any one fragment causes the entire packet to
get diverted. If different fragments divert to different ports, then
which port ultimately gets chosen is unpredictable.
Packets are recieved and sent unchanged, so all header fields are in net-
work order. Minimal sanity checking of transmitted packets is done so
length and checksum fields should be pre-computed, with the exception
that packets written as outgoing will have their IP header checksums
overwritten with the correct value. Packets written as incoming and hav-
ing incorrect checksums will be dropped.
Binding to port numbers less than 1024 requires super-user access.
ERRORS
Writing to a divert socket can return these errors, along with the usual
errors possible when writing raw packets:
[EINVAL] The packet had an invalid header, or the IP options in the
packet and the socket options set were incompatible.
[EADDRNOTAVAIL]
The destination address contained an IP address not equal
to INADDR_ANY that was not associated with any interface.
SEE ALSO
ipfw(8), socket(2), bind(2), sendto(2). recvfrom(2),
BUGS
This is an attempt to provide a clean way for user mode processes to im-
plement things like address translation, but it's not that clean and it's
too dependent on ipfw(8).
It's questionable whether incoming fragments should be reassembled before
being diverted. If some fragments don't get routed through the local ma-
chine, the packet is lost.
AUTHOR
Archie Cobbs <archie@whistle.com>, Whistle Communications Corp.
BSD June 18, 1996 2
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32129D22.2C67412E>