Why split‑tunneling matters for SSTP on Windows

Split‑tunneling allows selective routing of traffic: only traffic destined for specific networks goes through the VPN while other internet traffic continues to use the local gateway. For organizations and developers using SSTP (Secure Socket Tunneling Protocol) on Windows, split‑tunneling can reduce latency, save bandwidth on the VPN concentrator, and preserve access to local network resources such as printers or NAS devices. At the same time it reduces the load on corporate egress points and can improve user experience for latency‑sensitive services like video conferencing.

Prerequisites and environment checks

Before you begin, verify these items:

  • Windows 8.1/10/11 or Windows Server 2012 R2 and later (client PowerShell cmdlets vary by version).
  • Administrative access on the Windows client machine to run PowerShell and change network settings.
  • An SSTP VPN server reachable from the client (certificate‑based TLS required on the server for SSTP).
  • IP addressing plan for the remote private networks you need routed through the VPN.
  • Optional: RRAS or a VPN appliance configured to accept SSTP connections and to allow split‑tunnel (server may push a default route—if so, server configuration must be changed).

High‑level approach

There are two main ways to implement split‑tunneling for SSTP on Windows:

  • Client‑side split‑tunneling — configure the Windows VPN connection to not use the remote default gateway, and add explicit routes to the remote subnets via the VPN interface.
  • Server‑side split‑tunneling — configure the VPN server to push only specific routes to the client and not to push a default route. This is usually the cleaner solution for enterprise deployments.

Step‑by‑step: Create the SSTP connection on Windows

If you haven’t yet created the Windows SSTP VPN connection, do the following (UI or PowerShell):

UI method: Open Settings → Network & Internet → VPN → Add a VPN connection. Choose Windows (built‑in) as the provider, enter the server name, and select “Secure Socket Tunneling Protocol (SSTP)” for the VPN type.

PowerShell method (example):

Run PowerShell as Administrator and execute:

New-VpnConnection -Name “Corp‑SSTP” -ServerAddress “vpn.example.com” -TunnelType SSTP -AuthenticationMethod Eap -RememberCredential -Force

Adjust authentication parameters (EAP, MSCHAPv2, certificate) to match server configuration.

Disable default gateway on the remote network (turn on split‑tunneling)

By default, Windows VPN connections often set the remote default gateway so all traffic routes via the VPN. To enable split‑tunneling, disable that option. There are two ways:

  • In the classic Network Connections UI: Right‑click the VPN adapter → Properties → Networking tab → Internet Protocol Version 4 (TCP/IPv4) → Properties → Advanced → uncheck “Use default gateway on remote network”.
  • PowerShell (preferred for automation):

Set the VPN connection to use split tunneling (Windows 8.1 / Windows 10 cmdlet):

Set-VpnConnection -Name “Corp‑SSTP” -SplitTunneling $True

If Set‑VpnConnection does not expose SplitTunneling on your platform, you must uncheck the advanced TCP/IPv4 option via UI as above, or use rasphone.pbk modifications and rasdial automation.

Establish the VPN and inspect the interface

Connect to the VPN and collect interface details. Use these commands to inspect mappings and routes:

  • ipconfig /all — find the PPP adapter IP and DNS assigned over VPN.
  • Get-NetAdapter / Get-NetIPConfiguration in PowerShell — retrieve InterfaceIndex and IPv4 address for the VPN adapter.
  • route print or Get-NetRoute — show the current routing table.

Take note of the VPN adapter’s InterfaceIndex or the gateway address assigned to the PPP link. You will need this to add persistent routes pointing at the VPN.

Adding routes for the networks that must go through the VPN

Decide which IP ranges should be routed via the SSTP tunnel (for example, 10.0.0.0/8 for corp resources, or specific subnets like 192.168.50.0/24). Then add persistent routes so Windows forwards them into the VPN adapter.

Example PowerShell using persistent routing (Windows 10+):

Assume VPN interface index is 23 and remote subnet 10.20.0.0/16 must go via the VPN:

New-NetRoute -DestinationPrefix “10.20.0.0/16” -InterfaceIndex 23 -NextHop 0.0.0.0 -PolicyStore ActiveStore

Alternatively, using the classic route command (adds persistent entry):

route add 10.20.0.0 mask 255.255.0.0 metric 1 -p

Note: For PPP (SSTP) interfaces the next hop is usually 0.0.0.0 and Windows knows to forward via the PPP link using the interface index. If adding routes with a specific gateway, use the PPP peer IP if known.

Handling split DNS and DNS leaks

Split‑tunneling can cause DNS queries for internal names to go to the public DNS resolver unless the VPN supplies DNS servers and the client is configured to use them for internal domains. To avoid DNS leakage:

  • Set the VPN adapter’s DNS servers to the internal DNS and ensure search suffixes are provided. PowerShell example:
  • Set-DnsClientServerAddress -InterfaceIndex 23 -ServerAddresses (“10.10.10.10″,”10.10.10.11”)
  • Configure conditional forwarders or DNS suffixes so only requests for corp domains use the internal DNS.
  • Use tools like ipconfig /displaydns and nslookup -server to test which DNS is being used for specific names.

Adjusting interface metrics and prioritization

Windows chooses routes based on prefix specificity and interface metrics. If you see traffic still going out the wrong interface, check metrics.

List interfaces and metrics:

Get-NetIPInterface | Sort-Object InterfaceIndex

Change the metric to prefer the VPN for specific subnets (or to prefer local internet for all default traffic):

Set-NetIPInterface -InterfaceIndex 23 -InterfaceMetric 10

Lower metric means higher priority for routes tying to that interface. Carefully tune metrics to avoid unintended routing loops.

Testing and validation

After configuration, validate thoroughly:

  • route print / Get-NetRoute — confirm desired destination prefixes map to the VPN interface.
  • tracert or Test-NetConnection -TraceRoute — validate path for internal IPs goes through the VPN.
  • curl or browser checks — ensure public websites use local ISP when expected and internal resources are accessible via VPN.
  • nslookup — confirm internal names are resolved by the internal DNS servers when required.
  • Use packet capture tools (WireShark on the client) if deep inspection is required to verify which interface carries which flows.

Automating route updates when the VPN connects/disconnects

Because PPP interface indices can change between connections, it’s common to use connection hooks. Two methods:

  • Use Windows Task Scheduler with triggers on “On an event” for RasClient Events (event IDs for connect/disconnect) and run a PowerShell script that enumerates the VPN interface and re‑creates the routes using the fresh InterfaceIndex.
  • Use a connection script triggered by rasdial or a custom script that connects and then runs route commands to create persistent (or ActiveStore) routes and DNS settings.

Example script skeleton:

– Detect VPN interface by name (Get-NetAdapter -Name “vEthernet (Corp‑SSTP)” or Get-NetIPConfiguration | where { $_.InterfaceAlias -eq “Corp‑SSTP” })

– Get InterfaceIndex

– Run New-NetRoute for all required prefixes

Security considerations and best practices

Split‑tunneling offers performance benefits but introduces security tradeoffs. Key recommendations:

  • Limit split‑tunneling to required destinations only. Avoid broad CIDR ranges that might accidentally direct sensitive traffic outside corporate controls.
  • Use strong authentication and TLS certificates for SSTP. SSTP runs over HTTPS/TLS, so ensure certificates are valid and pinned or validated.
  • Harden DNS configuration. Prevent DNS leaks by forcing internal domains to internal DNS servers and consider DNS over TLS/HTTPS when appropriate.
  • Apply endpoint security. Ensure clients have up‑to‑date antivirus, host firewall rules, and EDR in place because split‑tunneling exposes the client to the public internet outside the VPN.
  • Consider a “kill switch” policy. If a connection to corporate resources must not occur outside the VPN, implement firewall rules that block access to those resources unless the VPN interface is present.
  • Server policy controls. When possible, implement split‑tunnel policies on the VPN server so the server controls the exact routes pushed to the client and can prevent unapproved traffic patterns.

Troubleshooting tips

Common problems and how to diagnose them:

  • Traffic still goes to the VPN for all destinations — check the “use default gateway” setting and verify the server is not forcing a default route.
  • Cannot reach internal hosts — verify routes exist and point to the VPN interface; ensure firewall rules on the server permit forwarded traffic.
  • DNS resolution uses public DNS — ensure DNS client settings on the VPN adapter are correct and that conditional forwarding is configured.
  • Routes disappear after reconnect — implement a connection script that re-applies routes based on the current InterfaceIndex.

Implementing split‑tunneling for SSTP on Windows requires careful coordination between client configuration and VPN server policy. When done correctly, it combines the security of encrypted SSTP tunnels for necessary corporate traffic with the performance benefits of preserving local internet access for other services.

For more deployment specifics, automation examples, and managed static IP options to pair with SSTP split‑tunneling, see Dedicated‑IP‑VPN at https://dedicated-ip-vpn.com/.