Thanks for your help, but we found it. Damn reverse path filtering was on :( On Sunday October 31 2004 17:16, Jason Straight wrote: > On Sunday October 31 2004 09:30, Bernd Eckenfels wrote: > > You reported that TCPDump of the request flow looks ok (I asume you also > > checked source/destination ip and ports, and mac)). And that you also see > > the response from peer. Since I also asume that the back route to the > > laptop is a simple static entry:(**) > > > > the problem may be with the FIB cache for that particular flow. Can you > > see what "route -C -ee"* tells you about that connection in both cases > > (while data flows). > > You are right, for some reason it's not getting to the route cache. But why > only when it's based on marked. > > Here's all I do at router #1. Router #2 is on eth0 and my laptop is on > eth1, it also has a T1 on ppp0. > > iptables -t mangle -I PREROUTING -s [laptop] -p tcp --dport 80 -j MARK > --set-mark 0x50 > > ip route add default via [router #2] dev eth0 table http > ip rule add fwmark 0x50 table http > ip route flush cache > > Traffic will flow to the remote, I get traffic from the remote location > which I can dump at router #1 eth0 and see a dst ether of router #1 and a > dst IP of laptop. > > If I route all traffic by 'ip rule add from [laptop] table http' it works > fine. If I route all traffic by changing the MARK to encompass all traffic > from laptop it doesn't work. The only common denominator I see is the > marking, however if I leave the traffic marked when I route by src it still > works fine. It doesn't seem to be the routing or the marking alone that is > causing failure, but routing based on the mark explicitly. -- http://www.skycon.net/ ICQ: 1796276 pgp: http://www.jeetkunedomaster.net/~junfan/pgp.key OS: Mandrake Linux http://www.mandrakelinux.com - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
