Definite NAT bug [was: 2.4.0 and sendmsg problem. Maybe NAT bug.]
Sun, 30 Jul 2000 14:31:21 -0700
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
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,
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
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.
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
Content-Type: text/x-vcard; charset=us-ascii;
Content-Description: Card for David Ford
title:Blue Labs Developer