Hi Jan, Thanks for your quick response. Disabling the rp_filter made everything work! Agreed, disabling the rp_filter is not a very secure and elegant solution. At least I have a working solution now. But what exactly did you mean by "proper policy routing" when saying that NAT should not be used for asymmetric routing? Greetings, Dominik On Wed, Mar 17, 2010 at 1:28 PM, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote: > > On Wednesday 2010-03-17 10:40, Dominik Kaspar wrote: >> >>I have a question about why packets are disappearing in my setup. My >>machine has two L2TP tunnels (10.6.1.2 and 10.6.1.3) to a Web server >>(10.6.1.1). The local machine uses a command such as "wget >>http://10.6.1.1/file --bind-address 10.6.1.2" to request a file from >>the server. On the server, outgoing packets are rewritten to 10.6.1.3, >>so that they travel back through the other tunnel. That works fine. > > For asymmetric routing, you should not be using NAT, but proper > policy routing. > >>At the client, I am using the RAWDNAT target to translate the address >>of incoming packets destined for 10.6.1.3 to be locally translated >>back to 10.6.1.2. This is the rule I use: >> >>iptables -t raw -A PREROUTING -p tcp --sport 80 -d 10.6.1.3 -j RAWDNAT >>--to-destination 10.6.1.2 > > That might trip up rp_filter. > >>According to the netfilter flow chart, a packet then travels into >>"conntrack" and then into MANGLE PREROUTING, where I can still log the >>packet (that is now going to 10.6.1.2 instead of 10.6.1.3). >> >>However, then it somehow disappears! I cannot find the packet in NAT >>PREROUTING and also not in any INPUT or FORWARD tables after the >>routing decision point. What happened? What made the packet suddenly >>disappear? Is there something going on that causes the packets to be >>dropped? > > My guess is that route lookup failed, or rp_filter. > Unfortunately I don't know a way to make failed route lookups > visible - perhaps the iproute2 guys have a magic command? > -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
