Hi Martin! Thanks for your feedback. Okay, i will try to go step by step. > : 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. I made every new try a ipchains -F - there was no other chain(s). >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. Okay, it seems there is a problem. In this DENY chain I get after every ping 4 more packets (one ping - 4 tries). It seems ipchains deny the incoming icmp packets on eth2. But why? I tried also to specify the source ip with some other chains, and it is the packet, that comes from the host 62.154.89.102 - exactly the packet I am waiting for. A ipchains -nML shows a open masq connection to the host, I ping'd: IP masquerading entries prot expire source destination ports ICMP 00:57.85 192.168.0.31 62.154.89.102 512 (61009) -> 8 >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 I used the ip address. > : 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? 0: from all lookup local 32766: from all lookup main 32767: from all lookup 253 Yes, it is okay - if I delete the rule, the network could not be reached, because I have no default route ( also in the table main). It was only a _simple_ test to see if ip rules works. With this rule: 0: from all lookup local 32765: from all fwmark 2 lookup 10 32766: from all lookup main 32767: from all lookup 253 there is a timeout. It shows me, the marking of packets works and the ip rules can see the marked packets. >By the way, you are using "ip route flush cache" every time you make >changes to the routing tables/RPDB, right? Yes, i do. ---- cut ---- your next Mail ---- cut ---- >Aigh! I think I may have spotted the problem. > >Your routing table number 10 doesn't know anything about 192.168.0.0/24 >does it? > >Make sure that each routing table has routes for the destinations it is >supposed to be able to reach! > > : 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 > : * x.x.x.x is the default gateway! Well, if I look into the rules table I see: 0: from all lookup local 32765: from all fwmark 2 lookup 10 32766: from all lookup main 32767: from all lookup 253 Okay! If I start the ping, the icmp packet comes into the input chain with source address ex. 192.168.0.31 (my local host). (ipchains -A input -p icmp -s 192.168.0.0/24 -m 2) ipchains looks: - is the source address in network 192.168.0.0/24? Yes. - is a icmp packet? Yes. Okay it will be marked with 2. Now the ip rules number 32765 (all fwmark 2 lookup 10) see it and activates routing table 10. The routing table 10: default via x.x.x.x dev eth2 x.x.x.x is the gateway. Okay, it goes out on eth2 to the gateway - to the target host. It answers a icmp packet. It arrives on eth2. Not it is going hot :) Normaly it should do the following: Comes into the input chain. Ipchains looks: - is the source address in network 192.168.0.0/24? No. The source address it _not_ in the net 192.168.0.0/24, so it will not be marked. Now it is ip rules turn: 0: from all lookup local 32765: from all fwmark 2 lookup 10 32766: from all lookup main 32767: from all lookup 253 okay, not local, not marked with 10 - is comes into the main routing table! And this is the main routing table: 217.5.98.39 dev ppp0 proto kernel scope link src 80.131.187.122 n.n.n.n/28 dev eth2 proto kernel scope link src y.y.y.y 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1 n.n.n.n/28 is the net and y.y.y.y the ip address of eth2 In the main routing table, there is the net 192.168.0.0/24, so it should go on! But okay. This is not the problem. It seems, ipchains DENY this packet. But why? Here a ipchains -L: Chain input (policy ACCEPT): target prot opt source destination ports - icmp ------ 192.168.0.0/24 anywhere any -> any DENY all ----l- anywhere anywhere n/a Chain forward (policy DENY): target prot opt source destination ports MASQ all ------ 192.168.0.0/24 anywhere n/a Chain output (policy ACCEPT): The deny chain, is your chain to monitor :) Without it (the deny chain) it is exactly the same siduation. Wth denys ipchains this incoming packet on eth2? Marco _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
