Obstacle with direct routing

To: linux-virtualserver@xxxxxxxxxxxx
Subject: Obstacle with direct routing
From: Lars Marowsky-Bree <lmb@xxxxxxxxx>
Date: Tue, 29 Jun 1999 10:53:05 +0200
Good morning,

I found the following obstacle when playing around with direct routing mode.

Imagine the servers A and B behind the loadbalancer C, which is also the
gateway / firewall for those two. (Maybe doing NAT for non-virtualserver
traffic etc)

On C, the address is bound and direct-routed to A:80 / B:80.
Appears to work fine, no?

No. Since C has the address bound, it will not route traffic comeing
in from A / B with src adr The check is in net/ipv4/fib_frontend.c,
fib_validate_source() and is meant to protect against spoofing attacks.

I realize that direct routing is specified with an additional gateway out of
the network for the hosts, but I mainly wanted to get rid of the masquerading

So, I think we have three options:

1. Either point this out in the documentation and say that "this is the way it
is" and disallow my configuration. (I am not too fond of this;)

2. Modify fib_validate_source() to not log these packets as martians.

3. Make "direct routing" work in a transparent proxy kind of way which does
not require a locally configured IP alias.

Number 1 seems like burying our heads in the sand. Number 3 has a problem if
the virtual address comes from the external subnet of the loadbalancer or even
if we want to use the external address of the load balancer itself!

Anyone feels up to 2. ? I could take the full check out myself, but I think it
would be cleaner to add logic to allow src addresses which are to be expected
by the vs code.

    Lars Marowsky-Brée
Lars Marowsky-Brée
Network Management Netzdienste GmbH - DPN Verbund-Partner

<Prev in Thread] Current Thread [Next in Thread>
  • Obstacle with direct routing, Lars Marowsky-Bree <=