Secure remote access remains a core requirement for modern organizations that host services and infrastructure in Azure. While OpenVPN has become the cross-platform favorite, SSTP (Secure Socket Tunneling Protocol) still provides a simple, robust option for Windows-centric environments because it natively runs over TCP/443, works through most firewalls and proxies, and integrates well with Windows authentication and certificate systems. This article walks through practical approaches to provide SSTP-based VPN access into Azure virtual networks, including Azure-native point-to-site (P2S) SSTP configuration, and an alternative architecture that uses a VM-based Windows RRAS server to terminate SSTP inside a VNet. You’ll get configuration steps, PowerShell commands, certificate guidance, and operational considerations suitable for site owners, enterprise administrators, and developers.

When to choose SSTP in Azure

SSTP is appropriate when your client base is primarily Windows and you need a connection that traverses restrictive networks (e.g., captive proxies, strict NAT), because SSTP uses TCP port 443. Consider SSTP when:

  • You require native Windows client support without installing third-party VPN software.
  • Your environment uses certificate or RADIUS authentication and does not require Azure AD auth for P2S.
  • You need a quick fallback for legacy clients or highly restrictive networks.

Note: Azure’s P2S VPN supports SSTP and OpenVPN. However, Azure AD authentication is only supported for OpenVPN and IKEv2. For SSTP, authentication options are certificate-based or RADIUS-backed.

Option A — Configure Azure P2S VPN using SSTP (certificate-based)

This approach uses the Azure VPN Gateway to terminate P2S SSTP sessions and is the simplest operational model because Azure manages the gateway appliance. It is ideal for smaller deployments that do not require custom routing appliances inside the VNet.

Prerequisites

  • An Azure virtual network and subnet(s).
  • An Azure VPN Gateway (Route-based) with SKU that supports P2S (e.g., VpnGw1 and above).
  • A PKI root certificate (self-signed for test; enterprise CA for production) and per-client certificates.
  • Azure PowerShell Az module or Azure Portal access.

High-level steps

  • Create/obtain root CA certificate and generate client certificates.
  • Create Azure VPN Gateway (Route-based), configure P2S address pool and authentication (certificate), and enable SSTP.
  • Upload the root certificate public key (.cer) to the VPN Gateway’s configuration.
  • Download the VPN client package and distribute to Windows clients.

Certificate creation (example using PowerShell)

For lab/test environments you can create a self-signed root and client certs using New-SelfSignedCertificate on a Windows machine:

  • Create root certificate in the machine or user store:

New-SelfSignedCertificate -Type Custom -KeyExportPolicy Exportable -Subject "CN=ContosoRootCA" -KeyUsageProperty Sign -KeyUsage CertSign -KeyLength 2048 -NotAfter (Get-Date).AddYears(10) -CertStoreLocation "Cert:CurrentUserMy"

  • Export the root public cert (Base-64 .cer) to upload to Azure.
  • Create a client certificate signed by the root and export it (PFX) for client import into Windows certificate store.

Provision Azure VPN Gateway and upload root cert

Using Azure Portal or PowerShell, create a VPN Gateway with the P2S configuration. Example PowerShell snippet (assumes existing virtual network and gateway subnet):

$gw = New-AzVirtualNetworkGateway -Name 'VpcGateway' -ResourceGroupName 'RG' -Location 'eastus' -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1 -VpnClientProtocol 'Sstp' -IpConfigurations $ipconfigs

Upload the root .cer public key to the gateway’s P2S configuration. In the portal: VPN gateway > Point-to-site configuration > Configure > Authentication type: Certificates > Add root certificate (paste .cer content or upload).

P2S address pool, routes and client download

  • Define a P2S client address pool (e.g., 172.16.201.0/24) that does not overlap VNet or on-prem addresses.
  • Optionally configure DNS servers for clients (custom DNS to resolve internal names).
  • Save configuration and download the VPN client package for Windows from the portal (it contains an .xml profile and installer).

Client setup

  • Install the client certificate (PFX) into Local/Current User > Personal store.
  • Install the Azure VPN client package and import profile or use built-in Windows VPN profile.
  • Connect — the SSTP session will negotiate over TCP/443 to the gateway’s public IP.

Option B — Deploy a Windows RRAS VM in a VNet to provide SSTP

When you need richer control over authentication, custom policies, or gateway functionality (e.g., use LDAP/Active Directory authentication, NPS RADIUS on the same VM, or integration with third-party appliances), host a Windows Server VM running RRAS and terminate SSTP there. This is also how to support SSTP for S2S-like topologies or when you cannot use Azure’s managed gateway for SSTP for business reasons.

Architecture overview

  • A Windows Server VM (multiple for HA) in a dedicated gateway subnet within the VNet.
  • Public IP(s) on Azure load balancer (if HA needed) that forwards TCP/443 to RRAS VMs.
  • Network Security Group allows inbound TCP/443 and outbound required ports.
  • Certificates: machine certificate with subject/subjectAltName matching the public DNS name of the gateway (used by SSTP).

Steps to configure RRAS SSTP

  • Provision a Windows Server VM and join it to your AD domain (if using AD auth).
  • Install the Network Policy and Access Services role and configure RRAS for VPN access (Routing and Remote Access).
  • Install an SSL server certificate into the Local Computer Personal store (subject name = gateway DNS name).
  • Enable SSTP in RRAS and bind to the installed certificate.
  • Configure NAT or UDR to ensure return traffic routing to the RRAS VM if using custom routing appliances. If the RRAS VM is the default gateway for its subnet, configure IP forwarding appropriately.
  • Configure authentication — either Windows accounts, NPS/RADIUS or certificate-based client authentication.

Load Balancing and HA considerations

For availability, use an Azure Standard Load Balancer with a Public IP and a backend pool of RRAS VMs. Health probes should target a TCP-based health endpoint (custom port/endpoint) because TCP/443 sessions are stateful — ensure probe settings and session persistence (source IP affinity) are correct to avoid session drops.

Network and security considerations

Packet path and ports: SSTP uses TCP/443 — ensure NSGs and any on-prem firewalls permit outbound/inbound TCP/443. For VM-based RRAS, also permit management ports (RDP/WinRM) from trusted source IPs only.

Routing and split tunneling: Decide between split tunneling (client only routes traffic to internal address spaces via the tunnel) and forced tunneling (all client Internet traffic goes through the VNet). Azure P2S supports setting the “use default gateway on remote network” via client profile options; for RRAS you control this via RRAS policies or the connection profile. Forced tunneling requires proper UDRs and NAT to route internet-bound traffic to your NVA/Internet egress.

MTU and performance: SSTP encapsulates PPP over HTTP encapsulation which can reduce effective MTU. For large transfers consider adjusting MTU/MSS on client and server to avoid fragmentation. Monitor throughput on the Azure gateway SKU limits or VM NIC bandwidth.

Monitoring and diagnostics: Enable diagnostics on the Azure VPN Gateway and collect RRAS logs on Windows servers. Use Network Watcher for packet captures, NSG flow logs, and Azure Monitor metrics for gateway/VM performance.

Troubleshooting common issues

  • Connection fails to establish: Verify the public IP/DNS resolves and that port TCP/443 is reachable from the client (telnet, Test-NetConnection).
  • Authentication errors: Check certificate chain trust — client certs must be issued by a root uploaded to Azure gateway for P2S certificate auth. For RRAS, ensure the server certificate subject matches the endpoint name clients use.
  • Routes inaccessible: Confirm P2S address pool doesn’t overlap VNet or on-prem networks and check UDRs and BGP (if S2S present) for conflicting prefixes.
  • Intermittent drops: On Azure LB setups, ensure session persistence and correct probe settings; on Azure VPN Gateway, check SKU limits and concurrent connection quotas.

Security best practices

  • Use an enterprise PKI for production certificates and rotate them periodically.
  • Harden RRAS VMs: patching, limited management access, endpoint protection, and monitoring.
  • Use conditional access and MFA where possible; if you require MFA, consider a hybrid approach (e.g., SSTP for basic connectivity, and multi-factor checks via VPN auth servers or jump hosts).
  • Segment management networks and enforce least privilege for VPN users.

Conclusion and recommended approach

For most Windows-centric, lightweight P2S needs, using Azure’s managed VPN Gateway with certificate-based SSTP offers the simplest deployment path with minimal operational overhead. If you need deep customization (enterprise authentication integration, complex routing, or hosting your own policies), deploying RRAS in a VNet behind an Azure load balancer gives full control at the cost of more management.

Regardless of the method you choose, plan certificate lifecycle, routing/UDR carefully, and validate client DNS and authentication flows before wide rollout. For further resources and configuration examples, you can review Azure docs and test in a non-production subscription first to fine-tune MTU, split tunneling, and authentication settings.

Article published by Dedicated-IP-VPN. Visit us at https://dedicated-ip-vpn.com/ for more guides and services.