|
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
| 