On Tue, 2007-11-20 at 12:17 +0100, KOVACS Krisztian wrote:
Hi,
On k, nov 20, 2007 at 11:33:53 +0100, Balazs Scheidler wrote:
On Mon, Nov 19, 2007 at 07:04:14PM +0530, Arun S wrote:
Any updates on the SNAT issue with tproxy4 related to sockets?
I'm just working on that issue. I hope I'll be able to finish it this evening, or maybe tomorrow.
And what is your solution? I was thinking about something like a "natsocket" match, but that looks ugly.
I've discussed this with Patrick and we have basically two options:
* to use the original source address for SNAT-ted connections (I don't think we'd need a separate match: I guess using the SNAT-ted address in the socket match is absolutely useless);
Yeah, but in that way the "socket" match would pull in the dependency on the NAT module unconditonally.
* to re-introduce the tproxy table and do the socket matching and marking in tproxy.
The first option seems pretty ugly and could work for SNAT but does not solve the problem with DNAT: we have the same incompatibility with nat/PREROUTING DNAT rules at the moment.
The second one is a step backwards and would break our 'user interface' _again_ (sigh), but I tend to think that it is the only correct solution...
I see. -- Bazsi