A service bound to the IP of eth1 is still visible from eth0. This is not an RFC violation (RFC1122 calls this "weak end host"), but it is unexpected for most Linux users, and the very reason why people bind a service to the IP of a specific network interface usually is to make sure it can only be used from that interface (DHCP, samba, squid and intranet web servers come to mind). This is not an ARP issue. Making the kernel stop answering to ARP requests will not make it harder for an attacker to reach the service. Here is how to reproduce the behaviour: host a (eth0 connected to eth0 of host b): ifconfig eth0 10.0.0.1 ifconfig eth1 23.0.0.1 tcpserver -RHl localhost 23.0.0.1 8000 echo fnord host b: ifconfig eth0 10.0.0.2 route add 23.0.0.1 gw 10.0.0.1 telnet 23.0.0.1 8000 No ARP request or answer for 23.0.0.1 is involved at all. tcpserver is from ucspi-tcp, use any other method to quickly bind a service to 23.0.0.1 at your discretion. This appears not work for services bound to 127.0.0.1, as this appears to be magically hard-wired to 127.0.0.1 (setting lo to another IP and setting a static route did not make a TCP connection appear on eth0 for me). This means that I could not get telnet on host b to send packets destined for 127.* out over eth0. That should not hinder attackers using other operating systems or raw sockets to pull this attack off. Previously, when this issue was brought up, the canonical answer was to # echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden but this option is no longer available in recent 2.4 kernels. I put together an experimental patch for 2.4.18 at http://www.fefe.de/linux-eth-forwarding.diff Be warned, though, that it may be horribly broken (not tested for SMP or machines with more than one IP per interfaces). There is a Linux specific kludge^Whack^Wmethod to bind to an interface, but I am not aware of any software using it. If you have multi homed hosts and rely on a service bound to eth1 not being visible to eth0, you need to use netfilter or this patch! Felix