> > for marking i use: > > "iptables -t mangle -A PREROUTING -i eth4 -s 192.168.0.22 -d 141.24.12.2 -j > > MARK --mark-with 1" > > > > for selecting a routing table upon that marking i use: > > "ip rule add fwmark 1 table test" > > > OK. Are these two instructions the only instructions active on the box? besides of the marking there is a masquerading active, as mentioned in previous mails: "iptables -t nat -A POSTROUTING -o ppp4 -j MASQUERADE" filter table is empty. there exist other routing rules, but they are all rules from other hosts out into the world. no rules backward, for internet-lan-direction i use the main table. > Both: > "ip rule add fwmark 1 table test" > and > "ip rule add from 192.168.0.22 table test" > > are being used for the ping packets and seem to be equivalent. Your problem > seems to be the loss of the pong packets, right? right > > tcpdump verifies, that indeed replies are coming in and shows, that no icmp > > error messages are sent out, what should be the case if no route back could > > be found due to incorrect routing. > > This part is not completely correct. The ICMP messages would go out through > ppp0, right? and you're not capturing that. > > Do a simultanious tcpdump on all the ppp interfaces and let us know the result. ok, i did monitor all interfaces using "tcpdump -n -i ppp0 icmp and host 141.24.12.2" and so on. as expected nowhere a pong went out. i think any pong leaving the box would have showed up in the FORWARD counting rule in the first test. > Although, with the output of "ip rule" it looks to me that table main must be > taken for the return traffic and you have a route to 192.168.0.0/24 there. you are right. and _all_ routing tables contain a route to the local net, so a packet should always find its way from the outside in. i think even if the masquerading would be broken, the packet wouldnt get lost. it would show up somewhere OR an icmp error would be sent to its sender. so is there a bug in the routing code? and why am i then the only one having this problem?
