Always On VPN Split vs. Force Tunneling

Always On VPN Split vs. Force TunnelingDuring the planning phase of a Windows 10 Always On VPN implementation the administrator must decide between two tunneling options for VPN client traffic – split tunneling or force tunneling. When split tunneling is configured, only traffic for the on-premises network is routed over the VPN tunnel. Everything else is sent directly to the Internet. With force tunneling, all client traffic, including Internet traffic, is routed over the VPN tunnel. There’s been much discussion recently on this topic, and this article serves to outline the advantages and disadvantages for both tunneling methods.

Force Tunneling

Force tunneling is typically enabled to meet the following requirements.

Visibility and Control

By routing all the client’s Internet traffic over the VPN tunnel, administrators can inspect, filter, and log Internet traffic using existing on-premises security solutions such as web proxies, content filters, or Next Generation Firewalls (NGFW).

Privacy

Enabling force tunneling ensures privacy and protection of all Internet communication. By routing all Internet traffic over the VPN, administrators can be certain that all communication from the Always On VPN client is encrypted, even when clients access unencrypted web sites or use untrusted or insecure wireless networks.

Force Tunneling Drawbacks

While configuring force tunneling for Always On VPN has some advantages, it comes with some serious limitations as well.

Poor User Experience

User experience is often degraded when all Internet traffic is routed over the VPN. These suboptimal network paths increase latency, and VPN encapsulation and encryption overhead increase fragmentation, leading to reduced throughput. Most Internet traffic is already encrypted in some form, and encrypting traffic that is already encrypted makes the problem even worse. In addition, force tunneling short-circuits geographic-based Content Delivery Networks (CDNs) further reducing Internet performance. Further, location-based services are often broken which can lead to improper default language selection or inaccurate web search results.

Increased Resource Consumption

Additional resources may need to be provisioned to support force tunneling. With corporate and Internet traffic coming over the VPN, more CPU, memory, and network resources may be required. Deploying additional VPN servers and higher throughput load balancers to support the increase in network traffic may also be necessary. Force tunneling also places higher demands on Internet Service Provider (ISP) links to the corporate datacenter.

Split Tunneling

The alternative to force tunneling is “split tunneling”. With split tunneling configured, only traffic destined for the internal corporate network is routed over the VPN. All other traffic is sent directly to the Internet. Administrators define IP networks that should be routed over the VPN, and those networks are added to the routing table on the VPN client.

Security Enforcement

The challenge of providing visibility and control of Internet traffic with split tunneling enabled can be met using a variety of third-party security solutions. Microsoft Defender ATP recently introduced support for web content filtering. Also, there are numerous cloud-based security offerings from many vendors that allow administrators to monitor and control client-based Internet traffic. Zscaler and Cisco Umbrella are two popular solutions, and no doubt there are many more to choose from.

Recommendations

The general guidance I provide customers is to use split tunneling whenever possible, as it provides the best user experience and reduces demands on existing on-premises infrastructure. Enabling split or force tunneling is ultimately a design decision that must be made during the planning phase of an Always On VPN implementation project. Both configurations are supported, and they each have their merits.

In today’s world, with many applications accessible via public interfaces, force tunneling is an antiquated method for providing visibility and control for managed devices in the field. If required, investigate the use of Microsoft or other third-party solutions that enforce security policy in place without the requirement to backhaul client Internet traffic to the datacenter over VPN for inspection, logging, and filtering.

Additional Information

Whitepaper: Enhancing VPN Performance at Microsoft

Whitepaper: How Microsoft Is Keeping Its Remote Workforce Connected

Microsoft Defender ATP Web Content Filtering

DirectAccess SQL Server High CPU Usage

UPDATE – March 14, 2016: Microsoft has published official guidance for implementing the changes outlined in this article using PowerShell. Details here.

Introduction

DirectAccess SQL Server High CPU UsageRADIUS and Inbox accounting are the two supported logging options for DirectAccess in Windows Server 2012 R2. When Inbox accounting is selected, a Windows Internal Database (WID) is provisioned. Part of the base operating system, WID is functionally similar to SQL Server Express.

SQL Server Utilization Issues

Over the last few months I’ve had a few customers reach out to me with a peculiar performance issue. For customers with very busy DirectAccess servers, where those servers have also been configured to use Inbox accounting, they’ve reported observing unusually high CPU utilization on the sqlservr.exe process.

DirectAccess SQL Server High CPU Usage
Image courtesy Thomas Vuylsteke. Used with permission. – setspn.blogspot.com

As luck would have it, Thomas Vuylsteke, a Microsoft Platforms Premiere Field Engineer (PFE), had already identified the issue and a workaround. Thomas traced the source of high CPU utilization on the sqlservr.exe process to a missing index on a session state table in the DirectAccess accounting database. If you are interested in learning how he performed the troubleshooting to identify and resolve this problem, you can read his entire blog post here.

Resolution

To resolve this issue, create an index on the Session Table in the DirectAccess database. Changes to WID must be made locally, as it is not remotely manageable. WID does not include a management interface, which means the SQL Server management tools would normally have to be installed. However, I’m not a fan of installing any extraneous software on the DirectAccess server, so thankfully one of the readers of Thomas’ excellent article on this subject, Fredrik Elmqvist, provided a very helpful alternative. Fredrik suggesting using the HeidiSQL tool, for which a fully portable version exists. This allows for changes to be made to the WID database without having to install any additional software.

Changes to WID

Begin by downloading the portable version of HeidiSQL here. Next, log on to the DirectAccess server as the local administrator. It is crucial that you must be the local administrator, not just a local or domain user with local administrator privileges. Extract the files from the download and copy them to the DirectAccess server, then follow these steps:

  1. Double-click heideisql.exe to launch the management tool.
  2. Click on New and then for the Network Type select Microsoft SQL Server (named pipe).
  3. For the Hostname / IP: enter \\.\pipe\MICROSOFT##WID\tsql\query.
  4. Select the option to Use Windows Authentication.
  5. Click Open to continue.DirectAccess SQL Server High CPU Usage
  6. Click the Query tab in the center console window and enter the following commands:
    Use RaAcctDb
    Create NonClustered Index IdxSessionTblSessionState on SessionTable (SessionState,ConnectionID)
  7. Click the Run icon in the tool bar or press F9. This will execute the code and create the missing index on the Session Table in the DirectAccess database.DirectAccess SQL Server High CPU Usage
  8. Confirm the index was created by clearing the previous query or creating a new query and then entering the following commands:
    select * from sys.indexes
    where name like ‘idx%’
    order by name ascDirectAccess SQL Server High CPU Usage

Summary
Once the change has been made, sqlservr.exe CPU utilization should return to normal. If you have multiple DirectAccess servers configured in a load-balanced array or in a multisite configuration, be sure to repeat these steps on each DirectAccess server in the organization.

Monitoring DirectAccess Machine and User Activity with Windows Component Event Logging

Monitoring DirectAccess Machine and User Activity with Component Event LoggingThe monitoring of DirectAccess machine and user activity presents some unique challenges for security administrators. All DirectAccess client communication destined for the internal corporate network is translated by the DirectAccess server and appears to originate from the DirectAccess server’s internal IPv4 address. Also, the public IPv4 address for DirectAccess clients using the IP-HTTPS IPv6 transition protocol is not visible using the native reporting tools. In addition, vital information such as source ports used by the DirectAccess server for internal connections and source ports used by DirectAccess clients is not available. This lack of granular connection logging creates a serious blind spot for administrators conducting forensic investigations.

As veteran Microsoft Premier Field Engineer (PFE) Martin Solis described in detail in a recent blog post, all of these details are in fact logged. However, gathering this information is not exactly intuitive. To collect this essential information it will be necessary to leverage Windows component event logging. By searching the IPHLPSVC, Base Filtering Engine Connections, Base Filtering Resource Flows, and WinNAT operational logs, it is possible to gather all of the information necessary for uniquely identifying DirectAccess corporate network communication.

Be sure to read Martin’s excellent article about using Windows component event logging to monitor DirectAccess machine and user activity, which can be found here.

%d bloggers like this: