netdev - MASQUERADE/SNAT and multiple interfaces with the same IP

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-next>] [day] [month] [year] [list]

Message-ID: <CAKfDRXjXkY--PjXAa1m=As+Vf_1__WBokkTAE5BHg+gxsM9Yxw@mail.gmail.com>
Date:	Fri, 16 Aug 2013 12:55:15 +0200
From:	Kristian Evensen <kristian.evensen@...il.com>
To:	netfilter@...r.kernel.org, netdev@...r.kernel.org
Subject: MASQUERADE/SNAT and multiple interfaces with the same IP

Hello,

I am currently experimenting with load-balancing traffic between
multiple tunnels. I have two ip-in-ip tunnels between a router and a
gateway, each tunnel given the same IP in order to simplify address
distribution. In order to route traffic through different tunnels, I
use policy based routing. MASQUERADE/SNAT is used to NAT the packets
coming from the network behind the router.

As long as each flow is sent through the same tunnel, everything works
as expected. However, when I move a flow from one tunnel to another
(for example when a link goes down), there is a difference in behavior
between MASQUERADE and SNAT that I haven't been able to figure out.
When MASQUERADE is used, the NAT mapping is destroyed, one packet is
dropped and then a new mapping is created. With SNAT, this does not
happen and the same mapping is used. The reason keeping the same
mapping on the tunneled packets is important, is to avoid confusing
the remote peer.

After spending long time looking at the source code, I can't figure
out why this happens. Once the MASQUERADE/SNAT rule has been inserted,
to me everything looks the same. One theory I had was that since
MASQUERADE rules are "bound" to an interface, moving the flow to
another interface would cause a new rule to be created and the old one
to eventually time out. However, I always see the DESTROY-message from
conntrack before NEW. I tried tracing the origin of the
DESTROY-message and it seems to be generated by death_by_timeout(). I
have a suspicion that the change of links is detected in early_drop(),
but I have not been able to figure out why.

Does anyone have some hints on where to keep looking, or know the cause?

Thanks in advance for any help,
Kristian
--
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