[tproxy] Fwd: Tproxy changes for performing dual NAT

[Arun S]

In solution 2, instead of going for sockref and by making the foreign
address persistent till the connection ends (using socket marking),
this issue could be resolved.

Please correct me if I am wrong.

On 20/11/2007, Arun S <hi2arun at gmail.com> wrote:
> 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.
>


-- 
Regards,
Arun S.