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 platform 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

 

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Always On VPN IKEv2 Load Balancing with F5 BIG-IPThe Internet Key Exchange version 2 (IKEv2) is the protocol of choice for Always On VPN deployments where the highest level of security is required. Implementing Always On VPN at scale often requires multiple VPN servers to provide sufficient capacity and to provide redundancy. Commonly an Application Delivery Controller (ADC) or load balancer is configured in front of the VPN servers to provide scalability and high availability for Always On VPN.

Load Balancing IKEv2

In a recent post I described some of the unique challenges load balancing IKEv2 poses, and I demonstrated how to configure the Kemp LoadMaster load balancer to properly load balance IKEv2 VPN connections. In this post I’ll outline how to configure IKEv2 VPN load balancing on the F5 BIG-IP load balancer.

Note: This article assumes the administrator is familiar with basic F5 BIG-IP load balancer configuration, such as creating nodes, pools, virtual servers, etc.

Initial Configuration

Follow the steps below to create a virtual server on the F5 BIG-IP to load balance IKEv2 VPN connections.

Pool Configuration

To begin, create two pools on the load balancer. The first pool will be configured to use UDP port 500, and the second pool will be configured to use UDP port 4500. Each pool is configured with the VPN servers defined as the individual nodes.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Virtual Server Configuration

Next create two virtual servers, the first configured to use UDP port 500 and the second to use UDP port 4500.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Persistence Profile

To ensure that both IKEv2 UDP 500 and 4500 packets are delivered to the same node, follow the steps below to create and assign a Persistence Profile.

1. Expand Local Traffic > Profiles and click Persistence.
2. Click Create.
3. Enter a descriptive name for the profile in the Name field.
4. Select Source Address Affinity from the Persistence Type drop-down list.
5. Click the Custom check box.
6. Select the option to Match Across Services.
7. Click Finished.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Assign the new persistence profile to both UDP 500 and 4500 virtual servers. Navigate to the Resources tab on each virtual server and select the new persistence profile from the Default Persistence Profile drop-down list. Be sure to do this for both virtual servers.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Additional Resources

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancer 

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN and IKEv2 Fragmentation

Windows 10 Always On VPN Certificate Requirements for IKEv2

Video: Windows 10 Always On VPN Load Balancing with the Kemp LoadMaster Load Balancer

DirectAccess IP-HTTPS Preauthentication


Introduction

DirectAccess IP-HTTPS PreauthenticationRecently I’ve written about the security challenges with DirectAccess, specifically around the use of the IP-HTTPS IPv6 transition technology. In its default configuration, the DirectAccess server does not authenticate the client when an IP-HTTPS transition tunnel is established. This opens up the possibility of an unauthorized user launching Denial-of-Service (DoS) attacks and potentially performing network reconnaissance using ICMPv6. More details on this can be found here.

Mitigation

The best way to mitigate these security risks is to implement an Application Delivery Controller (ADC) such as the F5 BIG-IP Local Traffic Manager or the Citrix NetScaler. I’ve documented how to configure those platforms here and here.

No ADC?

For those organizations that do not have a capable ADC deployed, it is possible to configure the IP-HTTPS listener on the Windows Server 2012 R2 server itself to perform preauthentication.

Important Note: Making the following changes on the DirectAccess server is not formally supported. Also, this change is incompatible with one-time passwords (OTP)  and should not be performed if strong user authentication is enabled. In addition, null cipher suites will be disabled, resulting in reduced scalability and degraded performance for Windows 8.x and Windows 10 clients. Making this change should only be done if a suitable ADC is not available.

Configure IP-HTTPS Preauthentication

To configure the DirectAccess server to perform preauthentication for IP-HTTPS connections, open an elevated PowerShell command window and enter the following command.

ls Cert:\LocalMachine\My

DirectAccess IP-HTTPS Preauthentication

Copy the thumbprint that belongs to the SSL certificate assigned to the IP-HTTPS listener. Open an elevated command prompt window (not a PowerShell window!) and enter the following commands.

netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert ipport=0.0.0.0:443 certhash=[thumbprint]
appid={5d8e2743-ef20-4d38-8751-7e400f200e65}
dsmapperusage=enable clientcertnegotiation=enable

DirectAccess IP-HTTPS Preauthentication

For load-balanced clusters and multisite deployments, repeat these steps on each DirectAccess server in the cluster and/or enterprise.

Summary

Once these changes have been made, only DirectAccess clients that have a computer certificate with a subject name that matches the name of its computer account in Active Directory will be allowed to establish an IP-HTTPS transition tunnel connection.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Introduction

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic ManagerTo provide geographic redundancy, DirectAccess can be deployed in a multisite configuration. In this scenario, Windows 8.x and Windows 10 clients are aware of all entry points in the enterprise and will automatically select the nearest available entry point to connect to. The nearest entry point is defined as the one that responds the quickest. When a Windows 8.x or Windows 10 client attempts to establish DirectAccess connectivity, an HTTP GET is sent to all entry points and the client will select the one with the shortest Round Trip Time (RTT) for the request.

Note: Windows 7 clients can be provisioned when DirectAccess is configured for multisite access, but they must be assigned to an individual entry point.

Challenges

There are a number of challenges that come with the default multisite configuration. Choosing an entry point based solely on network latency is rather simplistic and can often produce unexpected results. It also lacks support for granular traffic distribution or active/passive configuration.

GSLB

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic ManagerFor the best experience, DirectAccess can be configured to use a Global Server Load Balancing (GSLB) solution to enhance transparent site selection and failover for Windows 8.x and Windows 10 clients. Commonly this is implemented using an on-premises appliance (Citrix NetScaler, F5 Global Traffic Manager, Kemp LoadMaster, A10 Thunder, etc.). These solutions offer exceptional control over DirectAccess traffic distribution, but they add expense and complexity.

Azure Traffic Manager

Azure Traffic Manager is a cloud-based GSLB solution that is a simple and cost-effective alternative to dedicated on-premises appliances. While it does not offer all of the features that GSLB appliances provide, it does provide better traffic distribution options than the default configuration. Importantly, it enables active/passive failover, which is a common requirement not supported natively with DirectAccess.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Traffic Manager Configuration

In the Azure portal (the new one, not the old one!) click New, Networking, and then Traffic Manager profile.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Provide a name and select a Routing method.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Routing method options are Performance, Weighted and Priority.

  • Performance. Select this option to enable clients to connect to the entry point with the lowest network latency.
  • Weighted. Select this option to enable clients to prefer some entry points more than others. Assign a weight value of 1 to 1000 for each entry point. Higher values have more preference. Values for entry points can be the same, if desired.
  • Priority. Select this option to enable clients to connect to a primary entry point, then fail over to a secondary or tertiary entry point in the event of an outage. Assign a priority value of 1 to 1000 for each entry point. Lower values take precedence. Each entry point must be assigned a unique priority value.

Click Create when finished. Next click Settings for the new traffic manager profile and click Configuration. Change Protocol to HTTPS, Port to 443, and Path to /IPHTTPS. Click Save when finished.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Next click Endpoints and click Add. Select External endpoint from the drop down list, provide a descriptive name, and then enter the Fully-Qualified Domain Name (FQDN) of the first DirectAccess entry point. When using the Performance routing method, choose a location that best represents the geography where the DirectAccess entry point is located. When using the Weighted or Priority routing methods, specify an appropriate value accordingly. Click Ok when finished. Repeat these steps for each entry point in the organization.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

DirectAccess Configuration

In the Remote Access Management console, highlight DirectAccess and VPN below Configuration in the navigation tree and then click Configure Multisite Settings below Multisite Deployment in the Tasks pane. Click Global Load Balancing and choose Yes, use global load balancing. Enter the FQDN of the Azure Traffic Manager profile and click Next, and then click Commit.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

Note: An SSL certificate with a subject name matching that of the GSLB FQDN is not required.

In some cases, the management console may report that global load balancing addresses cannot be identified automatically for some or all entry points.

DirectAccess Multisite Geographic Redundancy with Microsoft Azure Traffic Manager

If this occurs, it will be necessary to run the Set-DAEntryPoint PowerShell cmdlet to assign GLSB IP addresses to each entry point. The GSLB IP address is the public IPv4 address that the entry point public hostname resolves to.

Set-DAEntryPoint -Name [entrypoint_name] -GslbIP [external_ip_address]

For example:

Set-DAEntryPoint -Name "US West" -GslbIP 203.0.113.195
Set-DAEntryPoint -Name "US East" -GslbIP 198.51.100.21

Summary

DirectAccess includes native functionality to enable geographic load balancing for Windows 8.x and Windows 10 clients. The site selection process used by DirectAccess clients in this scenario is basic, and has the potential to yield unexpected results. Azure Traffic Manager is a simple, cost-effective alternative to dedicated on-premises GSLB appliances. It can be integrated with DirectAccess to address some of the shortcomings with the native entry point selection process.

Additional Resources

 

 

 

Configure F5 BIG-IP for DirectAccess NLS

Recently I wrote about the Network Location Server (NLS) and its importance for DirectAccess deployments. As I described previously, the NLS is nothing more than a web server with an SSL certificate installed. It should also be made highly available to prevent potential service disruption caused by planned or unplanned NLS server downtime. Any web server can serve as the NLS. In addition, if you have the F5 BIG-IP Local Traffic Manager (LTM) in your environment, you can easily configure the LTM to serve as the NLS.

To accomplish this, import the SSL certificate for the NLS and create an SSL client profile using its certificate and private key. Next, create a new iRule that contains the following code.

when HTTP_REQUEST {
HTTP::respond 200 
}

Configure F5 BGIP for DirectAccess NLS

Finally, create a new virtual server listening on TCP port 443 and assign this iRule as a resource for the virtual server. Once NLS reachability has been verified, update the DirectAccess configuration using the Remote Access Management console or the Set-DANetworkLocationServer PowerShell cmdlet.

SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP

From a client perspective, DirectAccess is an IPv6 only solution. It requires IPv6 connectivity from end-to-end to provide seamless, transparent, always-on remote access. DirectAccess clients are most commonly connected to the IPv4 Internet, so to overcome the limitations imposed by the exclusive use of IPv6 for transport, DirectAccess leverages IPv6 transition technologies such as 6to4, Teredo, or IP-HTTPS to tunnel IPv6 DirectAccess client communication over the IPv4 Internet. These transition protocols are favored by the operating system in the order in which I have listed them here. 6to4 uses IP protocol 41 for transport and requires that the client have a public IPv4 address, so if the DirectAccess client is behind a firewall that does not allow outbound IP protocol 41, or is located behind a NAT and has a private IPv4 address, it will fall back to Teredo. Teredo uses UDP for transport on port 3544, and if this communication is blocked by a firewall the DirectAccess client will then fall back to IP-HTTPS. IP-HTTPS, as its name implies, tunnels DirectAccess IPv6 traffic in HTTP, which is authenticated and encrypted using SSL or TLS.

Historically the challenge with the IP-HTTPS IPv6 transition protocol is that it encrypts DirectAccess communication which is already encrypted using IPsec. This double encryption places significant demands on CPU and memory resources on the DirectAccess server, resulting in poor throughput and performance and limiting the overall scalability of the solution. To address these shortcomings, Windows Server 2012 DirectAccess introduced support for IP-HTTPS NULL encryption. SSL/TLS is still used for authentication, but the IPsec traffic is no longer double encrypted. This dramatically reduces resource consumption on the DirectAccess server, resulting in improved performance and allowing many more DirectAccess clients to be handled by a single server. The only drawback is that IP-HTTPS NULL encryption is only supported with Windows 8 clients. When Windows 7 clients connect to a Windows Server 2012 DirectAccess server using IP-HTTPS, they will continue to use encrypted IP-HTTPS.

An ideal solution would be to terminate SSL off box using a dedicated hardware appliance like the F5 BIG-IP Local Traffic Manager (LTM). Unfortunately there is no provision in Windows Server 2012 DirectAccess to enable SSL termination for IP-HTTPS traffic. However, using some of the advanced features of the LTM, we can effectively offload SSL on the F5 by configuring LTM to emulate Windows 8 DirectAccess client behavior. This is accomplished by having the F5 LTM exclusively negotiate the use of a NULL encryption cipher suite with the Windows Server 2012 DirectAccess server on behalf of Windows 7 DirectAccess clients.

Note: This post assumes that you are familiar with the configuration and management of the F5 BIG-IP LTM solution, and that you’ve already imported your SSL certificates and configured nodes, pools, and virtual servers for your Windows Server 2012 DirectAccess server.

To configure the F5 LTM to provide SSL offload for Windows 7 DirectAccess clients, we’ll need to create SSL profiles to allow the use of specific cipher suites for our IP-HTTPS traffic. In its default configuration, the BIG-IP LTM does not support the use of NULL encryption cipher suites. Since Windows 8 DirectAccess clients use NULL cipher suites exclusively, we need to explicitly enable these on the LTM to support our Windows 8 clients. Since our Windows 7 clients will use only encrypted cipher suites, we’ll be sure to include those as well. To do this, open the F5 management console, expand Local Traffic, Profiles, SSL, and then click the green icon next to Client.

f5_directaccess_iphttps_offload_01

Provide a name for the new Client SSL Profile, select Advanced configuration, check the Custom box and specify DEFAULT:NULL for Ciphers. Be sure to select the appropriate SSL certificate and key. Click Finished at the bottom of the screen to save these settings. This change allows NULL cipher suites in addition to encrypted cipher suites, allowing us to support both Windows 8 and Windows 7 DirectAccess clients.

f5_directaccess_iphttps_offload_02

Next we need to configure the LTM to use only NULL cipher suites when communicating with the Windows Server 2012 DirectAccess server. To do this, expand Profiles, SSL, and then click the green icon next to Server.

f5_directaccess_iphttps_offload_03

Provide a name for the new Server SSL Profile, select Advanced configuration, check the Custom box and specify NULL-SHA for Ciphers. Click Finished at the bottom of the screen to save these settings. The end result here will be to force the exclusive use NULL encryption cipher suites for all IP-HTTPS traffic, regardless if it is a Windows 8 or Windows 7 client.

f5_directaccess_iphttps_offload_04

Once you’ve completed the client and server SSL profiles, it will be necessary to assign these profiles to the virtual servers that represent your Windows Server 2012 DirectAccess server. Navigate to Virtual Servers and click on Virtual Server List. Click the virtual server that corresponds to your DirectAccess server, and then scroll down to the bottom of the page. For SSL Profile (Client), select DA_IPHTTPS_CLIENT and add that to the list. Repeat this step for the SSL Profile (Server), this time selecting DA_IPHTTPS_SERVER. Click Update to apply these changes.

f5_directaccess_iphttps_offload_05

Once complete, the F5 BIG-IP LTM will now effectively be offloading SSL traffic on behalf of Windows 7 DirectAccess clients by emulating the Windows 8 DirectAccess client behavior and using only NULL encryption for IP-HTTPS sessions established with the Windows Server 2012 DirectAccess server. Although I can see no issues with this deployment model, be advised that this configuration may not be supported by Microsoft, so make these changes at your own risk. I’ll be working with Microsoft and F5 to get this solution reviewed and tested and I will provide clarification on supportability here once I have that information.

Special thanks to Jeff Bellamy, Ryan Korock, and John Wagnon at F5 for their assistance with this developing solution.

DirectAccess and NAT

One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.

Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.

Windows Server 2012 DirectAccess Network Topology

Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.

So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.

%d bloggers like this: