|
Hello Julian,
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.
And you also need to fwmark the packets if I get the picture.
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?
For LVS-NAT and ESP it would be crucial to have a POSTROUTING or you
won't see your packets anymore, which can also be kind of a security :)
Happy hacking,
Roberto Nibali, ratz
|
