LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Direct/Tunneling lvs and spoofing protection

To: Stephen Zander <gibreel@xxxxxxxxx>
Subject: Re: Direct/Tunneling lvs and spoofing protection
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 14 Mar 2000 12:53:41 +0200 (EET)
        Hello,

On 14 Mar 2000, Stephen Zander wrote:

> 
> Not yet subscribed to the list so please cc me...
> 
> I'v previously set up lvs as a redirector/firewall to a farm of web
> servers and NAT using the 0.8.3 patch against 2.2.12.  Everything went
> swimmingly; so far so good.
> 
> I moved on and am now seting up another lvs redirector/firewall
> configuration using 0.9.7 (as pakaged in Debian) and 2.2.13 and I
> cannot for the life of me get either IP tunneling or direct connection
> to work.
> 
> I don't think it's an lvs issue per se, because I can sniff packets
> coming into the rediretor, out the redirector, into the real box, and
> out the real box.  However, the packes are never being forwarded back
> out the redirector to the real world.
> 
        Yes, this is a routing issue.

> My immediate thought is that spoofing protection is somehow getting in
> the way as I have a host sourcing packets on the protected side with
> an address that matches a redirector interface on the public
> side.
> 


        Yep, in VS/NAT mode you use the Director as default
gateway for the real servers but for VS/DR and VS/TUN methods you
have to use transparent proxy in the Director to receive packets
for the VIPs. By this way if the Director thinks the VIP is not local,
the outgoing packets will be successfully forwarded to the client.
If the VIP is configured using ifconfig these packets are dropped
from the source address validation code in the Director.

        The source address checking is very restrictive. We can't
control via /proc/sys/net/ipv4/conf/*/rp_filter packets with
saddr=local_ip daddr=non_local_ip, i.e. forwarded packets, even
when we use two different network devices to distinguish the
source of the packet: real server or external client.

> Just to double check everything I've just brought the configuration in
> line with the direct routing example (with different addresses of
> course), and when I attempt to access the vhost/port from the
> redirector itself I get a connection refused message;when I attempt to
> connect from the outside my connection hangs.
> 
> Has anyone used direct routing or ip unneling with IP_FIREWALL=y
> configured in their kernel?

        Yes, but this is not the problem.

Regards

--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>



<Prev in Thread] Current Thread [Next in Thread>