Secure remote access remains a top priority for site owners, enterprises, and developers. Secure Socket Tunneling Protocol (SSTP) is attractive because it tunnels VPN traffic over TLS (TCP/443), easing firewall traversal and permitting native Windows clients to connect without extra software. However, username/password authentication alone is no longer sufficient. Adding Multi-Factor Authentication (MFA) dramatically reduces account compromise risk. This guide offers a detailed, step-by-step technical walkthrough to deploy SSTP VPN with MFA—covering server prerequisites, certificate handling, RRAS/NPS configuration, and integration with popular MFA providers like Azure AD MFA and Duo.

Why use SSTP with MFA

SSTP encapsulates PPP frames inside an SSL/TLS channel, effectively using port 443 to pass VPN traffic. That makes it resilient to strict network policies and easy for end users—especially Windows clients. But relying solely on passwords leaves you vulnerable to phishing and credential stuffing. Adding MFA:

  • Provides a second proof of identity (TOTP push, phone call, SMS, hardware token, FIDO).
  • Enables conditional access in many identity ecosystems (Azure AD, Okta).
  • Preserves compatibility with native clients: the user still authenticates via their primary credentials while a back-end RADIUS/NPS flow enforces MFA.

High-level architecture

A typical deployment consists of:

  • SSTP server (Windows Server running RRAS) exposed on TCP/443 with a valid TLS certificate.
  • Network Policy Server (NPS) acting as the RADIUS endpoint for RRAS.
  • An MFA provider or gateway: Azure AD NPS extension, Duo Authentication Proxy, or a third-party RADIUS MFA server.
  • Client devices (Windows, macOS via third-party clients if needed).

Prerequisites

  • Windows Server (2016/2019/2022) with administrative privileges.
  • Publicly trusted TLS certificate (wildcard or SAN) matching the VPN FQDN (e.g., vpn.example.com).
  • Public DNS A record for your VPN FQDN and TCP/443 reachable at the server’s public IP.
  • NAT/firewall rules: forward TCP 443 to the SSTP server.
  • Azure AD tenant or MFA provider account (Duo, Okta, etc.) and knowledge of RADIUS integration steps for your choice.
  • Basic knowledge of Active Directory if using domain authentication.

Step 1 — Install and configure RRAS for SSTP

Install the Remote Access role and enable Routing and Remote Access Service (RRAS):

  • Open Server Manager → Add Roles and Features → Remote Access → check DirectAccess and VPN (or Remote Access with VPN).
  • You can also use PowerShell:

    Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools

    Install-WindowsFeature -Name Routing -IncludeManagementTools

  • Launch the Routing and Remote Access MMC, right-click server → Configure and Enable Routing and Remote Access → Choose Custom Configuration → VPN access. Start the service.

Ensure RRAS is configured to accept SSTP connections. In RRAS properties (IPv4 > General), configure the external interface (public-facing) and assign public IP/NAT rules as needed.

Step 2 — Install and bind the TLS certificate

SSTP requires a certificate whose subject or SAN matches the VPN DNS name. Use a certificate issued by a public CA (Let’s Encrypt, DigiCert, etc.).

  • Import the certificate into Local Computer → Personal store. Ensure the private key is present and marked exportable if you plan to copy it later.
  • Bind the certificate to the SSTP service. SSTP leverages HTTP.sys; on servers that run IIS you must ensure the certificate is associated properly. To bind manually:

    netsh http show sslcert to view bindings and netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint> appid=<GUID> to add.

  • Important: Avoid certificate mismatch errors—if the RRAS server sees a different cert than the client expects, the TLS handshake fails. Verify the certificate chain and CRL/OCSP accessibility from the client network.

Step 3 — Configure NPS as RADIUS

Use Network Policy Server (NPS) to centralize authentication and to forward authentication requests to your MFA provider.

  • Install NPS: Server Manager → Add Roles and Features → Network Policy and Access Services → Network Policy Server.
  • Open NPS console → RADIUS Clients → New. Add RRAS server (IP, shared secret).
  • Configure Connection Request Policies and Network Policies:
    • Connection Request Policy: Match NAS Port Type = Virtual (VPN) and Vendor = Microsoft. Forward to authentication servers if using an external proxy.
    • Network Policy: Match Windows Groups (e.g., VPN Users), Authentication Methods = MS-CHAP v2 or EAP as required, and configure constraints/conditions like day/time or machine certificate checks.

Configure the shared secret carefully—this is used by RRAS to communicate with NPS.

Step 4 — Integrate an MFA provider

There are two common integration patterns: NPS extension for direct Azure AD MFA, or a RADIUS proxy/agent for third-party MFA.

Option A — Azure AD MFA with NPS extension

  • Requirements: Azure AD Premium P1/P2 and an Azure AD tenant. Install the NPS extension on the NPS server.
  • Procedure:
    1. Download and install the Azure Multi-Factor Authentication Server NPS extension from Microsoft.
    2. Register the NPS extension with Azure AD by signing in with an Azure AD admin account during installation to create the service principal.
    3. Configure RRAS as an NPS RADIUS client and ensure NPS can reach Azure endpoints (TCP 443 outbound).
    4. On NPS, configure the RADIUS client (RRAS). The extension will intercept RADIUS authentication requests and call Azure MFA for the second factor (phone call, push, TOTP depending on user’s MFA methods).
  • Note: When using Azure MFA NPS extension, username/password is validated against AD (domain controller) and the extension triggers the Azure second factor. Design your network so NPS can reach a DC for primary auth and Azure for MFA calls.

Option B — Duo (or other third-party) via Duo Authentication Proxy

  • Install Duo Authentication Proxy on a server that can reach both NPS and Duo cloud services.
  • Configure Duo proxy with an “authproxy” stanza that listens as a RADIUS server for NPS and forwards verification to Duo. Example flow:
    • RRAS → NPS → RADIUS forward to Duo Auth Proxy → Duo cloud → NPS returns allow/deny.
  • Duo supports push, SMS, phone, and hardware tokens. Carefully configure user association between AD and Duo users (sAMAccountName or mail attribute mappings).

Step 5 — Configure RRAS to use NPS

  • In RRAS console, right-click server → Properties → Security tab → Authentication Provider = RADIUS Authentication (or Remote Authentication Dial-In User Service) and specify the NPS server IP and shared secret.
  • Alternatively, use the Routing and Remote Access Server → Remote Access Clients settings to point to the RADIUS server for authenticating VPN connections.

Restart RRAS after setting RADIUS parameters. Then attempt a test connection to trigger the RADIUS + MFA flow.

Step 6 — Client configuration (Windows native SSTP)

  • Create a new VPN connection (Settings → Network & Internet → VPN → Add a VPN connection) or use the Control Panel wizard.
  • VPN provider: Windows (built-in). Connection name: e.g., “Corp SSTP VPN”. Server name or address: vpn.example.com. VPN type: Secure Socket Tunneling Protocol (SSTP). Type of sign-in info: User name and password.
  • Optional: Configure split-tunneling or force all traffic through the VPN in the IPv4 properties → Advanced settings.
  • On connect: Enter your domain credentials. After primary auth is validated, MFA provider will prompt (push, code, call) as configured.

Troubleshooting checklist

  • TLS handshake failure: Verify cert subject matches FQDN, cert not expired, full chain trusted. Use openssl s_client -connect vpn.example.com:443 from an external machine to inspect certificate chain.
  • Port conflict (IIS vs SSTP): Both use HTTP.sys. If IIS is bound to 443, ensure the same cert is usable or use host headers/SNI only for HTTPS sites. In many setups, configure IIS to host websites on a different IP or disable the default site to avoid conflicts.
  • RADIUS timeouts: NPS must be reachable and respond quickly. Check shared secret mismatch and firewall rules between RRAS and NPS.
  • MFA not triggered: Validate NPS extension/proxy registration, ensure user is enabled for MFA in the provider console, and confirm NPS policies match the incoming requests.
  • Event logs: Check Windows Event Viewer → Applications and Services Logs → Microsoft → Windows → NPS and RemoteAccess logs for detailed errors.
  • OCSP/CRL: Clients must be able to access CRL/OCSP endpoints referenced in the certificate. If these are blocked, clients may reject the server certificate.

Security best practices

  • Use strong certs: Public CA-signed certificates with modern key sizes (RSA 2048+/ECDSA).
  • Enforce modern ciphers and TLS versions by applying Windows updates and registry/TLS hardening guides.
  • Limit management access to the RRAS and NPS servers—use jump boxes, MFA for admin accounts, and role-based access control.
  • Apply network segmentation—allow VPN clients only the required segments via firewall rules or VLANs.
  • Monitor logs and alerts for failed authentications and unusual connection patterns; integrate with SIEM.
  • Periodic review: Rotate shared secrets between RRAS and NPS, and enforce user MFA registration policies and backup authentication methods.

Conclusion

Combining SSTP with a robust MFA solution creates a user-friendly, firewall-friendly VPN that significantly strengthens remote access security. The key steps are proper certificate management, reliable RRAS and NPS configuration, and a well-tested MFA integration (Azure NPS extension or a third-party RADIUS proxy like Duo). Test thoroughly—both authentication and certificate flows—before rolling out to production users. With correct setup and hardening, SSTP + MFA delivers secure, manageable remote connectivity for modern organizations.

For implementation reference and managed service options, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.