Re: Routing issues - ping works one way but not the other

Hello,

David Brown a écrit :
> I've got a routing issue that I can't quite figure out. My (very
> simplified) setup is this:
>
> Box A is on 192.168.0.1 and is the router, dns server, etc. for the
> 192.168.0.x network. It has other interfaces as well, for access
> further into the network and out onto the internet. iptables are set to
> allow all traffic in, out and forwarded. There is a "route -net
> 192.168.1.0/24 gw 192.168.0.2" in the route table.

Don't you mean "192.168.1.0/24 gw 192.168.0.3" ?

> Box B is on 192.168.0.2 with 192.168.0.1 as the default gateway. It's a
> client machine on the 192.168.0.x network.
>
> Box C is a router with two ports. One is at 192.168.0.3, the other is
> 192.168.1.1. iptables are set to allow all traffic in, out and
> forwarded. The default route is set to 192.168.0.1 (box A).
>
> Box D is on 192.168.1.2 with 192.168.1.1 as the default gateway. It's a
> client machine on the 192.168.1.x network.
>
>
> If I log into box B, and type "ping D" I get a response. The route
> flow is B to A (the default gateway), then to C (due to the specific
> route command), then to D. I've confirmed this path with traceroute.
>
> If I log into box D and type "ping B", I get no response. Traceroute
> shows the flow from D to C as expected, but nothing beyond that. I know
> that the packet is going directly from C to B (see below for how I
> know), as expected. But somehow the reply from box B is not getting
> back to D.
>
> (If I ping from box D to something outside these networks, accessed
> through router A, it works fine.)

What about ping A from D ? I guess it works fine ?

> I can't see why I can ping one way, and not the other.

Is there some NAT or stateful filtering on the box A and box C ? These
don't work well with asymmetric routing.
Can you run tcpdump on the boxes and see what's going on ?

> If I run "route -net 192.168.1.0/24 gw 192.168.0.2" on B, then pings
> work properly both ways.

Then I guess it rules out box B not replying to ping at all.

David Brown a écrit :
> On 12/10/2010 13:06, Pascal Hambourg wrote:
>
>> Is there some NAT or stateful filtering on the box A and box C ? These
>> don't work well with asymmetric routing.
>
> There is no NAT or any kind of filtering on box C - everything passing
> through is forwarded directly. Box A does have filtering and NAT, but
> not on the interfaces in question (though see below for an update).
[...]
> A is refusing to forward it from B to C because of the iptables rule
> "iptables -A FORWARD -m state --state INVALID -j DROP". I have always
> used this rule (and the same for INPUT and OUTPUT chains) at the start
> of iptables firewalls.
>
> Assuming that is the case (and I'll do some more tests to make sure),
> the question then is why is this reply packet being judged as invalid?

Because box A's connection tracking state machine did not see the echo
request it replies to, due to the asymmetric routing. In the other way,
box A sees the echo request which has state NEW, and does not see the
echo reply, but that does not matter.

> And if I am correct in thinking that dropping INVALID packets is
> considered best practice, is there any risk in skipping that rule? The
> scope here is only for packets arriving and leaving on the same internal
> LAN interface - anything on other interfaces or originating from outside
> will still be dropped if it is INVALID.

You can safely ACCEPT any packet arriving and leaving on the same
internal LAN interface, regardless of its state.

Andrew Gideon a écrit :
> On Tue, 12 Oct 2010 15:07:45 +0200, Pascal Hambourg wrote:
>
>> Because box A's connection tracking state machine did not see the echo
>> request it replies to, due to the asymmetric routing. In the other way,
>> box A sees the echo request which has state NEW, and does not see the
>> echo reply, but that does not matter.
>
> Is there any way to "fix" this by sharing connection state amongst
> multiple routers?

Check conntrackd from conntrack-tools.
<http://conntrack-tools.netfilter.org/>