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.
Configuration
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.
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.
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.
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.
Certificates
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
Example:
Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart
Re-Encryption
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
Lukas
/ August 11, 2020HI 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 !
Regards
Lucas
Richard M. Hicks
/ August 11, 2020You 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: https://github.com/richardhicks/aovpn/blob/master/F5-BIG-IP-SSTP-Monitor.txt. 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, 2020Hi 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.
Regards
Lucas
Richard M. Hicks
/ August 13, 2020FYI, 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.
Nagu
/ September 8, 2020Hello 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.
Richard M. Hicks
/ September 9, 2020Shouldn’t make a difference at all. 🙂
Lucas
/ October 20, 2020Hi 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 https://support.f5.com/csp/article/K86025623 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.
Richard M. Hicks
/ October 24, 2020Thanks 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.
Aaro Terävä
/ October 15, 2023Hi, 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 ?
thanks,
Richard M. Hicks
/ October 18, 2023I’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.
Tony
/ October 30, 2023Hi 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 addr=::ffff:xxx.xx.xxx.xxx:443 srcaddr=::%0:37106 ]
Richard M. Hicks
/ October 30, 2023How is your montior configured? Is it just a TCP check? Or are you using an HTTPS GET?
Tony
/ October 30, 2023We 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.
Richard M. Hicks
/ October 30, 2023Ok, 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, 2023It’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..
Richard M. Hicks
/ October 31, 2023Ok. 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, 2023We 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.
Richard M. Hicks
/ October 31, 2023That’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.