[tproxy] tproxy development version 1.1.3
Wed, 05 Nov 2003 15:50:19 +0100
Tim Burress wrote:
> 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.
So, to summarize: you have such a config that the firewall does SNAT
only part of the traffic, packets coming from routable IP addresses should
be left intact. However, your proxy tries to forge original sender
addresses, and because of when tproxy is used, the NAT table is not
consulted, the private IPs of the non-routable subnet are forwarded.
Unfortunately, as Balazs already pointed out, using MASQ and tproxy
does not mix, and it won't help if you move your TPROXY rules to anywhere.
The 'tproxy' iptables table is only part of the game, but tproxy _does_
apply NAT mapping even when that table is completely empty, but you have
assigned a foreign address from your proxy software (using setsockopt). In
fact, in the tproxy hook, the 'tproxy' table is consulted only if such an
assigned address is not found for the socket. And once tproxy has assigned
a mapping for the connection, the 'nat' table (which is checked after
tproxy has done its work) is not traversed at all.
What could the solution be? Currently I don't see an easy solution for
modifying tproxy to be able to do MASQ also, so your problem should be
worked around on a userspace level. But instead of proxy-level logic to
decide if you have need transparency, you could classify your traffic
using iptables rules, and forward the routable and non-routable part to
two separate proxies. The traffic coming from routable addresses should be
processed by the transparent proxy, all other traffic should go the the
not transparent one. (I really don't know your environment, but I can't
currently think of a problem why you couldn't run more instances of your
proxy with different configuration.) This way, the decision layer for
transparency is in your iptables ruleset, and apart from having to run two
sets of proxies, I think it's a rather straightforward configuration.
(And, it's a cleaner solution, since you don't do address manipulation
twice: once to change the local source address to the original source, and
then to change the original to the NAT-ted...)
Of course, separating the proxy and the packet filter machine could
also solve your problem...