From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pascal Hambourg Subject: Re: Logging NAT Translations Date: Fri, 08 Jun 2007 00:36:31 +0200 Message-ID: <4668886F.6080800@plouf.fr.eu.org> References: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="iso-8859-1"; format="flowed" To: netfilter@lists.netfilter.org Hello, Jan Engelhardt a =E9crit : > >>>iptables -t nat -A ydm1 -j LOG "[Adress got SNATed to 134.76.13.21] " >>>iptables -t nat -A ydm1 -j SNAT --to 134.76.13.21 >>> >>>It already was a complete example. When you SNAT, you know you do. Not always. - A NAT may fail due to a conflict with an existing mapping, so you=20 believe you SNAT but actually don't. However I do admit that this=20 situation is unlikely to happen when you don't retrict the port range in=20 the SNAT target. - Implicit SNAT may be performed to avoid conflict with an existing=20 rule, so you SNAT but do not know you do. > I rarely need ranges, mostly because it does not RR over > them like I thought it does :( It used to, prior to kernel version 2.6.11. And I believe it still does=20 in the latest 2.4 kernel. But the developpers thought this behaviour was=20 not desirable because it broke some usages and replaced the round robin=20 with a hash so the same original source+destination pair always gets the=20 same address in the SNAT range.