Sunday, December 13, 2020

Modern Problems Require Modern Solutions: Split-Tunnel Client VPNs

Spent some time lately thinking about the approaches to corporate client VPNs, during a time of a pandemic, which has changed how a number of companies are operating. Namely, organizations are relying on their ability to remotely enable their workforce. To do this efficiently, there are modern strategies and tactics built into products engineers and management should be familiar with in order to achieve the best end user experience, and most efficient use of remote access to the company's information assets. Turns out, good end user experiences will also create both network performance increases, and potential cost savings.

Chris

VPNs as an Enabler

Virtual Private Networks, or VPNs, by their nature, are designed to protect network traffic from a network or individual machine, to another remote machine, or network.  VPNs have been around for a long time, supporting and securing corporate network communications from laptops, desktops, and remote offices back to the main office or data center. 

In the case of a client VPN, you're connecting your desktop/laptop to the corporate network, so you and your machine can work just like it did in the office.

Yes, desktops can VPN too, especially in the days of 100% WFH because of Covid quarantining and "safe distancing". Companies are just as likely to ship a desktop to a person's home to establish a home office when people are WFH.

So let's walk through the progression of remote access solutions, and what's possible today, selective split tunneling.

Remote Access Solution #1: Decentralized Broad Internet Access Creates Problems

Back in the day...companies didn't have high bandwidth connections, to the home office, or to the Internet. Given that, Network Admins wanted to only Corporate traffic to come back to Corporate networks, allowing users to use the local Internet connections for general Internet access. This is called "split tunneling" because you're splitting the VPN tunnel to allow network traffic outside the VPN, to access local or Internet resources. This saved on Corporate expenses around Internet bandwidth, and other overhead in managing people's Internet traffic.

There are potential problems with deciding routing for Internet traffic at the client level. Say you only route "company" traffic back to the company over a VPN. Or, in the case of a remote office, say you access the Internet using the local office connection, and you only route "corporate" traffic back to the "home office". Something like this:

Understanding Split Tunneling

The problem with this configuration is primarily that there may not be the same Internet controls, like URL filtering or other network security monitoring controls in place in each remote office, or on each client, to protect the company's assets from compromise.

Short-sighted companies without cybersecurity guidance frequently chose this configuration to save on costs and "create network efficiencies". 

Companies with information security expertise would tend to gravitate to solution #2...

Remote Access Solution #2: Centralizing Network Security Monitoring is Popular

This is the model we've been using since 1995, at least. Here's a basic example of what a traditional corporate VPN looks like because of the aforementioned issues with decentralized Internet access.  
Split Tunnel VPNs Improve Performance of Cloud Apps for Remote Workers |  Techtron
In this example, the VPN Gateway is typically at your Corporate HQ/Data Center, and you get access to both local resources and the Internet, including all your SaaS providers like Office365, or Service Now, or Zoom, or WebEx, etc. 

The advantage to this is primarily network controls and visibility, since all traffic from the client comes back to the centrally managed, on-premise corporate information security controls. This includes things like
  • Network traffic monitoring through IDS/IPS
  • Basic firewalling, blocking general network access to both local networks and the Internet, since you won't know whether or not the laptop is in a hostile airport or hotel network or an unmaintained home network. 
  • Category-based and specific URL blocking/permissions/reporting
  • "next gen" firewall application security capabilities, monitoring application layer traffic
  • network monitoring for data loss prevention (DLP) capabilities

Remote Access Solution #3: Selective Split Tunneling

As corporate software solutions have evolved to more Software-as-a-Service (SaaS) models, more of what we use in the day-to-day has moved to web-based, Internet-based service and software portals, companies have been moving to add more Internet bandwidth, adding SAML-based authentication, and providing more scrutiny and assessment of SaaS providers who provide business essential services.

Cyber-mature organizations will see a new way forward, to move beyond the Standard Corporate VPN, to enable both efficient use of network and Internet traffic, as well as maintaining expected and required cybersecurity controls.

This is still called VPN Split Tunneling, but is more appropriately called, Selective Split Tunneling. Here's what this looks like, from a Cisco WebEx perspective:
 


And, from a SaaS industry perspective, *ALL* of the high bandwidth SaaS application providers are going to recommend split tunneling Corporate VPNs for their services. I've seen this from Zoom and O365, as well.  Here's the O365 guidance.

Implementing VPN split tunneling for Office 365 - Microsoft 365 Enterprise  | Microsoft Docs

The controversy; dogma, NIST and current realities

If anyone has a rub with this design, its typically because dogma would have you believe split tunneling is risky behavior. May older information security frameworks, based on a compliance regimen, still prescribe that spilt-tunneling opens organizations up to additional risk. Traditional guidance on this topic is probably 10-15 years old. 

"Thou shalt not split tunnel VPNs!" 


That guidance was fine when VPNs only had two settings: no split tunneling, and only split the tunnel for specific networks you want to run through the VPN. But times have changed.

Modern problems require modern solutions

These days VPN capabilities are more robust and more capable, allowing for split tunneling for Zoom or Office 365, or other SaaS solutions. Companies should do this *if, and only if* a company is assessing their SaaS solutions for cybersecurity controls prior to their use. "Trust but Verify".

Allowing SaaS traffic to operate outside of the Corporate VPN should only minimally increase risk. The top SaaS solutions should care about and are taking actions to protect their traffic (Zoom was challenged on this point for a while in 2020, though, to be transparent). As a part of your own Vendor Risk Assessment, you should validate that a vendor is encrypting traffic between your clients and the SaaS provider.

But, but, but, you can't see or stop "bad" traffic!


Sure, you may not have network monitoring. You have to check your assumptions and ask yourself if you really have that visibility today. Do you intercept SSL? Would you intercept Zoom calls? Would you intercept WebEx? My bet is no.

Conclusion

I'd argue there's less reason, and little risk, to push full SSL-enabled web traffic through a VPN to partner organizations where the controls have been evaluated and understood, with contracts to enforce them. Yes, partner compromises happen (ahem Target), so it's highly dependent on the situation, but it seems like we should be taking a risk-based approach and not be just repeating dated dogma.

What points did I skip over, or miss? Or do you interpret differently? Comment below. Let me know what you think.

Chris

More info:
How to configure Cisco gear for split tunneling for O365, WebEx and Zoom: https://community.cisco.com/t5/vpn/split-tunnel-webex-outlook365-zoom/td-p/4049533

Monday, August 24, 2020

Fixing Steam 0 bytes available disk space issue when removing a drive from the system





 Ran into an issue this weekend, so I'm memorializing it here. 

I had two drives in my system, one SSD for the OS and one high capacity spinning drive for secondary, slower storage. The second drive is where I put my Steam Library.

I pulled the drive this weekend to put into another machine I'm using for temporary file storage while I migrate Synology servers (longer story). This 1TB drive was holding my Steam Library.


I went into Steam, and Steam recognized that the SteamLibrary folder was no longer present and set the default back to the C:\ drive. I thought I was all good.

Fast forward a week and I have picked up a used NVidia card, and wanted to test it out. Went to download/reinstall the game and Steam says there's "0 bytes available" even though there's no other Steam folder, and the DEFAULT is set to the C:\ drive.


Here's what I did, that wasn't covered by other posts and threads I found: 


1) Go to Steam Settings

2) then Downloads

3) then click Steam Library Folders


4) then right-click on the directory shown and click on Make Default Folder. (yes, yes, even though it says it's already the default)

5) then right-click on the directory again and click on Repair Library Folder. Steam will restart.

You're done. Try installing games again.



Sunday, January 26, 2020

Synology, Mac OS X, OpenVPN and Tunnelblick

I'm putting this here so it shows up in your chosen search engine more easily.

If you have a Synology NAS, have the VPN Server installed, configured OpenVPN and use an Apple Macbook with OSX with Tunnelblick as your VPN client, you've probably seen this message:
Warning: This VPN may not connect in the future. The OpenVPN configuration file for 'Undercity OpenVPN' contains these OpenVPN options: 'comp-lzo' was deprecated in OpenVPN 2.4 and removed in OpenVPN 2.5 You should update the configuration so it can be used with modern versions of OpenVPN. Tunnelblick will use OpenVPN 2.4.4 - OpenSSL v1.0.2n to connect this configuration. However, you will not be able to connect to this VPN with future versions of Tunnelblick that do not include a version of OpenVPN that accepts the options.
All you have to do to ensure compression is enabled, through the config file is to replace one line in the ovpn config file you're using. Replace the line with
comp-lzo
with 
compress lzo
You won't have the warning message show up in the Log window after that.

Chris