snat bridge routes reply packets

[Amin Azez <azez@ufomechanic.net>]

I have a bridge setup snat'ing some IP's that aren't actually on the
bridge subnet.

That works fine except that the nat code doesn't know what to do with
the de-snat'd packets and tries to send them to the default gateway.

This makes sense, but it's routing, not bridging.

Bridging dnat would keep track of the physdev and src mac as well as the
src ip and ignore arp altogether when re-issueing the de-snat'd
responses; it would write the de-snat'd packet back out to the original
interface and targeted to the original mac.

I think bridging snat can be detected when the target mac of the packet
that causes the conntrack to be created does not match the mac of the
physdev the packet comes in on (i.e. the snat'ing box is not being used
as a gateway).

In such cases the physdev and srcmac must be saved.

(Co-incidentally I'm already doing this in my contrack mods which will
no doubt get merged into nf_conntrack that does some layer 2 stuff)

So my real questions are:
1) Am I nuts?
2) Any tips on skipping the arp cache stuff on the de-snat'd response,
as I have a reference to the physdev and target mac already available?

I also think there is some mileage in checking the src_mac when looking
up conntracks in the orig direction, to avoid having to presume that the
same ip address does not exist on different physdev of the same bridge -
to thus allow them both to be snat'd independantly.

Sam Azez