Always On VPN SSTP Load Balancing with F5 BIG-IP

Always On VPN SSTP Load Balancing with F5 BIG-IP The Windows Server Routing and Remote Access Service (RRAS) includes support for the Secure Sockets Tunneling Protocol (SSTP), which is a Microsoft proprietary VPN protocol that uses SSL/TLS for security and privacy of VPN connections. The advantage of using SSTP for Always On VPN is that it is firewall friendly and ensures consistent remote connectivity even behind highly restrictive firewalls.

Load Balancing SSTP

In a recent post, I described some of the use cases and benefits of SSTP load balancing as well as the offloading of TLS for SSTP VPN connections. Using a load balancer for SSTP VPN connections increases scalability, and offloading TLS for SSTP reduces resource utilization and improves performance for VPN connections. There are positive security benefits too.


Enabling load balancing for SSTP on the F5 BIG-IP load balancer is fundamentally similar to load balancing HTTPS web servers. However, there are a few subtle but important differences.

Default Monitor

The default HTTP and HTTPS monitors on the F5 will not accurately reflect the health of the SSTP service running on the RRAS server. In addition, using a simple TCP port monitor could yield unexpected results. To ensure accurate service status monitoring, a new custom monitor must be created to validate the health of the SSTP service.

Custom SSTP Monitor

Open the F5 BIG-IP management console and follow the steps below to create and assign a new custom monitor for SSTP.

Create Monitor

1. In the navigation tree highlight Local Traffic.
2. Click Monitors.
3. Click Create.

Always On VPN SSTP Load Balancing with F5 BIG-IP

4. Enter a descriptive name in the Name field and from the Type drop-down list choose HTTP if TLS offload is enabled, or HTTPS if it is not.
5. In the Send String field enter HEAD /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ HTTP/1.1\r\nHost:r\nConnection: Close\r\n\r\n.
6. In the Receive String field enter HTTP/1.1 401.
7. Click Finished.

Always On VPN SSTP Load Balancing with F5 BIG-IP

Assign Monitor

1. Below Local Traffic click Pools.
2. Click on the SSTP VPN server pool.
3. In the Health Monitors section select the SSTP VPN health monitor from the Available list and make it Active.
4. Click Update.

Always On VPN SSTP Load Balancing with F5 BIG-IP

CLI Configuration

If you prefer to configure the SSTP VPN monitor using the F5’s Command Line Interface (CLI), you can download the monitor configuration from my GitHub here.

TLS Offload

It is generally recommended that TLS offload not be enabled for SSTP VPN. However, if TLS offload is desired, it is configured in much the same way as a common HTTPS web server. Specific guidance for enabling TLS offload on the F5 BIG-IP can be found here. Details for configuring RRAS and SSTP to support TLS offload can be found here.


When enabling TLS offload for SSTP VPN connections it is recommended that the public SSL certificate be installed on the RRAS server, even though TLS processing will be handled on the F5 and HTTP will be used between the F5 and the RRAS server. If installing the public SSL certificate on the RRAS server is not an option, additional configuration will be required. Specifically, TLS offload for SSTP must be configured using the Enable-SSTPOffload PowerShell script, which can be found here.

Once the script has been downloaded, open an elevated PowerShell command window and enter the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart


Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart


When offloading TLS for SSTP VPN connections, all traffic between the F5 and the RRAS server will be sent in the clear using HTTP. In some instances, TLS offload is required only for traffic inspection, not performance gain. In this scenario the F5 will be configured to terminate and then re-encrypt connections to the RRAS server. When terminating TLS on the F5 and re-encrypting connections to the RRAS server is required, the same certificate must be used on both the F5 and the RRAS server. Using different certificates on the RRAS server and the load balancer is not supported.

Additional Information

Windows 10 Always On VPN SSTP Load Balancing and SSL Offload

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN ECDSA SSL Certificate Request for SSTP

Windows 10 Always On VPN SSTP Connects then Disconnects

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers


Leave a comment


  1. Lukas

     /  August 11, 2020

    HI Richard,
    I am working currently on always on VPN deployment using DNS and load balancing URL on two sites F5 VIPs, and have F5 pool with 3 servers on each site. I found one problem how to monitor service on DNS as we have running UDP 4500 and UDP 500 VIPs ? any ideas as not finding any logical solution ? maybe Always ON VPN have rest API ? and it is possible to monitor any TCP port ?
    Thanks for any advice how to solve that !

    • You have a few options. First, F5 has a UDP monitor but I’m hearing reports that it is unreliable or that it doesn’t work at all. It should send UDP packets to the specified ports and mark them down if the workload returns an ICMP port unreachable message. It appears Windows Server doesn’t do that by default. Enabling that option has produced mixed results. Another alternative is to monitor the SSTP port using TCP 443 or an HTTPS monitor. I have an example posted on my GitHub here: The idea here would be that if the RRAS service was down and IKEv2 wasn’t available, SSTP would be down as well.

      • Lukasz Szopa

         /  August 11, 2020

        Hi Richard, thank you very much, will try this, also noticed one more thing server is listening on TCP port 80 (probably for some management purpose) if this SSTP will not be possible will try to use monitor this port 80 it is not covering 100% problems but is much better than trivial icmp or unreliable UDP. Thanks again ! Will update what finally we implemented and if we achieved planned goal.

      • FYI, the example I posted on GitHub is for SSTP offload scenarios. You’ll need to update it to use HTTPS, assuming you aren’t offloading. I’d definitely recommend monitoring TCP 443 though using an HTTPS probe, not just a TCP port probe though.

  2. Hello Richard
    With our AOVPN configuration we use a Device Tunnel and User Tunnel.Device Tunnel uses IKE and user tunnel SSTP. We use external load balancer but find Device tunnel and User tunnel from the same client get put through different AOVPN servers. Just asking if this can leade to any issues? Thinking if it can lead to any routing issues.

  3. Lucas

     /  October 20, 2020

    Hi Richard,

    based on yours advise SSTP monitoring works fine 🙂 also found some bug in F5 software version 11.6 there is a bug with health checks towards VIP which is down fixed in >13. But can be also fixed by applying Verify accept on F5 TCP profile. But have another problem, is it true that there is limitation regarding Always On VPN sessions using SNAT ? is there any possibility to obey that ? Found that our F5 sent information about client public ip address named as peer remote address and client could identify session based on that field, what do you think ? Thank for advise.

    • Thanks for the update! Good to know about the F5 fix for sure. As for using SNAT, it is not recommended but you can use it. It causes more problems for IKEv2 than it does SSTP anyway. The advantage to disabling SNAT is that your VPN access logs are more meaningful (have actual client source IP address rather than the address of the F5). Enabling SNAT may also cause issues under heavy load, but if you don’t have a lot of users you may not notice it.

  4. Aaro Terävä

     /  October 15, 2023

    Hi, we have noticed with a couple of customers a situation when RRAS servers gets updates and reboots. After reboot this https probe still marks node down. When we reboot the RRAS server one more time, problem is solved, ie. f5 marks nodes up.
    Has anybody else noticed similar behaviour ?

    • I’ve seen this myself too. No idea what causes it, though. Typically, restarting the RemoteAccess service solves it. Occasionally I’ve had to restart the server entirely to restore service.

  5. Tony

     /  October 30, 2023

    Hi Richard,

    We notice our F5 monitor is getting “connection refused” from the RAS servers, which marks the RAS server node as down, causing a mass connection reset.
    All AOVPN users connected to that RAS server get their session disconnected. So it’s a bit annoying to say the least..
    I’ve checked the RAS server event logs but cannot find any issues there.
    I am not sure what else we can do to figure out why the RAS server is refusing the connection from F5.
    Do you have any ideas?

    Example of F5 monitor log with connection refused:

    [0][7970] 2023-10-30 08:10:46.069093: ID 192 :(_connect_to_service): connect: Connection refused [ tmm?=false td=true tr=false srcaddr=::%0:37106 ]

    • How is your montior configured? Is it just a TCP check? Or are you using an HTTPS GET?

      • Tony

         /  October 30, 2023

        We are using the HTTPS monitor as described in your article above 🙂
        We now have a TCP monitor running as well – which doesn’t fail – to keep things running. If (at least) one of the two monitors is successful, F5 doesn’t bring the node down.

      • Ok, just wanted to make sure. 🙂 So, the question is – when the monitor is failing, is it persistent? In other words, does the monitor fail until you restart the service or reboot the server? Or does it happen intermittently?

      • Tony

         /  October 31, 2023

        It’s not persistent unfortunately. It happens intermittently. Next attempt the monitor will be successful and F5 brings the node back up. But in the meantime it already caused a mass-disconnect when bringing the node down..

      • Ok. I was going to suggest checking the state of the service manually from a different host to see if the service was indeed failing. That might shed some light on whether or not it is the service or just the F5 not interpreting the response correctly.

      • Tony

         /  October 31, 2023

        We think alike 🙂
        I have a monitoring server running the same HEAD request every 5 seconds and no issues so far. Always comes back as a 401.
        So I assume F5 is – occasionally – not interpreting the response correctly.

      • That’s what I suspect. You many need to open a support case with F5 and see what they have to say. Perhaps providing network captures from the F5 will help them figure things out.

  1. Always On VPN SSTP Connects then Disconnects | Richard M. Hicks Consulting, Inc.
  2. Always On VPN SSTP Load Balancing and SSL Offload | Richard M. Hicks Consulting, Inc.
  3. Always On VPN SSTP Load Balancing with Kemp LoadMaster | Richard M. Hicks Consulting, Inc.
  4. Always On VPN SSTP Load Balancing with Citrix NetScaler ADC | Richard M. Hicks Consulting, Inc.
  5. Always On VPN SSTP Certificate Binding Error | Richard M. Hicks Consulting, Inc.

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading