[tproxy] tproxy development version 1.1.3

[KOVACS Krisztian]

   Hi,

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...

-- 
   Regards,
     Krisztian KOVACS