This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Active/Active HA for VPN Connections?

Hi,

does anybody have experiences with a scenario with two astaros
in two premises in load balanced mode?
We would like to handle quite a number of VPN connections with two FWs, 
that should work load balanced usually, but if one fails the remaining
box should take over all connections.

As far as I have read, ASG does real active/active only with certain protocols
(http, ftp, ...)

But most of the docs refer to V7, date back from 2010 and older.

So what can V8 do actually now, what will it be able to do soon?

Best Regards


This thread was automatically locked due to age.
  • We have an experience with a scenario of 1 ASG 8.103 in active-active mode (2 nodes) and a lot of small ASGs connecting to it via IPSec.
    Our tests show that shutting down one node does not harm IPsec tunnels much.

    However, some issues (in general, not only with HA) may arise when using unusual IPsec routing and also with Dead Peer Detection.
  • does active-active in your setup mean, that the traffic is really load balanced between the nodes when both are up? As I understand the docs so far I'd expect the traffic to run over the active node only. Or is astaro better than the official docs in the meantime?
  • Yes, it is load-balanced between nodes.

    What you describe as "run over the active node only" is called active-passive.
  • If you run the ASG in Cluster Mode, IPSec distribution is packet based. So even if you only have one IPsec connection, you have increased IPSec throughput [:)]

    However IKE key exchange is still completely handled by Master node.

    BTW: Cluster mode distributes also HTTP, FTP, SMTP, POP3 and IPS connections.

    Cheers
     Ulrich
  • does this "true load balancing" only work with "advanced virtual mac" (cc set ha advanced virtual_mac 1) ?

    We set this parameter to 0 because of vmware restrictions, maybe this influences our test results?
  • @undel
    when you watch the traffic in an active/active scene you see that all client traffic is directed to the master node. Then master then distributes data packets for CPU intense things like virus scanning via the heartbeat link to the slave/worker.
    In this sense all client traffic goes via the master. And this is not what I would like to have regarding our two premises.
    I'd prefer the client traffic ditributed to both machines.
  • virtual_mac will not affect the clustering. BTW: You can allow your VMWare machines to set any MAC you want, thats a VMWare security option which can be disabled for each VMWare machine.

    Yes, all traffic is received by Master Nodes, distributed to other nodes and then send by Master node again. Can you name me a vendor which sends/receives traffic on all nodes? This can only be archived if:

    a) you broadcast the traffic via Multicast MAC addresses. You don't get much benefit here, all nodes will receive the whole traffic and are busy processing them if the traffic is for them...

    b) Different MAC addresses for each Node, clients will only see one node then. Balancing is quite static. One client can not benefit from the Cluster Performance.

    You can archive b) if you setup an external Load Balancer and run all ASG nodes in standalone mode

    Cheers
     Ulrich
  • again: my primary goal is the traffic balacing between different premises, assuming, that
    moving traffic from one premise to the other costs much (round trip time e.g., let's assume, there is no dark fiber between the buildings available, but some ATM or MPLS connection)

    But I want to see both premises as one for the outer world, 'cause they build one
    Autonomous System.

    ok, a) cannot be done so easily, it requires full multicast support from the client's IP stack, doesn't it?

    b) I agree with your arguments. 

    Let me suggest a technical solution (enhanced active/active cluster):
    1) both firewalls have their own IP and MAC, but they know each other via a heartbeat line.
    2) clients get one of those IPs statically assigned as their default gw, so you have a static balanced load in the first run, as you state.
    3) to prevent split routing problems, the conntrack tables between the cluster nodes have to be synchronised. This could be achieved in real time by copying each incoming IP packet to the other machine, giving it a tag "this is a informational copy only".
    This copy should be processed for the connection tables quite normally, only before sending it out on the physical interface this copy bit should be considered: in case it is set, this is a copy packet and *must* not be sent.
    4) both machines could give each other "load statistics". So if one has nothing to do and the other is heavy breathing, then some load sharing could take place as ASG does it now.
    5) if one box failes, the other box would have to take over the IP from the failed box as additional IP

    What do you think about this idea/concept?
  • ok interesting idea [:)]

    a) No, there are no requirements from client side. The router answers ARP request with an Multicast MAC address instead of a unicast MAC address. I think its not RFC conform but should with all clients.

    b) Having different IP addresses is to intrusive to our HA/Cluster implementation. There are to few use cases and would increase complexity for most of our customers.

    Whats the network topology of your setup? Do your premises have different subnets and Internet access?

    If yes, having standalone nodes makes more sense for me. You could abuse the feature "Internet Monitoring". You can set hosts to be monitored and define Actions, e.g. to enable/disable additional addresses. So each Node monitors the other and if one nodes fails, the other node enables the additional address...

    Cheers
     Ulrich
  • We would like to handle quite a number of VPN connections with two FWs, 
    that should work load balanced usually, but if one fails the remaining
    box should take over all connections.

    Although it wouldn't do an immediate fail-over, it seems like you could configure round-robin DNS to achieve your stated goal.  Clustering-at-a-distance doesn't seem like something I would recommend.

    Cheers - Bob