Jan Engelhardt wrote:
On Apr 24 2007 20:06, Ben Greear wrote:
I'm now trying to masquerade packets that have been marked
a certain way. I'm using these commands:
# I'm not sure this is doing the right thing, but it is not giving errors.
iptables -A POSTROUTING -t nat -j MASQUERADE -m mark --mark 10001
It does what the programmer said:
Masquerade only packets with a mark of 10001.
# This appears to work as planned.
iptables -t mangle -A PREROUTING -i eth1 -j MARK --set-mark 10001
iptables -t mangle -A PREROUTING -i eth2 -j MARK --set-mark 10001
And this says:
mark all packets that come from eth1 and eth2.
So in essence, you have "masquerade everything that came from eth1 and eth2".
A slight bug, but ok. (In most cases, you only want to masquerade on
some interfaces, not all, so the use of -o is usually wanted.)
I added a u32 'mark' field to the conn-track tuple,
Just why?
Because otherwise it seems to me that there is only a single conn-tracking
tuple for src -- dest, and it also seems to me that the conn-track entity
has the should-we-NAT flags (in the 'status' bitfield).
My scenario involves
virtual routers (ie, routing tables with rules so that pkts hit certain routing
tables) and sending packets through (virtual) looped-back ethernet ports, so
the same source-dest tuple will be seen on multiple interfaces. I need
a different tuple for the flow that should be NATed (so only that flow is NATed),
so that is why I added the MARK rules and the mark field to the conn-track tuple.
As you noticed, my attempt to MASQ based on skb->mark was not really the right
thing to do, so I changed it back to mask with -o [outgoing-device].
This still does not seem to trigger NAT to happen, and I had no luck figuring out why
yesterday...
I found someone who is interested in considering doing this for hire,
so I will be sending details and such to them. If that works out, hopefully
there will be a patch from him for review sometime soon.
There's also the possibility I have totally mis-understood what is currently
supported in the kernel and maybe I just need to adjust my rules or something
like that....
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
