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
On C, the address 22.214.171.124:80 is bound and direct-routed to A:80 / B:80.
Appears to work fine, no?
No. Since C has the address 126.96.36.199 bound, it will not route traffic comeing
in from A / B with src adr 188.8.131.52. 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.
teuto.net Netzdienste GmbH - DPN Verbund-Partner