When PC2 pings PC1, then several things happen:
the icmp request reaches PC1
PC1 sends icmp reply to its default gateway – Router 1
Router 1 receives the reply, but doesn’t forward it to Router 2, the reply gets lost somehow (can’t see it anywhere in any log)
PC2 ping times out
If on PC1 I manually do „route add 192.168.131.0/24 via 192.168.0.2 dev eth0“ then all is fine, but this solution is not applicable in our case.
When Router 1 was SLES10sp2 – all was fine. Since we updated Router 1 to SLES11sp1, we’ve got the above issue. I suspect some parameter changed for the kernel, but I can’t find which one it is. Is there something wrong with this setup?
It being about routing, it could have been OS independent. But a syou say this was OK in an earlier version of SLES and is going wrong now in a newer version of SLES, I guess this is a SLES problem. And as we are here on the openSUSE forums, this is not the place where you can expect the best answer.
My advice is to go to https://forums.suse.com/ . Th same username/password as here should work there.
I suspect it might be a general architecture design issue, therefore I would like to hear other people’s opinions on it. Nevermind the OS flavour, I’m sure it’s the same in openSUSE as well.
Then please backup your story with real, unabreviated computer facts, like the output of
netstat -rn
of all systems involved.
BTW, a wild guess, it could be that your icmp reply is dropped somewhere because it does not come from the same source as were tthe icmp request went to, and thus does not belong to an established session.
Yes, however, why everything is fine in one direction (PC1-PC2) and not working at all in the other direction (PC2-PC1)? It sounds to me like a new kernel security setting. I thought it was the rp_filter setting (if you have a look at the TID I mentioned you’ll see it pretty well matches the situation), but nothing happens if I change it’s value.
Another thought that I had was that some setting is prohibiting routing a packet out on the same interface it came in. In SuSEfirewall there’s a setting FW_FORWARD_ALWAYS_INOUT_DEV=“eth0” which controls this behaviour. However, I’m not using SuSEfirewall, I use iptables through FirewallBuilder gui. Do you have any idea which kernel settings the above FW_FORWARD_ALWAYS_INOUT_DEV controls?
P.S. Unfortunately I cannot post here command output from the real system, but I’ve described everything as it is (only with fake IP@).
Turned out that for whatever reason, when PC2 sends the ping “request” to PC1, the ping “reply” of PC1 reaches Router 1 in state “INVALID” . No idea why, but that’s the fact. Of course, on Router 1 I have iptables rule that looks like this:
$IPTABLES -A OUTPUT -s 192.168.0.0/24 -d 192.168.131.0/24 -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -s 192.168.0.0/24 -d 192.168.131.0/24 -m state --state NEW -j ACCEPT
As you can see, it won’t allow packets in “INVALID” state. So I made it stateless:
$IPTABLES -A OUTPUT -s 192.168.0.0/24 -d 192.168.131.0/24 -j ACCEPT
$IPTABLES -A FORWARD -s 192.168.0.0/24 -d 192.168.131.0/24 -j ACCEPT
The real question now is why those packets are marked “INVALID” on their way from PC1 to PC2 …