[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.58.0809160103160.3009@u.domain.uli>
Date: Tue, 16 Sep 2008 01:56:31 +0300 (EEST)
From: Julian Anastasov <ja@....bg>
To: Julius Volz <juliusv@...gle.com>
cc: Joseph Mack NA3T <jmack@...d.net>, lvs-devel@...r.kernel.org,
netdev@...r.kernel.org, j.stubbs@...kthink.co.jp
Subject: Re: Adding SNAT support to LVS/NAT
Hello,
On Sun, 14 Sep 2008, Julius Volz wrote:
> > Thanks for the info! Right, I even said myself in the previous reply
> > that ip_vs_postrouting() stops further processing in the POSTROUTING
> > chain, so it never reaches netfilter NAT code.
>
> Actually, what if we modify or remove that function to allow further
> processing in POSTROUTING? Could SNAT work with IPVS then?
>
> The comment above it says that the function specifically wants to
> avoid further NAT by netfilter. But is this always a problem?
This check (now flag ipvs_property) was implemented to avoid
netfilter to modify packet which was already changed by IPVS.
What happened was that FTP commands (TCP header and payload) were
modified first by ip_vs_ftp and then by netfilter. The result:
packet with wrong SEQ number. Later, after some Netfilter
changes (2.6.11), TCP payload was modified always in POST_ROUTING
while address can be modified in PRE_ROUTING. Not sure what happens
now, Netfilter code was reorganized and new code review and tests
are needed, may be such double manipulation (if ipvs_property is
not set) still can cause problems.
Regards
--
Julian Anastasov <ja@....bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists