From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: netfilter@lists.netfilter.org
Subject: Re: DNAT problem
Date: Mon, 02 Oct 2006 15:14:41 +0200 [thread overview]
Message-ID: <452110C1.2010203@plouf.fr.eu.org> (raw)
In-Reply-To: <20061002120137.GD23849@woyzeck>
Stefan Friedel a écrit :
>
>>OK, SNAT and DNAT do not support multiple --to any more in kernels above
>>2.6.10. But it is unclear to me whether they still support one IP
>>address *range* (with round robin) or only one single IP address.
>
> The range is still accepted as option for iptables 1.3.6, but it has no effect
> with 2.6.17.3 (so I assume that it is indeed the "NAT+round robin" capability
> which has gone in Kernels > 2.6.10/11). It doesn't matter if I use the SAME or
> the DNAT target in PREROUTING -
One question : did you test this from only one single source IP address
of from several source IP addresses ? SAME is designed to always give
the same mapping to a given source address, and it seems that DNAT/SNAT
do the same in kernels >= 2.6.11.
I remember reading something about this in kernel 2.6.11 changelog :
=======================================================================
[PATCH] Remove Randomness in Selecting NAT IP Address
We currently choose a "random" IP address to NAT to, where we have a
range. Martin Josefsson pointed out that he uses the SAME target in
iptables because changing IP addresses breaks Internet banking sites
(among others) which assume the customer will be coming from a
consistent IP address.
In fact, we spend a fair bit of effort trying to balance the number of
connections we NAT to each IP address. We can come pretty damn close
just hashing the source and destination IP addresses, and it has the
consistency property which is so desirable, as well as being faster.
========================================================================
I believe that with this patch the SNAT and DNAT targets behave in a way
like the SAME target and always use the same mapping in the --to range
for a given source IP address. However, when a range is specified,
different sources may use different mappings. But it won't be a dynamic
round robin, just a static hash. However I believe that when there are
many different source addresses it can achieve some kind of load balancing.
>>What about the BALANCE target ? It's in the man page, but I had never
>>heard of it.
>
> In iptables 1.3.6 BALANCE is not available (nor is it available in the 2.6.17.3
> source). Obsolete? And I fear that it would not help, because the problem is
> the missing round robin/load balancing in the Kernel.
I don't think so. Each target has its own code.
next prev parent reply other threads:[~2006-10-02 13:14 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-02 8:00 DNAT problem Stefan Friedel
2006-10-02 8:25 ` Marco Berizzi
2006-10-02 10:42 ` Pascal Hambourg
2006-10-02 12:01 ` Stefan Friedel
2006-10-02 12:51 ` Marco Berizzi
2006-10-02 13:14 ` Pascal Hambourg [this message]
2006-10-02 14:18 ` Stefan Friedel
2006-10-02 16:54 ` Cant find Joel Lindsay
2006-10-03 12:36 ` angico
2006-10-02 12:48 ` DNAT problem Marco Berizzi
[not found] <45227670.8040702@mail.nankai.edu.cn>
2006-10-03 14:48 ` Marco Berizzi
[not found] <4521C6A3.1040902@mail.nankai.edu.cn>
2006-10-03 10:11 ` Marco Berizzi
-- strict thread matches above, loose matches on Subject: below --
2006-07-08 21:00 Antonio Di Bacco
2005-01-22 15:59 dnat problem Pablo Allietti
2005-01-22 19:45 ` Jason Opperisano
2005-01-23 0:26 ` Pablo Allietti
[not found] ` <20050125150114.GA25839@omega.lacnic.net.uy>
2005-01-25 15:24 ` Pablo Allietti
2005-01-25 15:25 ` Pablo Allietti
2004-06-10 11:03 DNAT problem Paul M. Goorskis
2004-05-29 15:25 Patrick Leslie Polzer
2004-05-29 15:36 ` Alexis
2004-05-29 16:03 ` Patrick Leslie Polzer
2004-05-30 1:00 ` Alexis
2004-04-27 5:57 [Fwd: Re: DNAT Problem] test
2004-04-27 7:20 ` DNAT Problem Rob Sterenborg
[not found] ` <1081.80.0.0.23.1083127867.squirrel@80.0.0.175>
[not found] ` <000901c42cef$68603d40$1202a8c0@admin>
2004-05-04 5:32 ` test
2004-04-19 5:07 test
2004-04-19 13:43 ` Joel Newkirk
2004-04-20 4:31 ` test
2004-04-22 10:40 ` test
2004-04-22 11:07 ` Antony Stone
[not found] ` <1589.80.0.0.23.1082637754.squirrel@80.0.0.175>
2004-04-22 12:47 ` Antony Stone
2004-04-22 13:06 ` test
2004-04-22 13:21 ` Antony Stone
2004-04-22 18:18 ` test
2004-04-22 19:13 ` Antony Stone
2004-04-23 12:22 ` test
2003-03-30 14:58 DNAT problem Alexandru Coseru
2003-03-30 15:41 ` Joel Newkirk
2002-11-27 19:28 Geoff Silver
2002-11-19 8:07 HCLFM
2002-11-21 21:53 ` Rahul Jadhav
2002-05-21 20:53 dnat problem support
2002-06-13 17:28 ` Antony Stone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=452110C1.2010203@plouf.fr.eu.org \
--to=pascal.mail@plouf.fr.eu.org \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.