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.

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.

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.

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

 

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Note: For information about configuring the F5 BIG-IP to perform IP-HTTPS preauthentication, click hereFor information about configuring Windows Server 2012 R2 or Windows Server 2016 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerIP-HTTPS is an IPv6 transition technology used by DirectAccess. It enables DirectAccess clients to communicate with the DirectAccess server using IPv6 over the public IPv4 Internet by encapsulating IPv6 packets in HTTP and authenticating (and optionally encrypting) them using SSL/TLS. IP-HTTPS is supported for all DirectAccess network deployment configurations and is enabled by default.

When a DirectAccess client connection is established, only the server is authenticated by the client. The client is not authenticated by the server. The DirectAccess server will thus accept IP-HTTPS connections from any client, valid or not.

IP-HTTPS Connection

Once a client has established an IP-HTTPS transition tunnel, it will go through the standard IPv6 neighbor discovery process to identify routers and obtain an IPv6 prefix for the link. It will use this information to build its own IPv6 address, which it uses to communicate with the DirectAccess server and begin establishing IPsec security associations for DirectAccess.

ICMP and IPsec

By design, ICMP is exempt from DirectAccess IPsec policy processing. If an unauthorized client were to establish an IP-HTTPS transition tunnel, even without authentication (Kerberos Proxy or certificate) it would be able to ping the DirectAccess server tunnel endpoint IPv6 addresses, the DNS64 IPv6 address, and any intranet hosts (assuming host firewalls allow this access).

Security Risk

This default posture opens up the DirectAccess server and intranet to unauthorized remote network reconnaissance and some IPv6-related Denial-of-Service (DoS) attacks. These were demonstrated by security researcher Ali Hardudi at the recent Troopers16 security conference. You can view his very informative session here.

Note: DirectAccess IPsec data connections are unaffected and are completely secure. Data is never exposed at any time with the default configuration.

IP-HTTPS Preauthentication

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerTo mitigate these risks, it is recommended that an Application Delivery Controller (ADC) such as the Citrix NetScaler be configured to preauthenticate DirectAccess clients prior to establishing the IP-HTTPS transition tunnel.

Note: To configure the F5 BIG-IP to perform IP-HTTPS preauthentication, click here.

Citrix NetScaler Configuration

To perform DirectAccess preauthentication, it will be necessary to configure the Citrix NetScaler to perform SSL termination for IP-HTTPS. The virtual server on the NetScaler must use the SSL protocol. In addition, a CA certificate must be bound to the virtual server. Also, Client Authentication must be enabled under SSL Parameters and be set to Mandatory.

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Once configured, the NetScaler appliance will ensure that the DirectAccess IPsec certificate is present on the client before establishing the IP-HTTPS IPv6 transition tunnel. This will prevent unauthorized connections to the DirectAccess server.

Important Considerations

Performing IP-HTTPS preauthentication on the Citrix NetScaler is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the NetScaler appliance breaks OTP authentication.

Summary

The default security posture of DirectAccess leaves the internal network open to unauthorized network reconnaissance, and exposes the DirectAccess infrastructure to potential denial-of-service (DoS) attacks. To mitigate these security risks, implement the Citrix NetScaler ADC and enable client certificate authentication.

References

Security Assessment of Microsoft DirectAccess [Overview] – https://www.insinuator.net/2016/04/security-assessment-of-microsoft-directaccess/

Security Assessment of Microsoft DirectAccess [Full Document] – https://www.ernw.de/newsfeed/newsletter-53-may-2016-security-assessment-of-microsoft-directaccess/index.html

Security Assessment of Microsoft DirectAccess Troopers16 Presentation by Ali Hardudi [Video] – https://www.youtube.com/watch?v=wW1x7ow0V9w

Chiron IPv6 Penetration Testing Framework – https://www.insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/

IP-HTTPS specification on MSDN – https://msdn.microsoft.com/en-us/library/dd358571.aspx

Configure F5 BIG-IP to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/

Configure Windows Server 2012 R2  and Windows Server 2016 to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/06/13/directaccess-ip-https-preauthentication/