load balancing between firewall/vpn boxes

[Matthias Weidle]

>> the response would pass DR2 who
>> thinks that this packet is for a new ip flow and therefor choses one of 
the
>> 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
>you understand).

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 
host
>> 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
>packets transparently.

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 
it took
>to get there. It only has the destination IP and the source IP (the 
client's IP)
>to identify it. If the fw started a proxy session with its own IP's and 
sent
>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 
box).

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! :)

best regards,
-- matt.


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 
replies :))


>> is there any way to tell DR2 to remember where the initial packets came
>> from?

>From what I understand of this setup at the moment, no.
>
>Joe