DirectAccess and CVE-2024-38063

With the August 2024 Windows security updates, Microsoft released a fix to address a Remote Code Execution vulnerability in the Windows TCP/IP stack (CVE-2024-38063). Critically, this vulnerability affects IPv6 only and does not require authentication or user interaction to exploit. An attacker would only need to send specially crafted IPv6 packets to a Windows host, which could allow them to run arbitrary code on the server. This vulnerability presents some unique challenges for organizations that have deployed DirectAccess.

Exposure

DirectAccess servers are deployed to provide secure remote access and are, necessarily, exposed to the public Internet. Sometimes, this is a direct connection (not recommended) or behind an edge firewall or load balancer. In either case, anyone can establish a TCP connection from the Internet to the DirectAccess server by default. If the DirectAccess server has a global unicast IPv6 address assigned to its external interface, that presents a worst-case scenario for exposure. Administrators should update their DirectAccess servers immediately. There are some other mitigation options, though. See below for more details.

IPv6 Transition

DirectAccess servers are usually reachable on the public Internet via IPv4 only. The lack of direct IPv6 connectivity significantly reduces the attack vector for this vulnerability. However, DirectAccess servers use various IPv6 transition technologies that could present additional risks.

Tunnel Establishment

Clients on the Internet can establish an IPv6 transition tunnel to the DirectAccess server without authentication. Once the tunnel is established, the client will receive a router advertisement (RA) and establish an IPv6 address on link. However, communication over the link requires IPsec. Although an attacker can obtain an IPv6 address, they require authentication to send TCP and UDP traffic inside the tunnel.

ICMP

It’s important to know that ICMP traffic inside the DirectAccess IPv6 transition tunnel is exempt from IPsec policy processing, by default. It is unclear whether the “specially crafted packets” an attacker must send to exploit this vulnerability can be ICMP packets. If that’s the case, this introduces significant risks and increases exposure exponentially. I will update this post if I learn anything more about this specifically.

Mitigation

The best and most obvious way to mitigate this attack is to immediately apply the Microsoft security updates. However, some additional controls can be effective in mitigating this risk.

Authentication

As mentioned, DirectAccess allows IPv6 transition tunnels to be established by default without authentication. However, it is possible to update the DirectAccess configuration to support authentication, as described here.

https://directaccess.richardhicks.com/2016/06/13/directaccess-ip-https-preauthentication/

Note: Updating the DirectAccess configuration can be impactful for remote users. Be sure to test this change in a lab environment before implementing in production.

Load Balancers

If the DirectAccess server is behind a load balancer, it can be configured to require authentication for DirectAccess IPv6 transition tunnels. Below is published guidance for configuring popular load balancers to support this.

F5 BIG-IP

Citrix ADC (formerly NetScaler)

Additional Information

Microsoft Windows TCP/IP Remote Code Execution Vulnerability

DirectAccess IP-HTTPS Preauthentication

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

DirectAccess IP-HTTPS Preauthentication using Citrix ADC (formerly NetScaler)

Absolute Secure Access and IPv6

Absolute Secure Access (formerly NetMotion Mobility) is a premium enterprise secure remote access solution with deep user and application insight supporting Windows, Mac, iOS (iPhone and iPad), and Android devices. Although Absolute Secure Access supports IPv6 for remote network connections and client IP address assignment, the latter is not enabled by default. Administrators must make additional changes to the configuration to assign IPv6 addresses to their clients so they can access resources inside the tunnel using IPv6.

DHCPv6 and SLAAC

Absolute Secure Access supports DHCPv6 and Stateless Address Autoconfiguration (SLAAC) methods for assigning IPv6 addresses to connected clients. Although IPv6 client addressing is not enabled by default, it is quick and easy to configure.

Note: Absolute Secure Access does not currently support static IPv6 prefix assignment.

Enable IPv6

To enable IPv6 global support for all Absolute Secure Access clients, open the Secure Access management console and navigate to Configure > Client Settings > Virtual Address > Allocation Method: IPv6. Administrators can choose to support either DHCPv6 alone or DHCPv6 and SLAAC. After making a selection, click the Apply button to save the changes.

Once configured, Absolute Secure Access clients will be assigned an IPv6 address and can access IPv6 resources over the Secure Access tunnel.

Split Tunneling

If you have configured the Absolute Secure Access policy for split tunneling, ensure you have included your internal IPv6 prefix(es) defined in the split tunneling policy.

Additional Information

NetMotion Mobility is now Absolute Secure Access

Absolute Secure Access Zero Trust Network Access (ZTNA)

What’s New in Absolute Secure Access v13

Absolute Secure Access Features and Capabilities

Absolute Secure Access Advanced Features In Depth

Enterprise Zero Trust Network Access (ZTNA) and VPN

Always On VPN Client IP Address Assignment Methods

When Always On VPN clients connect to the VPN server, they must be assigned an IP address to facilitate network communication. When using Windows Server and Routing and Remote Access Service (RRAS) for VPN services, administrators must choose between Dynamic Host Configuration Protocol (DHCP) and static address pool assignment methods.

DHCP

DHCP is a quick and easy way to handle VPN client IP address assignment. However, there are some drawbacks and limitations associated with this option. Consider the following.

Allocation

DHCP for Always On VPN clients does not work as you might expect. For example, when a VPN client connects, it does not obtain its IP address directly from the DHCP server. Instead, the VPN server leases a block of IP addresses from the DHCP server and manages those on behalf of its clients. On the DHCP server, you will see the Unique ID column of these IP address leases indicating RAS.

Address Block Size

After configuring the VPN server to use DHCP VPN client IP address assignment, the VPN server will automatically lease a block of ten IP addresses from a DHCP server. When this initial block of ten IP addresses is exhausted, the VPN server will lease another block of ten IP addresses. Administrators can increase the size of the requested address block by creating the following registry key on each VPN server.

Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IP
Value: InitialAddressPoolSize
Type: DWORD
Data: <size of DHCP pool request>

Alternatively, administrators can download Update-VpnServerDhcpPoolSize.ps1 from my GitHub repository and run it on each VPN server to increase the size of the initial DHCP address pool request.

DHCP Options

The VPN server discards all DHCP option information returned by the DHCP server. The VPN server uses only the IP address from the DHCP lease. The client is unaware of any other information in the DHCP lease.

Subnet

By default, the VPN server will only request DHCP addresses from a scope that matches the same subnet as the IP address assigned to the VPN server’s network adapter. If the VPN server has more than one network interface, it will send DHCP requests from the network interface listed on the Adapter drop-down list, as shown here.

Note: This option is only available on servers configured with multiple network interfaces. Also, if the value is set to Allow RAS to select adapter, it is best to specifically define the network interface where DHCP and DNS requests are made.

Scope Size

When using the DHCP assignment method, ensure the DHCP scope contains enough IP addresses to support the number of concurrent connections expected on all VPN servers.

IPv6

DHCPv6 is not supported on RRAS for VPN client IP address assignment. The only option for IPv6 is prefix assignment.

RRAS in Azure

DHCP is not supported when deploying RRAS in Azure. Administrators deploying RRAS in Azure to support Always On VPN must use the static address pool assignment method. More details here.

Known Issues

When using DHCP with Windows Server 2019 RRAS servers, a known issue prevents this from working correctly. Administrators can download Update-VpnServerDhcpPrivileges.ps1 from my GitHub repository and run it on each VPN server to ensure proper DHCP operation.

Increased Complexity

Since the VPN server leases IP addresses on behalf of clients and discards DHCP option information included in the lease, there’s no real benefit to using DHCP. Using DHCP only adds complexity and introduces another dependency, making the solution more brittle and difficult to manage. Using the static address pool assignment method is a better choice.

Static Pool

Implementation best practices dictate using the static address pool assignment method instead of DHCP. The following is guidance for configuring RRAS to support the static address pool option for VPN client IP address assignment.

Unique Subnet

Using a unique IP subnet is best when using the static address pool assignment method. However, this also requires configuring internal network routing to return traffic for that subnet to the individual VPN server where that subnet is assigned. Each server must have a unique IP address pool assigned. Define static address pools using subnet boundaries when configuring multiple VPN servers. Assigning IP address pools along subnet boundaries simplifies internal network routing configuration. Ensure that assigned IP address pool subnets are large enough to accommodate the total number of concurrent connections expected on each server. Be sure to overprovision to handle failover scenarios.

Same Subnet

Alternatively, administrators can assign VPN client IP addresses from the same subnet as the VPN server’s network interface. Assigning VPN client IP addresses from the same subnet as the VPN server eliminates the need for any internal network routing configuration, simplifying deployment. However, server subnets are often small and may not have enough IP address space to support numerous concurrent VPN connections. Be sure to plan accordingly.

Static IP Addresses

It is possible to assign a static IP address to an individual user. However, assigning a static IP address to a specific device is not. I will discuss static IP address assignments for Always On VPN clients in a future blog post.

Other Limitations

Here are some additional things to consider when creating a VPN client IP addressing strategy.

DNS

Always On VPN clients can be configured to register their IP address in DNS. However, the VPN client configuration controls this setting. The DHCP server does not register IP addresses in DNS when using DHCP. The client registers its IP address in DNS directly after it connects. In addition, a VPN client will receive a different IP address each time it connects to the VPN server. DNS propagation can delay hostname resolution on-premises for remote-connected VPN clients.

Selective Addressing

Regardless of which assignment method is selected, assigning different IP addresses to different types of connections is not possible. For example, a common ask is to assign user connections from one IP address pool and device connections from another. The only option to support this is to use different servers for each type of connection.

Summary

The best practice for IPv4 VPN client addressing is to use the static address pool method with a unique IPv4 subnet per server. Using static address pool assignment provides the most flexible configuration options and eliminates the dependency on internal services, making the solution more resilient and easier to manage. A unique address pool per server ensures that a large enough subnet can be defined to support the expected number of concurrent connections, regardless of the subnet size the VPN server is assigned to. Also, a unique IP subnet for VPN clients makes configuring internal firewall rules to control VPN client access easier.

Additional Information

Always On VPN and IPv6

Always On VPN Client DNS Server Configuration

Always On VPN Routing Configuration

Always On VPN RRAS Internal Interface Non-Operational