SSTP (Secure Socket Tunneling Protocol) remains a reliable option for VPN connectivity, particularly in Windows-centric environments where it leverages SSL/TLS over TCP port 443 to traverse restrictive firewalls. However, like any remote access technology, SSTP deployments can be made significantly more robust by combining certificate- and user-level authentication with precise IP-based filtering. This article explores practical, technical methods to tighten an SSTP VPN by enforcing both IP-based and user-based access controls, with configuration examples, integration points, and operational guidance for administrators and developers.

Why combine IP- and user-based filters?

Authentication without access controls grants a user network-level entry but not necessarily constrained privileges. Conversely, IP-based filtering without identity awareness can block or permit connections irrespective of who is connecting. Combining both approaches yields layered security: only authenticated users can connect, and their traffic is further restricted to specific IP ranges, services, or destinations. This minimizes lateral movement, reduces attack surface, and helps meet compliance requirements.

Threat model and objectives

  • Prevent unauthorized SSTP access from compromised accounts or stolen credentials.
  • Limit post-authentication access to specific subnets, hosts, and services.
  • Reduce risk from infected client devices by restricting reachable IPs.
  • Implement logging and enforcement points that support auditing and incident response.

Core building blocks

Designing a secure SSTP deployment with IP- and user-based controls requires several interlocking components. Each layer provides control and telemetry:

  • Transport security and certificate management — TLS version controls, cipher suites, server certificates, CRL/OCSP checks.
  • Authentication backend — Active Directory (AD), RADIUS (Network Policy Server), or external identity providers.
  • Policy engine — NPS policies, group-based rules, and RADIUS attributes that map users to access profiles.
  • Network enforcement — Windows RRAS filters, Windows Firewall/WFP, edge firewall/NAT device rules, and internal perimeter ACLs.
  • Logging and monitoring — Event logs, RADIUS accounting, SIEM integration for alerting and forensic visibility.

Transport hardening: TLS and certificates

Because SSTP uses TLS, hardening the TLS layer is essential:

  • Enforce TLS 1.2 or TLS 1.3 only; disable SSL and older TLS versions at the server.
  • Use strong cipher suites (prefer AEAD ciphers like AES-GCM and ChaCha20-Poly1305 when supported).
  • Deploy an X.509 server certificate from a trusted CA and enforce strict certificate validation on clients. Consider certificate pinning where feasible to prevent MITM risks.
  • Enable CRL and OCSP checking to ensure revoked certificates are not accepted.

On Windows RRAS, you can control the certificate through the MMC Certificates console and assign the appropriate server cert for SSTP binding. Maintain a private key with appropriate ACLs and rotate certificates before expiry.

User-based controls: authentication and policy mapping

Centralized authentication and policy mapping are critical to implement per-user access restrictions.

Use NPS (RADIUS) for extensible policy decisions

Integrate RRAS with NPS to leverage RADIUS attributes for fine-grained control. Common approaches:

  • Map AD group membership to specific RADIUS attributes like Filter-Id, Framed-IP-Address, or Vendor-Specific attributes to drive downstream filtering behavior.
  • Implement NPS network policies that evaluate conditions (group membership, client IP, machine certificate presence) and issue Access-Accept with attributes that RRAS or the firewall can interpret.

Example: Assign a RADIUS Filter-Id per AD group so the edge firewall can apply the appropriate ACL for that session.

Use machine and user authentication

Enable both user and computer certificates (machine authentication) where possible. This raises the bar by requiring a trusted client machine in addition to valid user credentials.

IP-based filtering: where to enforce

IP-based filtering can be applied at multiple enforcement points. Combining them increases resilience:

  • Edge firewall / VPN gateway: Filter inbound SSTP connections by source IP ranges if you expect connections from controlled networks (e.g., corporate offices, partner networks). This reduces exposure from wide-open internet access.
  • RRAS connection filters: Use Routing and Remote Access filters to control traffic from the PPTP/L2TP/SSTP interface. RRAS supports input/output filters per interface which can enforce destination IPs or ports.
  • Windows Firewall & Windows Filtering Platform (WFP): Implement per-user firewall rules (WFP can be used with IPsec policies or via advanced firewall rules linked to user/group SIDs) to limit what authenticated users can reach.
  • Internal network ACLs: Use switch/edge ACLs and internal firewalls to restrict tunnels to specific subnets or servers.

Implementing RRAS filters

RRAS allows you to add filters (input/output) on the VPN interface. Example workflow:

  • Create policy groups in NPS and tag sessions with a RADIUS attribute that your orchestration system can translate to RRAS filters.
  • Use PowerShell to add/remove RRAS filters or to script filter application per group. Example (run on RRAS server):

PowerShell conceptual commands: (adapt to your environment)
netsh routing ip nat show interface

Create or modify filters using the RRAS MMC or scripting via WMI/RemoteAccess cmdlets

Note: RRAS CLI/WMI programming is often environment-specific—combine GUI setup with automated processes that apply named filter templates per group.

Per-user firewall rules with Windows Firewall

Windows Advanced Firewall supports rules scoped to user or group SIDs. This lets you constrain which local or remote IPs a particular authenticated user can access.

  • Create inbound/outbound rules with the “Users and Computers” tab selecting particular AD users/groups.
  • Scope rules by remote IP address ranges, protocols, and ports.
  • Use Group Policy to deploy these rules consistently across clients or to the RRAS server for service-side enforcement.

Example: A rule that allows access to 10.10.20.0/24 for members of the domain group “VPN-Finance” but denies other destinations.

Dynamic address assignments and Framed-IP-Address

When you need to assign static or dynamic internal IPs per user group, use RADIUS Framed-IP-Address attributes to control the IP address assigned to the PPP session. This allows network ACLs to assume predictable source addresses and apply filtering accordingly.

Workflow:

  • Create DHCP or static pools tied to groups.
  • Issue Framed-IP-Address via NPS policies based on group membership.
  • Edge firewalls then allow traffic only from those framed IPs to sensitive resources.

Integration with SIEM and logging

Visibility is key. Log these events to detect anomalies:

  • SSTP connection starts/stops in RRAS event logs.
  • NPS authentication successes/failures with RADIUS accounting.
  • Edge firewall logs showing source IPs and permitted/denied flows.
  • WFP/Windows Firewall logs for per-user blocking events.

Feed logs to a SIEM and implement alerts for suspicious patterns: mass failed authentications, sessions from unexpected geolocations, or users suddenly accessing previously unused subnets.

Operational recommendations

  • Least privilege: Map users to the minimum set of IP destinations needed for their work.
  • Change control: Manage filter changes via version-controlled scripts or Configuration Management (Ansible, PowerShell DSC) to avoid errors.
  • Testing: Test filters with staging users and monitor logs to verify expected behavior before broad rollouts.
  • Fail-safe design: Have an out-of-band admin access method (jump host, VPN with stricter controls) for troubleshooting if filters misapply.
  • Periodic review: Audit group memberships, RADIUS attributes, and firewall rules quarterly to ensure they still match business needs.

Example deployment pattern

Here’s a compact example of how components come together:

  • Clients authenticate to SSTP endpoint using machine and user certificates (two-factor: cert + AD credentials).
  • RRAS proxies authentication to NPS (RADIUS).
  • NPS evaluates user group membership and issues Framed-IP-Address and Filter-Id attributes.
  • Edge firewall reads Filter-Id (or consults an orchestration service) and applies a corresponding ACL that limits traffic to allowed application subnets/ports.
  • Windows Firewall enforces per-user rules on key servers restricting lateral movement.
  • All logs flow to a SIEM for correlation with threat intelligence.

Challenges and caveats

Be mindful of operational trade-offs:

  • Overly restrictive IP filtering can break legitimate use cases (split-tunneling vs full-tunnel behavior).
  • Mapping user policies to IP-based ACLs requires careful planning when users roam or connect from unknown networks.
  • Not all VPN appliances support dynamic enforcement of RADIUS attributes—verify compatibility before designing policies.

Conclusion

Securing SSTP connections requires more than strong TLS — it requires layered enforcement that ties identity to network access. By combining certificate-based transport hardening, NPS/RADIUS-driven user policies, Framed-IP-Address assignment, RRAS/WFP filters, and edge firewall ACLs, you can implement a robust model that limits both who can connect and what they can reach. With centralized logging and regular audits, this architecture reduces risk while preserving operational flexibility.

For practical deployment templates, scripts, and managed dedicated IP options that align with these controls, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.