Date: Fri, 16 May 2003 12:46:48 -0700 From: "Crist J. Clark" <crist.clark@attbi.com> To: andy@sorted.org Cc: freebsd-ipfw@freebsd.org Subject: Re: Q: ipfw & divert sockets (2nd try) Message-ID: <20030516194648.GD98044@blossom.cjclark.org> In-Reply-To: <19025.217.154.240.18.1052823481.squirrel@radix.sorted.org> References: <19025.217.154.240.18.1052823481.squirrel@radix.sorted.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 13, 2003 at 11:58:01AM +0100, andy@sorted.org wrote:
> Apologies if this is not the place for this question - I worked through
> the list of mailing lists and this seemed the appropriate spot (and
> apologies if you already have this mail from another address - reverse-DNS
> problems).
>
> I've been working to use FreeBSD4.8-STABLE/IPFW2 and a small user-land App
> linked to it via a divert socket, to encapsulate all outgoing data on a
> given interface into a UDP packet stream (and visa versa) - effectively an
> IP-over-UDP tunnel.
>
> The send-side of this seems to work fine - I can send a datagram,
> encapsulate it, and watch it travel over the network. Furthermore, the
> receive side seems to correctly deencapsulate the packet without raising
> an error. However, the deencapsulated packet, which is identical to its
> 'pre-encapsulated' form does not seem to make it out of the diverted
> socket, and appears to be dropped.
>
> Is what I'm doing possible within the IPFW2 framework, or am I trying to
> do something foolish?
> Are inbound packets handled differently to outbound ones?
I wrote some code to do this too. Are you checking the return value of
the sendto(2) that writes the packet back to the divert(4) socket? It
is returning the correct size?
We'll probably need to at least see the firewall rules and likely some
of the source code too to be able to help.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030516194648.GD98044>