RE: lvs-nat & SNAT

To: Rodger Erickson <rerickson@xxxxxxxxxxxx>
Subject: RE: lvs-nat & SNAT
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Tue, 29 Jan 2002 22:04:57 +0000 (GMT)

On Tue, 29 Jan 2002, Rodger Erickson wrote:

>       After looking through your situation below, I believe that this
> would work properly if you removed the post_routing hook from ip_vs_conn.c
> (or did some #ifdef'ing to replace the contents of the existing hook with
> "return NF_ACCEPT").
>       This way your packets could continue through the netfilter mechanism
> and be SNAT'd properly.

        They are already SNAT-ed from LVS.

>       I don't think that routing is an issue with SNAT if all you want to
> do is masquerade the source address to force responses to come back through
> a particular (and thus the correct route is the one you would have used
> anyway).

        The NAT fails with multipath routes on route cache flush

>       As a caveat, I'm not 100% certain why the ip_vs_post_routing()
> routine was put there (and what things would break by effectively removing
> it).  It seems to me that all it's doing is preventing conntrack entries
> from being created for packets leaving the box.  While this is a good thing
> under most circumstances, it is certainly undesireable for your situation.

        LVS does not touch the netfilter's conntrack packets,
they reach unchanged post_routing where they can be SNAT-ed
if such manipulation is scheduled from netfilter.

        As for the LVS in->out NAT traffic, it is SNAT-ed at
FORWARD and don't reach ip_nat_out. This is the goal we achieve
by using ip_vs_post_routing.

>       Can one of the core LVS guys tell me if I'm missing something here?
> I've done something similar to what I've described above and it seems to
> work great for me in my environment.
>       Rodger Erickson


Julian Anastasov <ja@xxxxxx>

<Prev in Thread] Current Thread [Next in Thread>