[tproxy] socket match can't work with DNAT rules

[Arun Srinivasan]

With the tproxy server as given in my scenario, I have a lot of
flexibilities:
1. The high-end caching (tproxy) server can offer thro'put advantages.
2. Original IP of the clients can be retained thro' tproxy support
3. Another IP based traffic identification/metering mechanism can sit
between comp/tunneling-agent2 and the web server and monitor the traffic.

whereas in the conventional scenario suggested by you, point # 2 and # 3
would fail.

Tproxy4 socket is not a secure tunnel like that of IPSec to prevent DNATs
from happening.

IMHO, I feel that the tproxy-local DNAT issue is a kind of restriction in
the name of a new feature.



2008/12/16 Balazs Scheidler <bazsi at balabit.hu>

> On Tue, 2008-12-16 at 10:46 +0530, Arun Srinivasan wrote:
> > Hi,
> >
> > Balazs comment 1:
> > "You cannot use DNAT and tproxy on the same connection. What do you
> > want
> > to achieve?"
> >
> > This is a common scenario. Say you have an intermediate compression
> > agent/tunneling agent between the tproxy server and the web server as
> > shown below:
> >
> > Client <--------> tproxy server <---------> compression/tunneling
> > agent1 <=============> compression/tunneling agent2
> > <------------------> web server
> >
> > In this case, the output from the tproxy server has to be DNATted or
> > policy routed to the compression/tunneling agent. Policy routing is
> > possible if the compression/tunneling agent lies outside the box. In
> > case, if it runs as another process along with the tproxy server, DNAT
> > is the only option, AFAIK.
> >
> > Balazs comment 2:
> > "If you want to change the target address of the server side
> > connection,
> > why don't you DNAT the server connection? That should work."
> >
> > Not able to understand what you exactly mean by "DNAT the server
> > connection".
> >
> > If my understanding is correct, Tproxy association is only for the
> > socket created between client and the tproxy server. If that is the
> > case, why does socket match failure happen for the socket created
> > between tproxy server and DNAT server?
>
> No, tproxy _may_ operate for both the client->tproxy and the
> tproxy->server connections, not just between client & tproxy.
>
> However, you're right that tproxy does not support redirecting the
> traffic if the upstream for tproxy is running on the same box, the
> reason is simple, tproxy also uses routing to direct traffic to a local
> process, and it is not currently possible to divert outgoing traffic
> back to the input interface. but never mind.
>
> So in the scenario above, what is the added value of using "tproxy"
> instead of plain, simple NAT.
>
> client -> REDIRECT in nat/PREROUTING -> proxy1 -> DNAT in nat/OUTPUT ->
> compression/tunneling agent1 <-> compression/tunneling agent2 ->
> webserver
>

>
> the added value of tproxy over using NAT is increased performance (no
> NAT is required) and solving the problems related to the conntrack table
> and local IP stack state to get out of sync.
>
>
>
> --
> Bazsi
>
>
>


-- 
Regards,
Arun S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/tproxy/attachments/20081216/2c435640/attachment.htm