Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 2 subscribers
  • Views 5001 views
  • Users 0 members are here
Options
Suggested
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?

paule
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.
Parents
  • 0
    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
  • 0 in reply to BAlfson
    well, our current state of discussions:
    in each premise terminates on internet uplink (different providers), so we have two
    BGP speaking uplink routers and an AS of our own.

    One link connects the BGP routers directly, and over an IP over IP tunnel they talk their iBPG session and traffic is sent that will have to leave via the other uplink.
    The tunnel is needed if this direct link has to be moved to a backup line.

    Towards the internal net OSPF will be spoken. 
    In each premise one firewall will be located, and now we think about without HA on the firewalls.
    From each fw there is a direct link to an other router: there terminates the OSPF area.
    These two routers/gates to the DMZ do something like da_merlin suggested: they watch each other, and if
    the mate is missing, it's IP comes up on the "lonely box".

    There is one unique DMZ for both premises, connected internally via dark fiber with a backup line of different physics. Each DMZ server has its gateway assigned statically, and if this fails: see above, the remaining will have the requested IP.

    With statically injected routes for the hosts in the local premise we think we can
    force the packets to use only one way forth and back, so conntrack will not fail.

    ok, some details I left out, but hopefully you can imagine our current idea to solve the task.

    Any suggestions, remarks, enhancements, warnings, critics are welcome, as well as questions ;-)
Reply
  • 0 in reply to BAlfson
    well, our current state of discussions:
    in each premise terminates on internet uplink (different providers), so we have two
    BGP speaking uplink routers and an AS of our own.

    One link connects the BGP routers directly, and over an IP over IP tunnel they talk their iBPG session and traffic is sent that will have to leave via the other uplink.
    The tunnel is needed if this direct link has to be moved to a backup line.

    Towards the internal net OSPF will be spoken. 
    In each premise one firewall will be located, and now we think about without HA on the firewalls.
    From each fw there is a direct link to an other router: there terminates the OSPF area.
    These two routers/gates to the DMZ do something like da_merlin suggested: they watch each other, and if
    the mate is missing, it's IP comes up on the "lonely box".

    There is one unique DMZ for both premises, connected internally via dark fiber with a backup line of different physics. Each DMZ server has its gateway assigned statically, and if this fails: see above, the remaining will have the requested IP.

    With statically injected routes for the hosts in the local premise we think we can
    force the packets to use only one way forth and back, so conntrack will not fail.

    ok, some details I left out, but hopefully you can imagine our current idea to solve the task.

    Any suggestions, remarks, enhancements, warnings, critics are welcome, as well as questions ;-)
Children
No Data