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

Tuesday, March 13, 2018

LABRAT graffiti up and down Puget Sound

Rail bridge over I-5 South with
LABRAT KNATS graffiti.
Living in Puget Sound over the last decade, I've noticed tagging and graffiti with LABRAT or LABRAT KNATS across bridges downtown, by Lacey (picture below, the site of the recent train derailment) and down to Olympia, Washington (State).

To be clear, this graffiti is not mine, or is it associated with me. Just in case there was any question... (ha ha, lol)

(photo credit: Wikipedia)

Synology Let's Encrypt SSL certificate failure and ASUS AC68U

So...I was running my own SSL cert from a free SSL certificate provider SSLForFree.com but thought I'd try the built in capability of my Synology DS413J to provision one from Let's Encrypt for free.

I walked through the menus to find the Control Panel, Security, and Certificates tab. Once I walked through adding/replacing a cert, I receive this error:


For clarity, this is what it says:
     Get a Certificate from Let's Encrypt
   
     Failed to connect to Let's Encrypt. Please make sure your DiskStation and router have port 80
     open to Let's Encrypt domain validation from the Internet. All the other communications with
     Let's Encrypt go over HTTPS to keep your DiskStation secure.

I originally was thinking my router, an Asus AC68U, wasn't capable of forwarding port 80 because it uses that port for the web interface. Turns out that later software updates fixed this issue and is now able to pass the traffic from outside:80->Synology:80. All good.

I made sure Web Station was running. And it still failed.

Turns out, I think the biggest issue was that even though the screen suggests you should just use your top TLD, you really need to put in your full FQDN in both the domain name and the alternative subject name fields.

Then the wizard worked like a charm.

Good luck!
Chris

Friday, November 25, 2016

Kenwood TK-890 Amateur Radio Mod (repost)

(Now reposted/moved to my site focused on ham radio, ZebrasRunningWild. cg)

 I'm a ham radio operator and have been since 1987, when I got my Novice ticket in rural South Dakota (SD) at 14 years old. It's been a fun hobby, even though I took a break from roughly 1993-2013. So...to the point...

I went to the Mike and Key Ham Fest down in Puyallup, WA in the spring of 2015. Before I showed up there, I had been thinking about a GMRS license and radios for the family. I picked up a Kenwood TKR-820 repeater, already programmed to the GMRS repeater frequencies.

Kenwood TK-790/890 control head options, basic and advanced.
I also picked up 4 Kenwood TK-890 radios. I got a "good deal". They didn't come with microphones, but I didn't see that as a big deal...while I was at the ham fest. Once I got home, I found out differently. This particular breed of radio, as a result of the genius of Kenwood, doesn't have a standard microphone plug. As a result, microphones cost $65+ each. And the aftermarket doesn't make them. Stupid. I found a lot of 7 on eBay, for a reasonable price, so now I'm in action.

Anyway, this is a repost of an article I found on a blogspot post about how to tune the TK-890 to the high end of the 70cm ham bands. That article has since disappeared and the blogspot site is no longer in existence...so, I'm reposting the content here. (Thankfully, PDF'ed the article!)

Original article:
(from Wirelessness blog from W6DTW, originally at http://sparqi.blogspot.com/2013/05/tk-890-amateur-radio-mod.html)

Over the past weekend a friend of mine asked if I would help him convert his Kenwood TK-890 mobile to work on the ham bands. I wasn't sure how successful we'd be, since most every online search came up with at best little information or at worst flat out statement saying "Nope, can't be done." As it turns out, it can't be done. Kudos to Time K for his notes posted to Radio Reference [cg, I also placed the relevant content at the end] which gave enough hints to make this happen.

In general this is how it went. My friend wanted his radio to work on the Bay-Net repeater system, which operates 443.225 with a +5 MHz TX split. TX was fine, but RX was giving a steady "beep-beep-beep..." which indicates PLL unlock.

In the PLL section, under the copper foil, [cg, for the record, mine weren't) are three adjustment pots: A = TC302, B = TC303, and C = TC301. (Don't ask why they're out of order.) According to the Service Manual, Pot A sets the PLL for the low end of the receiver range, Pot B set the high end of the receiver range, and Pot C sets the TX PLL. The goal is to monitor testpoint CV with a voltmeter and adjust for minimum voltage during RX and TX. This requires reprogramming the radio's test frequencies to match the band of interest, so you'll need the [KPG-44] software and [KPG-4] cable.

Once we had the PLL voltages minimized for RX and TX, I found that the radio's TX frequency was way off, so a frequency alignment was needed. This again required the [KPG-44] software - for some reason we couldn't get the radio in to Panel Test/Tune via the control head. It was easy enough with the KPG, once we realized you need to press "Enter" to lock the modified value.

Other things like adjusting the BPF and checking deviations should be done. In the end, the conversation was very easy and the radio is working well on the UHF amateur band.

[cg Adding this here, to make it more complete, and have information all in one place.]
From Radio Reference:
From ramal121:
"The VCO can be adjusted fairly easy with a volt meter. You just program your highest and lowest frequencies, monitor the VCO steering line voltage, check high and low (both TX and RX) and see if the voltage stays within specs. There are tweekers for both TX and RX to achieve this. And yes, if you lower your VCO's range, you will lose the top freqs, the VCO can only swing so far."

From Tim K:

Thursday, November 3, 2016

For the record...HP Elitebook 840 G3 BIOS update

HP, in their wisdom, decided that a standard laptop BIOS update should sound like you're bricking your device. So, I'm posting this here so it will get picked up by Google and people don't need to freak out as much as I did. My experience was I ran the BIOS update, the machine started beeping with the screen blank and then I panicked, trying to figure out what I should do. After a bit of work, I found out that this is completely normal for these laptops, for this BIOS update. It is not normal in the world of systems BIOS updates, by any means.

Comment here if you have the same or a different experience.

- Run BIOS update
- Warning about bitlocker being suspended temporarily.
- Update completes
- Machine reboots automatically
- Screen blanks
- 2 long beeps, 2 short beeps x 5
- Reboot
- 1 long beep, 2 short beeps
- 2 long beeps, 2 short beeps x 4
- Reboot x 2
- Full, white screen notification of DXE update
- Reboot
- Back to Windows login

Chris