[tproxy] Fwd: Tproxy changes for performing dual NAT

[Arun S]

Hi,

In the case of solution 2 (i.e, going for tproxy table and using
sockref), maintaining the foreign address in conntrack for the whole
session is mandatory.

If the foreign address is deleted from conntrack, once a "confirmed"
call from Conntrack is received, then it is difficult to handle
mangling of packets in POSTROUTING chain based on foreign address.


On 20/11/2007, KOVACS Krisztian <hidden at sch.bme.hu> wrote:
> Hi,
>
> On k, nov 20, 2007 at 12:23:25 +0100, Balazs Scheidler wrote:
> > > > > 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.
>
> Not necessarily: that part could be enclosed by #ifdef CONFIG_NF_NAT
> guards.
>
> > > * 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.
>
> Erm, more feedback would be really reassuring... ;)
>
> --
> KOVACS Krisztian
>


-- 
Regards,
Arun S.