Microsoft—and Ars—advise split-tunnel VPNs to minimize coronavirus woes

When SARS hit its peak, remote work wasn’t yet practical enough for quarantine efforts to affect office networks much. With the coronavirus, though, most of the toolset needed to work from home or the road is available—but many office networks are having difficulty handling the sudden increase in scale.

Internet scale versus VPN scale

There’s not much you can do about a WAN (Wide Area Network) connection that isn’t robust enough to handle traffic from remote workers to internal infrastructure such as file servers and application servers. But much of a typical company’s infrastructure isn’t onsite at all anymore—it’s increasingly likely to be hosted in the cloud, behind its own set of protective firewalls and filters.

Traditionally, most office VPNs are set up to route not just office traffic, but all traffic—including Internet-destined traffic—across the user’s VPN tunnel. For most sites, that means paying a double penalty—or worse—for all Internet traffic from VPN-connected users. Each HTTPS request and its subsequent response must hit both the upload and download side of the office’s WAN twice. This is bad enough with a symmetric WAN—e.g., a 500Mbps fiber link—but it’s beyond punishing for an asymmetric WAN, such as a 100Mbps-down/10Mbps-up coaxial link.

The idea behind globally routed VPN tunnels is to allow an office firewall to inspect and monitor all traffic. Modern Internet traffic is almost entirely end-to-end encrypted, however, which makes such inspection of dubious value. There’s little reason to route Office 365 traffic through a typical office’s local Internet connection, instead of allowing it to flow directly from remote worker to the cloud.

Routing as much as possible directly to the Internet

We generally advise routing only office-bound traffic over an office VPN and allowing all Internet traffic to proceed directly to its destination—this can easily reduce VPN traffic by an order of magnitude or more, and the router-level filtering and monitoring in most offices isn’t particularly useful in the first place.

Doing things this way is simple—the network administrator disables global routing in their VPN configurations and only routes the office’s subnet(s) across the tunnel. The details vary by VPN implementation, but in Cisco VPN clients, for example, it’s a simple checkbox to be ticked on or off.

Allow direct Internet routing for Office 365 only

Somewhat more paranoid (or Orwellian) environments might not be willing to relinquish all control over Internet-bound traffic, however, preferring instead to only enable known-safe services—such as Office 365.

This raises the question, how do you identify Office 365-bound traffic? Microsoft provides an API for identifying Microsoft service endpoints, which can be queried via a Powershell script. Although the company recommends setting up a dynamic, regular update procedure to use the API to harvest all necessary endpoints, Microsoft has also provided a simple list that’s correct for now.

IPv6, unfortunately, gets its usual “eh, maybe later” treatment—Microsoft advises that IPv6 endpoints can simply be ignored and notes that its services “will currently operate successfully on IPv4 only, but not the other way around.”

Listing image by CDC