snat bridge routes reply packets
azez at ufomechanic.net
Fri Sep 30 11:56:40 CEST 2005
Henrik Nordstrom wrote:
> If you do not reroute DNAT:ed packets then the bridge would deliver the
> packet to the original destination MAC, not to the local host.
> Same applies if you DNAT within the local subnet.
I probably didn't make clear that I was looking at changing kernel
behaviour, not looking for iptables rules.
Oh; well that was the bit I was going to change. One of the bridgeing
code output functions (whose name I forget for now) was the trick;
>>> Yes, in MASQUERADE type flows where the firewall SNATs flows to it's own
>>> address it might be possible in certain cases to remember the original
>>> "client" MAC address, and avoid the ARP:ing on return traffic. But this
>>> is on the assumption that the client network is symmetric. It is
>>> possible the traffic was received via an assymetric route where return
>>> traffic should go to another MAC address and ARP is required to figure
>>> this out.
>> Yes, this is a strong assumption, we would only do this when snat-ing
>> bridged traffic. There may be assymetric bridging which would break, but
>> then snat is already broken for bridging.
> I would not agree. Both SNAT and DNAT works just fine in bridgeing
> assuming the IP level is properly set up to support the addresses used.
I agree, but pure bridging also works without this assumption and it
could work with snat bridging.
> You can not SNAT to an otherwise non-existing IP as there then is no MAC
> address for the receiving host to sent the replies to (no ARP answer
> when the receiving host wants to send reply packets, so it can't).
This is the problem I intend to solve
> - Don't reroute the packet at all. All MAC addressing is preserved
> as-is on each packet. (relevant to both normal IP level iptables and
> - Track the initiating source MAC address, and reroute at MAC level
> all packets in the reply direction to this address. (only relevant to
> bridgeing). But route packets in the forward direction. **
I did say in my first post that my conntrack mods are already tracking
the mac address and phsedv of the originating packet; this is what I was
planning to do.
> - Reroute all NAT:ed packets. (the default, what we have today).
> One drawback of the proposed solution is that conntrack needs to be
> extended with MAC addressing in each direction.
already got it, and afact nf_netfilter already does much in this
More information about the netfilter-devel