CentOS - Oct 2009 - Reply to ICMP echo request (type 8) on different (ethernet) interface

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

I have a weird (?) problem here on a setup running CentOS 5.3 x86_64
(and OpenVZ, and some home-brew L2TP daemons, RIPd, BGPd, etc).

There's a (VE in OpenVZ speak) virtual machine that has two ethernet
interfaces, seen as eth0 and eth1, respectively. Those live in VLANs,
but it's not important here.

The thing is that on eth1 the default route lives, while on eth0 all
traffic comes in.

So, sending a ping to the IP address of eth0 tcpdump shows that the echo
request (type 8) packet arrives on the machine. However, the machine
does _not_ send an echo reply (type 0) back to the machine that pings
eth0, maybe because it would have to emerge from eth1.

One exception (an obvious one) is that IPs on the /29 where eth0 lives
on _can_ ping eth0 and receive an answer -- this is because the packets
don't have to take 'the default route', which lives on the other
interface, eth1.

This seems to me like decent behaviour.

However, I really need eth0 to be able to be pinged from the outside
world, it's totally okay for me that eth1 would 'answer' and send
the
echo replies instead of eth0.

Is there anything I can tweak (via sysctl or whatever)?

TIA,

Timo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org/

iD8DBQFKxOC0O/2mgkVVV7kRAgjGAJ9B292FpBzUSS3rpUcZgPE+utWn5wCglptc
dNUSD4i4iF4KaAiG1+jFdeg=QTM+
-----END PGP SIGNATURE-----

On Thu, Oct 1, 2009 at 2:02 PM, Timo Schoeler
<timo.schoeler at riscworks.net>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi list,
>
> I have a weird (?) problem here on a setup running CentOS 5.3 x86_64
> (and OpenVZ, and some home-brew L2TP daemons, RIPd, BGPd, etc).
>
> There's a (VE in OpenVZ speak) virtual machine that has two ethernet
> interfaces, seen as eth0 and eth1, respectively. Those live in VLANs,
> but it's not important here.
>
> The thing is that on eth1 the default route lives, while on eth0 all
> traffic comes in.
>
> So, sending a ping to the IP address of eth0 tcpdump shows that the echo
> request (type 8) packet arrives on the machine. However, the machine
> does _not_ send an echo reply (type 0) back to the machine that pings
> eth0, maybe because it would have to emerge from eth1.
>
> One exception (an obvious one) is that IPs on the /29 where eth0 lives
> on _can_ ping eth0 and receive an answer -- this is because the packets
> don't have to take 'the default route', which lives on the
other
> interface, eth1.
>
> This seems to me like decent behaviour.
>
> However, I really need eth0 to be able to be pinged from the outside
> world, it's totally okay for me that eth1 would 'answer' and
send the
> echo replies instead of eth0.
>
> Is there anything I can tweak (via sysctl or whatever)?
>

You need a way to tell that packets originating from eth0 destined outside
should be routed to eth0. This thread should help:

http://lists.centos.org/pipermail/centos/2009-January/070828.html

Giovanni P. Tirloni
tirloni at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos/attachments/20091001/35021e4c/attachment-0002.html>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

thus Giovanni Tirloni spake:
| On Thu, Oct 1, 2009 at 2:02 PM, Timo Schoeler
| <timo.schoeler at riscworks.net>wrote:
|
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi list,
|>
|> I have a weird (?) problem here on a setup running CentOS 5.3 x86_64
|> (and OpenVZ, and some home-brew L2TP daemons, RIPd, BGPd, etc).
|>
|> There's a (VE in OpenVZ speak) virtual machine that has two ethernet
|> interfaces, seen as eth0 and eth1, respectively. Those live in VLANs,
|> but it's not important here.
|>
|> The thing is that on eth1 the default route lives, while on eth0 all
|> traffic comes in.
|>
|> So, sending a ping to the IP address of eth0 tcpdump shows that the echo
|> request (type 8) packet arrives on the machine. However, the machine
|> does _not_ send an echo reply (type 0) back to the machine that pings
|> eth0, maybe because it would have to emerge from eth1.
|>
|> One exception (an obvious one) is that IPs on the /29 where eth0 lives
|> on _can_ ping eth0 and receive an answer -- this is because the packets
|> don't have to take 'the default route', which lives on the
other
|> interface, eth1.
|>
|> This seems to me like decent behaviour.
|>
|> However, I really need eth0 to be able to be pinged from the outside
|> world, it's totally okay for me that eth1 would 'answer' and
send the
|> echo replies instead of eth0.
|>
|> Is there anything I can tweak (via sysctl or whatever)?
|>
|
|
| You need a way to tell that packets originating from eth0 destined outside
| should be routed to eth0. This thread should help:
|
| http://lists.centos.org/pipermail/centos/2009-January/070828.html
|
| Giovanni P. Tirloni
| tirloni at gmail.com

Thank you very much, Giovanni -- seems exactly to be what I need.

Cheers,

Timo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFKxajhfg746kcGBOwRAgIuAJ9FYy4k5mDBXcOp8J1RHt5b4WtcVgCghlFh
5QZ4PQchWB1By/D50zDjJHo=UEjy
-----END PGP SIGNATURE-----