load balancing between firewall/vpn boxes
matt at box.li
Mon Jan 29 15:21:53 GMT 2001
>> the response would pass DR2 who
>> thinks that this packet is for a new ip flow and therefor choses one of
>> boxes according to the configured strategy.
>I don't understand this sentence. What does "pass DR2" mean?
>The connect request packet from A will go through DR-1, fw, DR-2 and arrive
>on host B. The response from B will go to its default gw (which it seems
all the hosts on the internal LAN have DR2 as their default GW. hence the
response from B to A will go through DR2 which in turn has to make a
decision which fw box has to be used.
for the lvs config that means that we have to configure one VIP on each lvs
director: the first VIP for the fw cluster seen from the outside and one
VIP for the cluster as seen from the inside. (to be exactly: the internal
fw VIP is the default GW address for the internal hosts)
>> and this is definitly _not_
>> what you want to happen here! the expected behaviour for this setup would
>> be to forward the packet from host B to the box where the traffic from
>> A arrived in the first place.
>I assume this means fw-1, fw-2, fw-3?
exactly. if the connection setup packet goes through dr1-fw1-dr2 i want the
response packet to go the same way backwards ...
>I'm assuming that the fw boxes (after doing their checking) as just passing
well, more or less: yes.
source and destination ip's won't be changed by the firewall.
the main reason that i need persistant connections in both ways is the vpn
software installed on the fw boxes:
if A wants to talk to B it first has to establish a secure tunnel to one of
the fw boxes. then the secure traffic can be passed through that very
tunnel to the internal host B.
since the fw boxes don't share any keys i have to go sure that the backward
traffic from B to A goes through that box too!
>When the connect request arrives at B, there is no evidence of the route
>to get there. It only has the destination IP and the source IP (the
>to identify it. If the fw started a proxy session with its own IP's and
>them to DR-2 then you could put 3 VIPs on DR-2.
no, its no proxy session. you still have the src=A, dst=B when the packet
arrives on host B. therefor the only point to remember the path (i.e. which
fw box) the incoming packet to host B took is on DR2.
here are my thoughts how this could be done by the lvs code:
if a packet arrives on DR2 the lvs code has to inspect if the src MAC
address of this packet is one of the known fw boxes. if that is the case it
doesn't have to do any load balancing decision, it only has to remember the
src and dst ip of that packet together with the MAC address of the fw box
in some internal table.
if the src MAC address of the incoming packet is not any of the configured
fw boxes, then the packet came from the attached internal LAN and a load
balancing decision has to be made if there is NOT yet an entry in the
connection tracking table. if we already got a matching entry (same src and
dst ips) we have to use the already associated fw box for this connection
(means forwarding the packet for further processing to the MAC of the fw
of course the same logic has to be applied to DR1 in case of connection
setup from the internal LAN to the outside internet :)
i hope i could bring some more light in that issue! :)
PS: since i am subscribed in digest mode to this mailing list ... could you
please do a CC to my mail address when answering? would be easier to make
>> is there any way to tell DR2 to remember where the initial packets came
>From what I understand of this setup at the moment, no.
More information about the lvs-users