On Fri, Jan 22, 2010 at 11:53:45AM +0100, Patrick McHardy wrote: > Fredrik Ax wrote: > > On Fri, Jan 22, 2010 at 11:09:43AM +0100, Patrick McHardy wrote: > > > >> Fredrik Ax wrote: > >>> Hi guys, > >>> > >>> I'm a pretty experienced Linux / network developer and administrator, > >>> but I can't get my head around this one. > >>> > >>> The long story is that I have a box used as router/fw/proxy running > >>> Debian Squeeze with a customized 2.6.32 x86_64 kernel having three > >>> interfaces (eth2,eth3,eth4) on the same external subnet. One of the > >>> interfaces is used for doing masquerading of other > >>> subnets. Masquerading (not snat) is chosen because the interfaces are > >>> on dhcp, and I don't want to have to rewrite the fw rules each time I > >>> get a new addr ... already have enough with dhclient-hooks for fixing > >>> the routing tables dns-updates, etc ;-) What I basically want to do is > >>> make the proxy's request to go out the same ifc as the masqueraded > >>> packets getting a src addr of s41.s42.s43.s44. Other locally generated > >>> packets should get a src addr s21.s22.s23.s24. > >>> > >>> To accomplish this I'm using iptables to mark all, to port 80, locally > >>> generated tcp packets: > >>> > >>> % iptables -t mangle -vnL OUTPUT > >>> Chain OUTPUT (policy ACCEPT 3234 packets, 2254K bytes) > >>> pkts bytes target prot opt in out source destination > >>> 1114 181K MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 MARK set 0x4 > >>> > >>> I have verified that the iptables rule marks them fine enough. > >>> > >>> Then the ip rule with prio 99 below should then catch them and route > >>> according to table eth4 below. That rule however does, for some reason > >>> not match those packets, instead they are routed according to table > >>> eth2 below (prio 200 rule), getting src addr s21.s22.s23.s24. If I > >>> disable that rule they are routed according the the prio 300 rule > >>> (getting src addr s31.s32.s33.s34). > >>> > >>> ... > >>> > >>> > >>> What am I doing wrong here? > >> Source address selection happens before the packet is even generated, > >> so iptables marking in OUTPUT can't affect it. > > > > So, to accomplish this I would have to oute it through a dummy > > interface to make iptables able to mark it before it goes out? > > You need some criteria for your routing rules that is available > when the socket is routed. That's everything but the packet mark. > Using a seperate device will work. > > For ethernet, the macvlan device might be a good choice if you > don't mind using different MAC addresses for each IP. Thanks, I'll have a look at it ... Just one more question, the host is actually run as a domU on XEN and all of the eth2-4 interfaces are on a in dom0 created bridge, bridging in a vlan where the tagged traffic is on a blanace-rr bond-device. Would it create any problems creating a macvlan device on top of this? Thanks AGAIN, /frax ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -- 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
