Hello,

I have an advanced routing problem here.
I need the advice of a Networking Expert or a CCNA/CCNP level administrator.

The problem can be found here:
http://hosted.infosky.ro/interesting.png

I have changed the IP addresses to simplify the output.

As you've noticed, I have 2 networks: 192.168.0.0/24 and 192.168.1.0/24 linked to the Router.
192.168.0.0 - is an Ethernet Network.
192.168.1.0 - is a Wireless Network.

My Laptop is running Ubuntu Linux and my router is running Gentoo Linux.

I have connected the Laptop to BOTH the 192.168.0.0 net (via eth0) and to 192.168.1.0 net (via eth2).

So my routing table looks like this:
The PROBLEM: When I ping the Wireless Interface of the Laptop (192.168.1.2) from the Computer (192.168.0.3) the ping DOESN'T WORK !
It travels the network up to my Wireless NIC on the Laptop but it dies there !

But if I ping the Router Interface for the WLAN (192.168.1.1) from the same machine (192.168.0.3) it works !

Pinging everything else from Laptop also works !

Being connected to 2 networks on my laptop via my physical interfaces, I have at least 2 directly connected routes.
So it's not a routing problem from what I have seen.

If I remain only on wireless and disconnect Ethernet, everything works fine.
The problem only arises when I'm using BOTH the connections at the same time.

I wiresharked my laptop on all interfaces and filtered for ICMP, and when I ping from the Computer to the Wireless Interface of my Laptop I see that the PINGs are indeed coming into my wireless interface !
But my OS does not send replies.
Only ICMP requests, no replies.

Theoretically it should receive PING on wlan interface and send it out on the ethernet interface (since my ethernet network is directly connected trough eht0). - as indicated by my Red directions in the drawing.

So it's a "ping trough one interface, reply trough other" scenario.

Before you ask, my Router is already set to ip_forward=1, beucase my laptop can sense the pings coming on the wlan interface.

Please, only reply if you understand what I am saying here, please do not "BUMP" or other stuff.
I need serious help here.

Thank you !

Two possibilities:

1. The router NATs the packet from the desktop computer, leaving you with a hairpin NAT scenario. Wireshark should be able to tell you if this is the case.

2. The packet is caught by the laptop's ingress filtering ("Source Address Verification"), as the source address matches a network connected to a different interface. Try disabling this feature with echo 0> /proc/sys/net/ipv4/conf/default/rp_filter and see what happens.

(By the way, this is by no means an advanced routing problem.)

1. No, it's not a NAT problem.
NAT is enabled only when leaving the Router.
The Ethernet LAN and WLAN are local to the Router.

2. I've echo`ed Zero and still no luck...

Have you tried altering the rp_filter settings for the respective interfaces? (/proc/sys/net/ipv4/conf/eth0/rp_filter for eth0)

I've set all to 0 but it still doesn't work.

Well, can you ping in the other direction (from the laptop to the desktop) if you force the source interface/address with the -I parameter? (ping -I eth2 192.168.0.2)

Destination Host Unreacheable

Strange, perhaps the -I parameter doesn't work the same way as the -s parameter to traceroute. Could you try traceroute -s 192.168.1.2 192.168.0.3 from the laptop?

No replies. Only *.

It this isn't caused by the rp_filter setting, it has to be a firewall issue on the laptop.

all ICMP is enabled on the firewall.
I don't think it's a firewall issue, since Wireshark tells me that the system receives the ICMP Request, by my system doesn't send out the ICMP Reply...

A packet (ICMP or otherwise) received on interface X with a source address belonging to a network connected to interface Y is usually a spoofed packet. The rp_filter setting will cause the system to discard any such packets, but it is also common to have firewall rules dropping spoofed packets.

In addition to disabling rp_filter, you may want to temporarily disable the firewall with iptables -P INPUT ACCEPT and iptables -F INPUT. You may want to check the OUTPUT chain as well, just in case.