Definite NAT bug [was: 2.4.0 and sendmsg problem. Maybe NAT bug.]

[David Ford]

This is a multi-part message in MIME format.
--------------D149A14BA6873FAA1E50117F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rusty Russell wrote:

> This code will only kick in if you are doing DNAT to 192.168.1.2, for
> example.  Then you (1) want to reroute, and (2) want to disregard the
> original binding.
>
> With no NAT rules, you shouldn't be seeing any effect,
> Rusty.

Unfortunately that isn't the case.  As soon as iptables_nat goes active in
the kernel, ALL packets exiting the machine take on the address of the egress
interface.  There are _no_ rules in the nat table.

You can check this by running traceroute -s <secondary ip> and tcpdump.  The
very moment the nat module is loaded, the src ip changes to the primary IP on
the interface.

That's what I've been discussing with lkml and Andi for about two weeks now,
I thought it was just tunnels that were affected.  Then I noticed my BIND
transfers were getting refused and saw the IP they were trying to transfer
with.  So I investigated.  All known programs, traceroute, IRC, etc, all
exhibit this behavior.

Unfortunately this makes netfilter w/ NAT incompatible with machines that
have more than one interface address.  I have four routers that are 'broken'
in this situation.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."



--------------D149A14BA6873FAA1E50117F
Content-Type: text/x-vcard; charset=us-ascii;
 name="david.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Ford
Content-Disposition: attachment;
 filename="david.vcf"

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

--------------D149A14BA6873FAA1E50117F--