|
Hello,
On Tue, 12 Feb 2002, Henrik Rossner wrote:
> > Do you mean cluster of VPN gateways behind LVS
> > router, LVS schedules the VPN clients to different
> > VPN gateways/servers?
>
> Yes, exactly - sorry, that it wasn't really clear.
> I just 'stole' the picture from Axel Kuester and modified it to my needs.
>
> 'target' subnets
> |
> +------------------+
> | Director A |
> +------------------+
> | |
> +--------------+ +--------------+
> | Real Server | | Real Server |
> | IPsec term. | | IPsec term. |
> +--------------+ +--------------+
> | |
> +------------------+
> | Director B |
> +------------------+
> |
> insecure connection e.g. Internet
> |
> +-----+------+
> | |
> +--------------+ +--------------+
> | IPSec term. | | IPSec term. |
> +--------------+ +--------------+
> | |
> +--------------+ +--------------+
> | many Subnets | | many Subnets |
> +--------------+ +--------------+
>
> I want to make it possible to have a secure connection from the 'many
> Subnets' to the 'target subnets'.
> Maybe one Director is enough, but I liked the approach with one Director
> for each direction.
I now understand
> > If yes, may be such setup will need a VPN
> > Masquerade software (ISAKMP+ESP) for NAT?
>
> I'm not sure, what you're talking about. Sorry. Where do you think the
> NAT could be?
If you prefer NAT support (it is not needed at all) you can
google for VPN Masquerading, also there is a HOWTO. I mean LVS-NAT
between Director B and its real servers. You don't need it.
> > May be it is possible by adding ESP support to LVS
> > to define fwmark-based persistent virtual service that can
> > forward ISAKMP and ESP to the right VPN gateway, all in LVS-DR
> > mode? May be even AH can work with LVS-DR? One client goes
> > only to one real server. I hope the ESP protocol is not difficult
> > to add in LVS. Any thoughts from the IPSec gurus on this list? :)
>
> Sounds like the direction I think of... Maybe Connection persistence is
> way too much - because each 'IPSEC term.' will support only one tunnel.
No, the persistence is needed to maintain 2 kind of connections
scheduled to same real server: ISAKMP (UDP:500) and ESP. The ISAKMP
conn will create the template for persistence, then the ESP connection
will be scheduled to the same RS. Without persistence the ESP
traffic will be scheduled to random RS.
> Would it be possible to do an IP based sheduling?
Yes, with persistence and by adding ESP/AH support to
LVS.
> > How exactly you want LVS and Freeswan to cooperate?
> is the picture enough information?
Yes, thanks. But I'm not sure, if your clients access the
real servers using IPSec tunnel mode how the target nets (or
Director A if LVS-NAT is used for its cluster) will know
to route the replies to the right IPSec gateway (IPSec RS) for
encryption, for example, they need to resolve the route
"from target_subnet to universe" via different gateways. May be
each real server should use SNAT after decryption (we should
fix LVS not to skip postrouting in out->in direction and to
allow SNAT but this should be analyzed, TODO for the next
design)? Something like this, am I missing something? Comments?
> Henrik.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
