Todd writes thusly:

-> On Fri, 17 Sep 1999, vianney rancurel wrote:
-> 
-> : A---->B---->C
-> : 
-> : A is an internal host, B is a NetBSD box with two NICs, C is the 
-> : destination host. A has got a default route to B. He wants to 
-> : "telnet" C. He just send packets following routing table and 
-> : B "hijacks" the connection. C sees B making the connection but 
-> : A believes is directling talking to C.
-> 
-> This is called NAT.  See ipnat(4).

While NAT may achieve similar ends, this was not the question.  NAT just
rewrites header addresses.  A transparent proxy will understand the specific
protocol and can do many things simple NAT cannot (access control, rewriting
addresses in protocol data/commands, enforcing correct protocol semantics,
yadda, yadda, yadda).  Can you tell what I do for my day job? 8-)

That said, there is a way to do what Vianney wants without adding a "proxy"
rule.  There are patches that allow the TIS FWTK to act as a transparent
proxy in conjunction with IPFilter.  If you're proxying for services the
proxy machine isn't provided, this is easy to do.... Otherwise, you need some
port redirection tricks so that you can talk to both the telnet proxy on
the proxy box and the local telnet daemon.

I'm sorry I don't have references to where you can find those patches for
the FWTK, but a search through the IPFilter mailing lists should get you
something.  I had started implementing this on my home router (which is
just a NetBSD box) over a year ago, but didn't have the time to finish it 
and ended up using NAT instead, since almost all traffic flows out->in 
anyway and I wasn't that concerned about fine-grained access controls or
protocol verification.  I may still get around to doing this for FTP, as
the in-kernel IPFilter FTP proxy is far from perfect.

--rafal

----
Rafal Boni                                                  rafal@mediaone.net