MASQUERADE/SNAT and multiple interfaces with the same IP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux