Subject: Re: Transparent Proxying
To: Matthew Mondor <>
From: Lord Isildur <>
List: tech-kern
Date: 05/14/2002 10:16:32
it wouldnt be difficult to do, especially if it was strictly a packet 
forwarder. Rewrite the src address, recompute the checksum, and dump it 
back on the wire. you can do it pretty easily with a small program that
just reads frames out from bpf and sticks them back on with bpf as well, 
so you do it easily in userland, and the checksums are very simple.. 

If you can wait a month or two til the next revision 
is done (the first version is being hastily finished to meet the paper 
deadline, but it's gotten pretty kludgy by now :), youll be able 
to download a copy of some stuff im working on which will do as a small 
subset of its capabilities exactly what you want. it's basically a 
network proxy that can transparently rewrite traffic, match based on some
reasonably complex filter rules subscribable by a userland process, have
such processes decide the fate of traffic, put it back on the network 
possibly rewritten, and tap data out of the network stack anywhere you 
want it. The pain is that i'm doing this for tcp as well.. doing 
arbitrary rewriting of a tcp stream as it goes by is fun, but there are lots
of little gotchas and it's made for a lot of late nights.. :) 
When the thing is running you dont know its there, ethernet frames go in one
side and come out the other, and without some out of band communication, 
neither side of the traffic can tell (unless its doing some very smart 
things with a lot of guessing and statistics) that its being diddled with
in the middle.


On Tue, 14 May 2002, Matthew Mondor wrote:

> Sorry for my last post which had unwrapped lines, so I am resending it
> with a better formatting now:
> Hi all,
> Is there a userspace facility on NetBSD which allows a TCP proxy daemon to
> spoof the source address for the life of a TCP connection to that of the
> actual internet client when connecting from a gateway to an internal
> service? This way the internal machine would see the connection as
> originating from the client rather than from the proxy gateway.
> I have looked into ipnat, but this would not seem to solve the issue at
> hand, I previously wrote an FTP passive proxy (mmtcpfwd) which requires
> this feature, it currently works on Linux but I would like to port it to
> NetBSD...
> A possibly viable method seems to be running part of the system as uid 0
> so that interaction with the kernel would occur frequently to forward
> ports, using the same techniques which ipnat and/or ipf are using... Is
> there any other known solution?
> Matt