1

I'm currently exploring my options for running a client VPN server within Azure. I've examined the Point-to-Site VPN functionality, and it seems to be more of a method for administrators to dial in, rather than a fully-fledged client VPN solution.

One of the remaining options is to run a client VPN server within an Azure VM. Many of the client VPN options make use of IPsec in one way or another, which uses IP protocols other than TCP/UDP for operation (ESP/AH). As far as I can tell, Azure does not allow traffic other than TCP/UDP to your virtual machines. Endpoint-based ACLs only permit you to select TCP or UDP. I've just been investigating Network Security Groups (NSGs) in the hope they may offer a solution, but they also only offer 'TCP', 'UDP' or '*' as a protocol option within ACLs. This leads me to believe that it's not possible to run an IPsec server within Azure. Is this correct, or are there options available that I've not come across? Obviously there are options that only require TCP/UDP (Microsoft SSTP comes to mind), but specifically on the question of IPsec?

As a side-question, what other solutions have people settled on when it comes to providing a client VPN to resources hosted within Azure?

dbr
  • 1,812
  • 3
  • 22
  • 37

1 Answers1

3

You are correct, only TCP and UDP connections are allowed to Azure virtual machines; they are also severely limited, as in "you can only open single ports and not whole port ranges", which effectively disallows the use of dynamic protocols.

You can work around the latter limitation by using an instance-level public IP, which allows all traffic on all ports to a VM (but be sure to turn on your firewall!); however, this will still only allow TCP and UDP traffic.

The only supported option (at the present time) for client VPN connections is to use Azure's built-in client VPN service, which BTW works fine, as long as you can get a client certificate to each of your clients.

Also, as you said, another option could be using HTTPS tunneling for your VPN server instead of IPSec; HTTPS VPNs (including Windows' SSTP) run on TCP port 443, thus they actually could work on Azure VMs; however, if you want to run a VPN server on an Azure VM, you could run into all sorts of networking issues, because Azure VMs really don't play nice when you try to do something not explicitly supported, especially when networking is involved.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • That is a very bizarre limitation of the Azure firewall. I can't think of a good reason, technical or otherwise that they would do this. – EEAA Nov 08 '15 at 20:00
  • Wait, so ICMP is impossible as well? – EEAA Nov 08 '15 at 20:01
  • Azure has *lots* of crazyness in its networking; see here for some examples (including the links at the end of my own answer, which refer to two other questions): http://serverfault.com/questions/676867/error-adding-child-active-directory-domain-to-existing-forest. – Massimo Nov 08 '15 at 21:50
  • Re: ICMP: it works *inside* virtual networks, but I've never seen any Azure public IP address (VM or otherwise) ever answering a ping... – Massimo Nov 08 '15 at 21:51
  • 1
    Wow, that is *really* broken. – EEAA Nov 08 '15 at 22:26
  • 1
    Azure does allow port ranges to be included (I've just tested this) - the tooltip for destination input reads - "The destination port range can be a single port, such as 80, or a port range, such as 1024-65535." – Michael B Nov 09 '15 at 02:14
  • @MichaelB: If this is allowed now, it's a very recent update... and it isn't even mentioned in the documentation. – Massimo Nov 09 '15 at 02:52
  • I think it is a new feature with ARM security groups, they seem to be a lot more logically designed (let's hope we get to configure more protocols soon!) – Michael B Nov 09 '15 at 03:40
  • I really did think NSGs were going to be the answer as you're eliminating the Azure load balancer abstraction so you would think it would then be possible - sadly not! – dbr Nov 13 '15 at 20:42