OnPremise to Azure Domain Based VPN Redundancy

[JoSec]

I had an issue when setting up a route-based VPN to Azure when I enabled the Checkpoint VTI interfaces, all inbound traffic had intermittent connectivity but the site to site VPN traffic was fine and I have opened case for the issue.
As an alternative, I am now looking at the possibility of using a domain based VPN to utilize the two connections into Azure especially since finding out QOS is not supported on VTI interfaces. Is it as simple as having both Azure VPN Gateway remote peers in the VPN community and enabling DPD? How do I select which tunnel is active and which is the standby? Thanks

[_Val_]

@Shay_Levin Anything you can advise here?

[Shay_Levin]

HI, 

What is the topology?

Single gateway with two external interfaces?

[JoSec]

Update: I attempted to utilize MEP and add our on premise cluster as the Satellite Gateway and the two Azure VPN Gateway Interoperable objects as the Center Gateway's. It worked but was not stable in that I would be able to communicate to a resource from one environment to the other and then communication would fail and within minutes could start working again. Also, I would be able to connect to a resource from one system and it would fail from another system and start working for that system later. I did make many modifications to the VPN community in regards to the MEP policy to see if one option would resolve the issue but it did not. I also ran a vpn debug which I reviewed with TAC which showed no issue with the tunnel creation and did show the DPD communication from Azure to the on-premise gateways. It is noted in sk101275 for a domain based VPN that DPD is not supported though the capture shows Azure sending a DPD HELLO and the on premise gateway responding with a DPD ACK and this occurred every 10 seconds.

I have reached to out my SE regarding the issue with QOS not being supported when using VTIs, noted by sk36157, which means I cannot utilize a route based VPN config to connect to Azure and use QOS on the gateways. Since this limitation exists, it would be good to have an alternate method to connect to an Azure VPN Gateway configured with active/active tunnels that is supported. In the meantime, I have defaulted to the standard domain based tunnel which at least Azure by default uses and Active/Standby config for the vpn gateway.