netdev - Re: Adding SNAT support to LVS/NAT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080915014337.GA10026@verge.net.au>
Date:	Mon, 15 Sep 2008 11:43:39 +1000
From:	Simon Horman <horms@...ge.net.au>
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,
	Siim Põder <siim@...rad-teel.net>
Subject: Re: Adding SNAT support to LVS/NAT

On Sun, Sep 14, 2008 at 04:47:51PM +0200, Julius Volz wrote:
> On Sun, Sep 14, 2008 at 12:39 PM, Julius Volz <juliusv@...gle.com> wrote:
> > On Sun, Sep 14, 2008 at 3:37 AM, Joseph Mack NA3T <jmack@...d.net> wrote:
> >> On Sun, 14 Sep 2008, Julius Volz wrote:
> >>
> >>> So maybe it would already work? ;)
> >>
> >> No. Some highly motivated people tried doing SNAT on OUTPUT in an attempt to
> >> do F5-SNAT and it didn't work. This lead to the write up in
> >>
> >> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.non-modified_realservers.html#F5_snat
> >>
> >> which brings us to where we are now.
> >
> > 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?

Well, it would be a problem if it gets DNATed a second time.
But perhaps we can take a slightly different approach such that
we protect against DNAT while allowing SNAT.


Perhaps it might just be easier to allow iptables to explictly match
packets that have been mangled by LVS-NAT. Perhaps by poviding
a match rule for skb->ipvs_property? Or by using Siim Põder's match
against connections in the LVS connection table.

http://lists.graemef.net/pipermail/lvs-users/2008-July/021081.html

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

--
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