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?
I’m having the following strange issue since I’ve updated one of our
routers to sles11sp1.[/color]
[color=blue]
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[/color]
I may be able to help…
It seems that even though IP Forwarding is on, packets are only
forwarded between two separate interfaces.
I had a similar situation and got it to work this way.
Thank you Kevin for the reply, however I’m not using SuSEfirewall - it’s stopped. I’m using iptables (through firewallbuilder interface). I see option number 33 in the file you mentioned :
33.)
Bridge interfaces without IP address
Traffic on bridge interfaces like the one used by xen appears to
enter and leave on the same interface. Add such interfaces here in
order to install special permitting rules for them.
Format: list of interface names separated by space
Note: this option is deprecated, use FW_FORWARD_ALLOW_BRIDGING instead
Example:
FW_FORWARD_ALWAYS_INOUT_DEV=“xenbr0”
FW_FORWARD_ALWAYS_INOUT_DEV=“”
Do you know exactly which kernel settings this option modifies, so I can give it a try?
Regards,
Milko Simeonov
[QUOTE=KBOYLE;9886]Simeonof wrote:
[color=blue]
I’m having the following strange issue since I’ve updated one of our
routers to sles11sp1.[/color]
[color=blue]
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[/color]
I may be able to help…
It seems that even though IP Forwarding is on, packets are only
forwarded between two separate interfaces.
I had a similar situation and got it to work this way.
Traffic on bridge interfaces like the one used by xen appears to
enter and leave on the same interface. Add such interfaces here in
order to install special permitting rules for them.
Format: list of interface names separated by space
Note: this option is deprecated, use FW_FORWARD_ALLOW_BRIDGING
instead #
Example:
FW_FORWARD_ALWAYS_INOUT_DEV=“xenbr0”
FW_FORWARD_ALWAYS_INOUT_DEV=“eth0”[/color]
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are using the web interface,
show your appreciation and click on the star below…[/QUOTE]
Do you know exactly which kernel settings this option modifies, so I
can give it a try?[/color]
I’m sorry, I don’t. I haven’t worked with iptables. Perhaps someone
else has and can offer a suggestion or perhaps you could do some
research and find out what needs to be changed to allow forwarding to
occur “on the same interface”.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are using the web interface,
show your appreciation and click on the star below…
The strange thing is that “forwarding on the same interface” works fine if the “initiator” is PC1, and doesn’t work at all if the “initiator” is PC2…
[QUOTE=KBOYLE;9902]Simeonof wrote:
[color=blue]
Do you know exactly which kernel settings this option modifies, so I
can give it a try?[/color]
I’m sorry, I don’t. I haven’t worked with iptables. Perhaps someone
else has and can offer a suggestion or perhaps you could do some
research and find out what needs to be changed to allow forwarding to
occur “on the same interface”.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are using the web interface,
show your appreciation and click on the star below…[/QUOTE]
[COLOR=blue]> Do you know exactly which kernel settings this option modifies, so I
can give it a try?
[/COLOR]that’s most probably not affecting kernel settings, but simply adding an appropriate forwarding rule (the comment reads “in order to install special permitting rules for them”).
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)
This may be something totally different than rules… your routing setup will result in ICMP redirects sent by router1 and may be affected by a bug in recent Linux kernels/IP stack (on PC1, in this case). This bug’s results are affected by timing, so it’s independent of “ICMP echo request” vs. “echo reply”:
PC1 sends ICMP echo request to PC2. The packet is sent to router1, as no other option is available to the IP stack on PC1
router1 notices that the packet will leave via the same interface as it entered the router, so router1 sends an “ICMP redirect” to PC1 (“check your routing setup… and use router2, not me!”)
router1 forwards the packet to router2
… (router2 forwards to PC2, response PC2 to router2 to PC1)
This can happen for some time, until PC1 actually reacts to the ICMP redirect (this can take several seconds) and sends the request packets to router2 directly, making it PC1-router2-PC2.
At some point in time, the redirect information stored in PC1 times out. The correct way would be that PC1 sends further packets to router1 again… but due to the bug, nothing will be sent from PC1.
Now, this can be with any packet from PC1 to PC2 - an ICMP request or an ICMP response, a first one or starting somewhere in the middle of the packet chain.
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)
Have you actually verified this using i.e. tcpdump? And did you mean “router1 receives the replies”? If yes, the problems you describe should not be caused by the mentioned Linux bug.
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 …
← try this as well.