Re: [tproxy] proxy app and server app on the same host

19 Jan 2015

      I did some experimenting:

Flow-Analysis of SYN+ACK in iptables tables
SYN+ACK (sent by server app as step 2 of the 3-way-handshake):

  1) Connect by remote client to proxy server, server app is on other host in LAN:
  STATUS: OK
    mangle  : PREROUTING INPUT
    filter  :            INPUT
    nat     :
    raw     : PREROUTING
    security:            INPUT

  2) Connect by local client to proxy server, server app is on other host in LAN:
  STATUS: OK
    mangle  : PREROUTING INPUT
    filter  :            INPUT
    nat     :
    raw     : PREROUTING
    security:            INPUT

  3) Connect by remote client to proxy server, server app is on same host (ip 
same or different):
  STATUS: FAIL
    mangle  :                  OUTPUT POSTROUTING
    filter  :                  OUTPUT
    nat     :
    raw     :                  OUTPUT
    security:                  OUTPUT

  4) connect by local client to proxy server, server app is on same host (ip 
same or different):
  STATUS: OK
    mangle  : PREROUTING INPUT OUTPUT POSTROUTING
    filter  :            INPUT OUTPUT
    nat     :
    raw     : PREROUTING       OUTPUT
    security:            INPUT OUTPUT

It is the 3rd case which doesn't work ("FAIL").
My interpretation for the cause of the error is as follows:
the routing decision seems to be done only in the PREROUTING chain,
but not in POSTROUTING, because otherwise it would work.
To me it seems impossible to fix this via some clever iptables rules,
I think this can be fixed only by patching the kernel.

Any thoughts or further ideas for fixing the 3rd case above?

Regards,
U.Mutlu

U.Mutlu wrote, On 01/18/2015 06:44 PM:
...
Scheidler, Balázs wrote, On 01/18/2015 07:49 AM:
...
The problem is that the synack in response to the syn goes out to the
internet towards the faked IP address, and not back to the loopback
interface.
The problem is that the same return traffic is used by the client side of
the proxy as well.
So if you have a means to differentiate the two (match on the process
somehow for example), then use that to mark server side packets, and then
have routing tables that enforfes these packets to be delivered locally
would work.
Yes, that makes sense and at first look it seems to be easy to do.
I'll have to experiment, but if you, or anybody else, have already
done this successfully I would be happy to see your solution.
But I think a more general and user-friendly solution would be
if that fix could be implemented into the kernel where the routing decision is
made, isn't it?
Thx
Uenal