Hi Marco, Let's work through this together--your description is good--I'm a bit puzzled too. : ipchains -A input -p icmp -s 192.168.0.0/24 -m 2 : ip ru add fwmark 2 table 10 : ip route add default via x.x.x.x dev eth2 table 10 : ipchains -A forward -s 192.168.0.0/24 -j MASQ You don't write a rule to allow explicitly for the returning echo-reply packets. If you have a default policy of DENY on your input chain, then the packet can appear on eth2 (see your tcpdump below) but still be denied. If you want to make sure that the policy never gets called (easier to see if packets are hitting the last rule than if they are hitting the chain policy): ipchains -A input -i eth2 -j DENY -l Now you'll have a chain that logs the packets and has a counter--this will make it easier to see if ipchains is part of the problem. : here the tcpdump on eth2 during a ping from internal 192.168.0.31 to a : host in the internet (ping 62.154.89.102 - 4 times timeout): : : tcpdump: listening on eth2 : 19:20:28.532089 y.y.y.y > L-EB1.L.DE.net.dtag.de: icmp: echo request : 19:20:28.572089 L-EB1.L.DE.net.dtag.de > y.y.y.y: icmp: echo reply : 19:20:33.532089 arp who-has x.x.x.x tell y.y.y.y : 19:20:33.532089 arp reply x.x.x.x is-at 0:0:c0:b1:a9:90 : 19:20:33.852089 y.y.y.y > L-EB1.L.DE.net.dtag.de: icmp: echo request : 19:20:33.882089 L-EB1.L.DE.net.dtag.de > y.y.y.y: icmp: echo reply : 19:20:38.852089 y.y.y.y > L-EB1.L.DE.net.dtag.de: icmp: echo request : 19:20:38.892089 L-EB1.L.DE.net.dtag.de > y.y.y.y: icmp: echo reply : 19:20:43.862089 y.y.y.y > L-EB1.L.DE.net.dtag.de: icmp: echo request : 19:20:43.902089 L-EB1.L.DE.net.dtag.de > y.y.y.y: icmp: echo reply : : y.y.y.y = the ip of eth2 : x.x.x.x = the gateway : You can see, the ping goes out and returns on the eth2 interface. But it : will not be masqueraded to the internal host 192.168.0.31. Minor note: I'd say "de-masqueraded" here because the packet was masqueraded on the outbound trip, and will now be associated with the existing masqueraded connection. To view the masquerading table (if you have any doubt about whether the entry exists or not): ipchains -nML : On this host, I started the ping. : Other strange thing: after the return of the first reply, there is a : pause of 5 seconds. After that comes a arp request. Now that strikes me as very odd. I don't have an easy answer for this one...unless you started the ping like this: ping -i 5 L-EB1.L.DE.net.dtag.de : And anything else: if I delete the rule fwmark 2 table 10, the client : (192.168.0.31) shows during a ping to outside: : 192.168.0.1 (ip of eth0): no route to host What does "ip rule show" tell you after you have removed the above rule? : The ip rule seems to work and the ip route too because the icmp packet : goes out and comes back. But why will it not be route to the internal : host, which has sent it? See my speculation above....ipchains interference? : I really do not know what is wrong here. : If I do: : ip ru add default via x.x.x.x dev eth2 : Everything works well - everything goes over eth2. By the way, you are using "ip route flush cache" every time you make changes to the routing tables/RPDB, right? OK, so: - remove all extraneous ip rule entries (from the RPDB) - add the one RPDB rule you want - check all your routing tables - ip route flush cache - try again from the internal host - check the counters on the ipchains Also, could you show me what "ip rule show" says on the affected box? -Martin -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
