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]

Date:	Sat, 13 Sep 2008 19:55:09 +0100
From:	Graeme Fowler <graeme@...emef.net>
To:	Joseph Mack NA3T <jmack@...d.net>
Cc:	Julius Volz <juliusv@...gle.com>, lvs-devel@...r.kernel.org,
	netdev@...r.kernel.org, j.stubbs@...kthink.co.jp
Subject: Re: Adding SNAT support to LVS/NAT

Hi

On Sat, 2008-09-13 at 11:17 -0700, Joseph Mack NA3T wrote:
> when we've discussed it before, the packets will appear to 
> come from the DIP, a private IP (or whatever IP the servers 
> were using for their default route before they were put into 
> an LVS).

I'm a bit late to the party, but...

Ideally, the packets would appear to come from the "inside face" of the
director - usually (and in the most basic case) the NIC with an address
on the same layer 3 network as the real servers. This way the default
route would be ignored as there would normally be a more specific route
for that network, namely straight out of the device the packets arrived
on. Of course, if that coincides with the default gateway address, it'll
still work anyway.

> more importantly, people who are bound by serious IT rules 
> setup by managers, can duplicate their (real) servers only 
> with a change in RIP on each server and can keep the default 
> route.

This is the single most compelling thing about this setup.

It's simultaneously a problem in that for (say) an HTTP server, all the
requests will appear to be sourced from the director's internal address.
For many applications this won't be acceptable, not least in that for
the webserver case log processing will be an irrelevance!

Anyone know how the F5 hardware gets around this? I can't get my hands
on any to test...

Graeme

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