0

I've been struggling with some practical limitations on Azure and some on-premise infrastructure. I setup a VNET on Azure and needed to connect via Site-to-Site VPN to 4 different on-premise locations.

Naturally, I chose a route-based VPN which could support multi-site connections, but it turns out that one or more of these on-premise VPN devices support only static (policy based) IKEv1 setup. It won't be a problem if I can create a policy based VPN and connection to each client on the VNET but apparently I can only have one VPN per VNET.

What options do I have to be able to connect to these various on-premise locations? Will I need to create multiple VNETs, connect each VNET to an on-premise location with a VPN and join the VNETs with VNET-VNET connection? Is this even possible even though it's becoming messy just typing it.

Appreciate all the help I can get now.

keni
  • 139
  • 2
  • 10

1 Answers1

1

[UPDATE 31/08/2017] The below is not completely accurate anymore.
Now you can have multiple policy-based connections (IKEv2 only!) and P2S, Vnet to Vnet, etc on the same gateway. You'll need to deploy one of the new SKUs (VpnGw1, VpnGw2, VpnGw3).

E.g. https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps

You can't do Vnet to Vnet with a policy-based gateway, so that's not an option either.

These are probably your best alternatives:

  • Deploy a Network Virtual Appliance (NVA) in the VNet (all major network security vendors have options in the Marketplace) and use that in conjunction with UDR to establish S2S VPNs with all your on-premises locations.
  • Deploy a Linux VM and configure your own VPN gateway with some available IPSec software like StrongSwan or similar.
  • Use one of the on-premises locations as a VPN hub in a hub and spoke architecture, where the Azure Vnet is one of the spokes. This way you only need one VPN connection between Azure and on-premises, but you still can reach any on-premises locations.
  • You could also do a sort of hybrid architecture where any on-premises location that is only compatible with a policy-based VPN is connected to another on-premises location that can do route-based VPN, so you end up having >1 tunnels between Azure and on-premises to not centralize all traffic in one location and to keep all the features a route-based gateway offers (more SKUs, Point to Site VPN, BGP, Coexistence with ExpressRoute, etc) - you could even take advantage of the BGP capabilities and add redundancy to your tunnels to on-premises.

(Disclosure: I work for Microsoft in Azure)

Hope this helps!

Pedro Perez
  • 6,202
  • 1
  • 11
  • 11
  • Thanks. The last 2 options (doing anything on-premise) is not feasible for me, I have zero control over those. Yes, I had thought of using OpenSwam so thanks a lot for mentioning Strongswan. I have a feeling you put the NVA first for good reasons, so let me explore that first. – keni Jan 27 '17 at 06:29