[tproxy] tproxy development version 1.1.3

Tim Burress hokousha2001@yahoo.com
Tue, 4 Nov 2003 19:39:52 -0800 (PST)


As an example, consider a firewall machine with
interfaces to the usual public, DMZ, and local
networks. Proxy programs are used to monitor traffic
like SMTP or POP to scan for viruses and other
undesirables. The original proxy code used REDIRECT
rules to intercept connections, and opened independent
sessions between the client-proxy and proxy-server.
Just what you'd expect, but without tproxy it is not
transparent, and this causes application layer

So we add tproxy, and inbound SMTP works like a charm.
The internal server sees the connection as if it
originated from the actual client, which is just what
we'd hoped for.

The trouble comes with outgoing SMTP from the local
network. If these hosts use private addresses, then
when tproxy is used, the outside server sees the
traffic as originating from the unroutable private
address, which would normally have been masqueraded at
the firewall. As a result, all outbound connections

One solution would be to modify the proxy so that it
decides whether to be transparent or not based on the
direction of traffic, and that would work fine in
fixed, simple cases, but since firewall rules can
become arbitrarily complex, it seems like it would be
better to find a solution within iptables. One idea
might be to incorporate the TPROXY rules into the
existing NAT chains, so that transparency could be
invoked or not depending on the order in which the
rules appeared. You could mix REDIRECT, TPROXY, and
other NAT rules as needed in order to produce the
desired behavior. As it is, tproxy always takes
precedence, which eliminates a lot of control,
especially in complex networks.

I realize you went to a lot of trouble to keep the
tproxy rules separated, so I wondered if you had a
better workaround for this kind of situation?


--- Balazs Scheidler <bazsi@balabit.hu> wrote:
> On Mon, Nov 03, 2003 at 10:58:40PM -0800, Tim
> Burress wrote:
> > Hi Krisztian,
> > 
> > So does this interaction with the NAT tables
> explain
> > why IP masquerade rules are being ignored when a
> > connection is tproxied? I wonder if there is a
> good
> > way around that?
> definitely, if you have a matching TPROXY rule it
> will never even enter the
> NAT table. What do you want to accomplish? If a
> TPROXY rule is matched the
> connection will be processed by a userspace proxy,
> there's no point in masquerading.
> -- 
> Bazsi
> PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C
> 0944 9CFD 804E C82C 8EB1

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard