I have been using transparent proxies on Linux for a long time, very
possibly longer than anyone else, since I wrote a extremely crude hack
that served me well back 1995.
I mean, I am very fond of transparent proxies and I do things with
them that are extremely difficult to achieve at the kernel level. I
also think I am pretty much aware of their problems and limitations
and, thus, resort to other techniques here and there. But I use
proxies everytime unless I cannot afford them.
Most people think of transparent proxies as programs that just catch
connections and redirect them to other places. That's good and it is
what Squid does, it just pretends to be the server to the client and
completes the service somehow.
But I also have scenarios where I absolutely need to pretend both to
be the server to the client and the client to the server. That means
I need to create a socket, bind to it with a foreign address and
connect it to somewhere else. A common use for this is the
transparent stunnel. If the illusion is not preserved, the server
gets no idea of the origin and thus, cannot use it for authorization
or audit. Even not so long ago, I had something like this as a part
of a pop-before-smtp setup where this working was critical.
This mechanism has worked since I originally wrote my kludge up to
2.2.x but, from what I can gather, it does not work anymore in 2.4.x.
Could someone explain to me what was the rationale for dropping this?
Is it incompatible with the deep magic in netfilter? Was it declared
"evil" or something? Or was it simply that no one needed it and was
lost in the rewrite until someone steps forward?
In the same line, how much effort would it entail to write the code to
put it back? And, finally, are there philosophical problems that
would make it unacceptable for the standard kernel?
Thanks in advance,
Julio
On 25 Jul 2001 21:09:13 +0200 Julio Sanchez Fernandez <[email protected]> wrote:
JSF>
JSF> I have been using transparent proxies on Linux for a long time, very
JSF> possibly longer than anyone else, since I wrote a extremely crude hack
JSF> that served me well back 1995.
JSF> This mechanism has worked since I originally wrote my kludge up to
JSF> 2.2.x but, from what I can gather, it does not work anymore in 2.4.x.
Hello,
I don't know if it is useful for you, but http://www.mcknight.de/jftpgw
supports transparent proxy for Linux 2.4.x kernel.
BTW, do you know of any port forwarder which works with 2.4 kernel in
transparent mode? I tried mmtcpfwd and portfwd, but both do not work.
Regards,
Nerijus
On Thursday 26 July 2001 22:15, Nerijus Baliunas wrote:
> On 25 Jul 2001 21:09:13 +0200 Julio Sanchez Fernandez <[email protected]>
> wrote:
>
> JSF>
> JSF> I have been using transparent proxies on Linux for a long time, very
> JSF> possibly longer than anyone else, since I wrote a extremely crude hack
> JSF> that served me well back 1995.
>
> JSF> This mechanism has worked since I originally wrote my kludge up to
> JSF> 2.2.x but, from what I can gather, it does not work anymore in 2.4.x.
>
> Hello,
>
> I don't know if it is useful for you, but http://www.mcknight.de/jftpgw
> supports transparent proxy for Linux 2.4.x kernel.
>
> BTW, do you know of any port forwarder which works with 2.4 kernel in
> transparent mode? I tried mmtcpfwd and portfwd, but both do not work.
Well, for simple forwarding within the box I'm using:
iptables -t nat -A PREROUTING -p tcp -i eth1 -d 10.0.0.0/8 -j REDIRECT
--to-port 3141
That's to forward an all ports for a given address range (anything in the
10.x.x.x subnet in this case) to a daemon on the box itself. I don't
remember if it winds up on eth1 or on loopback (where said daemon should
bind), probably eth1. The magic snippet of C code that can recover the
original destination address and port for a forwarded connection is:
getsockopt(connection_fd,SOL_IP,SO_ORIGINAL_DST, &addr, &i);
(Finding out the above involved thumbscrews, a bullwhip, google, a lot of
luck, and emailing various developers. But I sent it off to the man page
maintainer so hopefully it should be better documented now.)
To forward a port outside the box entirely, the mystic iincantation is:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport "$fromport" --j DNAT
--to "$addr":"$toport"
fromport being the port on the firwall (I.E. 80), addr and toport being the
remote machine's IP address and the port number on that remote machine
(hopefully one behind your firewall, although that's probably not a
requirement).
Is that what you needed?
> Regards,
> Nerijus
Rob
Nerijus Baliunas <[email protected]> writes:
> On 25 Jul 2001 21:09:13 +0200 Julio Sanchez Fernandez <[email protected]> wrote:
>
> JSF> This mechanism has worked since I originally wrote my kludge up to
> JSF> 2.2.x but, from what I can gather, it does not work anymore in 2.4.x.
>
> Hello,
>
> I don't know if it is useful for you, but http://www.mcknight.de/jftpgw
> supports transparent proxy for Linux 2.4.x kernel.
Only impersonating the server. What does not work is impersonating
the client and that cannot be fixed from user space.
> BTW, do you know of any port forwarder which works with 2.4 kernel in
> transparent mode? I tried mmtcpfwd and portfwd, but both do not work.
Anyone that used TCP and worked before should be easy to adapt by just
finding where it got the destination address with getsockname and
using the getsockopt with SOL_ORIGINAL_DST thing. Apparently, UDP is
out as well, though I don't care about that currently.
Add to your list more forwarders like transproxy and those (plug-gw in
particular) in the TIS (NAI) FWTK with the transparency patches
described at http://www.fwtk.org
While none of them has been adapted to 2.4, they should be easy as I
said above.
And as long as you don't care what origin address the server sees,
that's alright. But all connections now seem to come from the proxy.
And that does not let you do things like differentiated services,
access control or audit. Even user support becomes a mess.
Julio
On 27 Jul 2001 09:16:58 +0200 Julio Sanchez Fernandez <[email protected]> wrote:
JSF> > I don't know if it is useful for you, but http://www.mcknight.de/jftpgw
JSF> > supports transparent proxy for Linux 2.4.x kernel.
JSF>
JSF> Only impersonating the server. What does not work is impersonating
JSF> the client and that cannot be fixed from user space.
JSF>
JSF> > BTW, do you know of any port forwarder which works with 2.4 kernel in
JSF> > transparent mode? I tried mmtcpfwd and portfwd, but both do not work.
JSF>
JSF> Anyone that used TCP and worked before should be easy to adapt by just
JSF> finding where it got the destination address with getsockname and
JSF> using the getsockopt with SOL_ORIGINAL_DST thing. Apparently, UDP is
JSF> out as well, though I don't care about that currently.
JSF>
JSF> Add to your list more forwarders like transproxy and those (plug-gw in
JSF> particular) in the TIS (NAI) FWTK with the transparency patches
JSF> described at http://www.fwtk.org
JSF>
JSF> While none of them has been adapted to 2.4, they should be easy as I
JSF> said above.
JSF>
JSF> And as long as you don't care what origin address the server sees,
JSF> that's alright. But all connections now seem to come from the proxy.
JSF> And that does not let you do things like differentiated services,
JSF> access control or audit. Even user support becomes a mess.
Do you mean that even if I adapt them as you say, the receiving end will see
connection orriginating from the proxy instead of the real address?
I'm asking as these 2 port forwarders I tried work with 2.4 kernel in non-transparent
mode, i.e. connections seem to come from the proxy, what I need is connection
to be seen to come from real originating IP.
Regards,
Nerijus