Why deploy a VPN inside an Azure Virtual Network?

Many organizations host applications and services in Microsoft Azure and still need per-user remote access, legacy application compatibility, or a way to present a static/dedicated public IP for client VPN connections. While Azure provides first-class site-to-site and point-to-site VPNs via Azure VPN Gateway, some use-cases—legacy clients, very specific management workflows, or compatibility with older third-party tooling—lead administrators to consider deploying a PPTP-based VPN on an Azure VM inside a Virtual Network.

Important upfront caveat

PPTP is an outdated and insecure protocol. Microsoft CHAPv2 has well-known vulnerabilities and no forward secrecy; traffic and passwords are susceptible to compromise. Azure’s native VPN Gateway does not offer PPTP as a built-in option. If your environment permits, you should favor modern, secure VPN protocols such as IKEv2/IPsec, SSTP, OpenVPN, or WireGuard. The guidance below explains how to deploy PPTP on Azure VMs when there is no alternative, and highlights security and operational constraints you must accept.

High-level architecture

  • Create an Azure Virtual Network (VNet) and subnet for the VPN server.
  • Deploy a VM (Windows Server with RRAS or a Linux instance running a PPP/GRE-capable server).
  • Assign a public IP directly to the VM (not behind an Azure Load Balancer) to enable GRE traffic.
  • Configure host-level firewall and VPN server, plus appropriate Network Security Group (NSG) rules.
  • Harden, monitor, and restrict access to minimize risks.

Technical constraints and Azure specifics

There are three Azure-specific constraints that determine whether PPTP can function correctly:

  • GRE (protocol 47) requirement: PPTP uses TCP/1723 for control and GRE (IP protocol 47) for the encapsulated PPP frames. Azure’s Load Balancer does not support forwarding GRE, so you must assign a public IP directly to the VM instance (instance-level public IP) or use a configuration that does not involve a load balancer in the data path.
  • NSG protocol filtering limitations: Azure Network Security Groups (NSGs) allow rules for TCP, UDP or Any. They do not allow specifying IP protocol 47 explicitly. To permit GRE, you must set an NSG rule to allow traffic (Protocol = Any) and then rely on host-level firewall controls to constrain GRE. This is less granular than ideal and increases the attack surface.
  • Azure VPN Gateway compatibility: Azure’s managed VPN Gateway does not support PPTP; you cannot enable PPTP for Azure P2S via the platform service. A VM-based approach is required if PPTP must be used.

Step-by-step quick setup (Windows Server RRAS example)

1. Prepare the Azure network

  • Create a Resource Group and a Virtual Network with a dedicated subnet for the VPN server (e.g., 10.1.0.0/24).
  • Create a Network Security Group (NSG) and associate it with the VPN subnet or VM NIC. For PPTP you will need a permissive inbound rule for GRE, so set Protocol = Any and Destination port ranges = 1723 (control). Minimize scope by specifying source IPs where possible.
  • Allocate an instance-level Public IP address and attach it directly to the VM NIC. Do not place the VM behind a Standard Load Balancer if you need GRE forwarded.

2. Create the VM

  • Deploy a Windows Server VM (2019/2022) with a size appropriate for the expected concurrent connections and encryption workload.
  • Ensure the VM’s NIC has IP forwarding enabled if you plan to route traffic through the VM to other subnets.
  • Do not enable Azure DDoS protection unless you understand its implications for your public IP and expected traffic patterns.

3. Configure Windows RRAS for PPTP

  • Install the Network Policy and Access Services role (Routing and Remote Access Service, RRAS).
  • Use the RRAS console to configure a VPN server supporting PPTP. In the RRAS setup, select “Custom configuration” and then “VPN access”.
  • On the server, configure a pool of private IP addresses that will be handed out to PPTP clients (e.g., 10.1.0.200–10.1.0.230) or integrate RRAS with Active Directory for user authentication.
  • Configure authentication settings. RRAS supports MS-CHAPv2; be aware it is weak—avoid storing long-term secrets that could be re-used across services.

4. Host-level firewall configuration

  • Open TCP port 1723 on Windows Firewall for inbound connections.
  • Allow GRE (IP protocol 47) on the host firewall. Windows Firewall allows protocol selection; add an inbound rule permitting protocol number 47.
  • Because Azure NSGs cannot filter GRE specifically, ensure the VM host firewall is the primary control for GRE traffic, and restrict source addresses where practical.

5. Test connectivity

  • From an external client, create a PPTP connection pointing to the VM’s public IP. Use credentials provisioned on the RRAS server.
  • Verify TCP/1723 connectivity (telnet or Test-NetConnection). Confirm GRE frames are accepted—troubleshooting GRE is often the sticking point in Azure deployments.
  • Check that client traffic is routed as intended (split tunnel vs. forced tunnel) and that DNS resolution works for the target resources.

Linux-based alternatives

If you prefer a Linux server, tools such as pptpd or more modern packages (pppd + gre/ppp kernel modules) can implement PPTP. The same Azure constraints apply: direct public IP on the VM NIC and host firewall rules must allow GRE. Because pptpd is similarly insecure and mostly unmaintained, consider OpenVPN or WireGuard on Linux instead, both of which work well behind Azure NSGs and can be fronted by Azure Load Balancer or Application Gateway if needed.

Security hardening and operational recommendations

  • Avoid PPTP if possible. If legacy clients mandate PPTP, isolate the VPN server in its own VNet/subnet and restrict access via NSG source IP filtering where you can.
  • Use strong credentials and rotation: enforce complex passwords, frequent rotation, and unique accounts per user. Consider combining with Azure AD Conditional Access for management accounts.
  • Monitor and log extensively: enable Windows event forwarding, Network Watcher NSG flow logs (note GRE won’t appear in NSG flow logs), and leverage Azure Sentinel or a SIEM to detect anomalies.
  • Network segmentation: place the VPN server in a DMZ VNet and use Network Virtual Appliances (NVAs) or UDRs to control routing between VNets and subnets.
  • Limit management plane exposure: use Azure Bastion for server console management rather than exposing RDP/SSH to the internet.
  • Failover and high availability: PPTP over Azure makes HA complicated because GRE cannot be load-balanced by Azure LB. Consider multi-region standby or DNS-based failover, but plan for stateful reconnection problems.
  • Audit and decommission: regularly review whether PPTP is still necessary and phase it out in favor of secure alternatives.

Troubleshooting common issues

  • PPTP connects but no traffic: usually GRE blocked. Verify host firewall rule for protocol 47 and that VM has the public IP directly attached.
  • Can reach TCP/1723 but cannot establish session: confirm RRAS authentication settings and MS-CHAPv2 configuration; check RADIUS authentication if used.
  • Intermittent drops: check for asymmetric routing or NAT issues—ensure return traffic from backend resources routes back through the VPN server when using forced tunneling.
  • Performance concerns: encryption and PPP overhead reduce throughput—choose an appropriately sized VM and monitor CPU usage. Consider non-PPTP options for higher throughput.

Recommended modern alternatives

For most use cases where a dedicated public IP and per-user client VPN is required, these are safer and better-supported choices in Azure:

  • SSTP (Secure Socket Tunneling Protocol): supported by Windows and can traverse most firewalls; uses TLS over TCP/443 so it avoids GRE issues.
  • OpenVPN: widely supported cross-platform, configurable on a VM or using third-party Marketplace appliances; works well with NSGs and load balancers.
  • IKEv2/IPsec or WireGuard: modern, efficient, and secure; WireGuard is fast and simple to configure on Linux-based appliances.

Deploying PPTP on Azure Virtual Networks is possible but comes with significant technical and security compromises. If you must proceed, follow the guidelines above: assign an instance-level public IP, configure RRAS or a Linux PPP server, allow GRE at the host layer, and implement rigorous logging and isolation. Whenever feasible, migrate users to a modern VPN protocol to protect credentials and data in transit.

For additional deployment patterns, security templates, and managed VPN options appropriate to Azure-hosted services, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.