7 ms·

Selecting and Hardening Remote Access VPN Solutions [pdf]

132 points by EastOfTruth 5y ago

WatchDog 5y ago
A lot of warnings against TLS based VPN solutions. I imagine these solutions are popular because they are more likely to function through corporate firewalls, where IPsec might be blocked. Unsurprisingly no mention of wireguard, as it's not FIPS. However, unless you need FIPS compliance, it seems like the way to go these days.
- mianos 5y ago
  With something like OpenVPN, they seem to have strong issues with some exploitable parts of the startup/bring-up process. There are two ways to look at this: It's either too good for them or it's bad. :)
  - collsni 5y ago
    Well yeah they're only going to recommend solutions they have a back door into :). Jk I hope..
- Galanwe 5y ago
  > I imagine these solutions are popular because they are more likely to function through corporate firewalls, where IPsec might be blocked. I implement IPSec at work, because we need the real deal. Though for my personal projects, my infra is using OpenVPN. The reason is simple: it's so much easier to configure and understand, and the desktop clients are usually more modern and stable. With IPsec, there's always these plethora of extensions and subtleties that each client will support or not. Clients will support Cisco IPsec but will bug with strongswan, strongswan clients will not play well with windows, Android client will not support IKEv2, etc etc etc. From my experience, there's a lot of "finding the right client for the right setup for each platform" with IPsec. For OpenVPN, usually the native windows/Linux(NM) clients will work out of the box, which is a much better experience than a third party client. As for TLS VPNs being more prone to vulnerabilities, that does not scare me all that much, since there's always SSH behind the VPN anyway, so it's usually "good enough" for non corporate security.
- wahern 5y ago
  > Unsurprisingly no mention of wireguard The hard part of a VPN, the part that everybody makes money at, isn't the IP-level encapsulation. Yes, Wireguard is both conceptually and in implementation simpler and more elegant in this regard. But IPSec per se isn't actually a real pain point in real world corporate road warrior deployments, at least not any more than with Wireguard, which can have very similar issues with MTUs, NAT timeouts, etc when dealing with the diversity of remote user networks. The hard part of a corporate VPN is authentication, address assignment, subnet routing, nameserver announcements, etc. Therein lies the hard, dirty, complex pieces. Many IPSec-based VPNs utilize IKE for that, although some don't and utilize bespoke, hacky solutions. Most of the horror stories of configuring IPSec relate to IKE, and much of the complexity there is irreducible. (Though I rejoiced when Android finally added native IKEv2 support--years after Windows, macOS, and iPhone--as IKEv2 substantially reduces some of the complexity relative to IKEv1.) Wireguard provides none of that. Instead, you have to build that stuff separately, and in the realm of Wireguard it's still the wild west, with people slapping together management frameworks with all the dubious quality and opaqueness that have made the traditional VPN ecosystem a nightmare. (The Wireguard team is working on and publishes a separate project for that aspect, but AFAIU it's not widely used and in any event is far removed by its nature from the stark elegance of the transport layer Wireguard protocol.) But the year is 2021. Every major platform today, including Debian- and RedHat-based Linux, FreeBSD, NetBSD, OpenBSD, macOS, Android, and iPhone, ships with a modern, native IPSec+IKEv2 stack that is highly interoperable and provides, at least in the simple case, certificate-based authentication, dynamic address assignment and subnet routing, and nameserver advertisement. And, importantly, they all support modern cipher suites so the old problem of finding compatible suites is (or could be, in new deployments) a distant memory--everybody supports ECDH P256, AES128-GCM, etc. On my work-issued macOS laptop the third-party VPN software simply uses native IPSec and a custom IKE daemon. Though as far as I can tell from the configuration the custom daemon is just technical debt from building the product before macOS' IKE daemon (racoon fork) was more mature. And in fact, AFAICT there's absolutely nothing of value, beside IT familiarity, that macOS' IPSec+IKEv2 stack doesn't provide. An equivalent VPN setup using the native stack requires nothing more than a username, password, certificate, and a hostname for the endpoint. You don't need to install a third-party client to automate entering that information; heck, you don't really even need to automate it at all, not any more than you need to automate sending a person to gmail.com or outlook.com for their e-mail. When you're comparing Apples + Apples, I personally don't think Wireguard is a serious choice for corporate, road warrior VPN access. On most key points, actual Wireguard-based systems are qualitatively worse. The story is different for static point-to-point, server-to-server communications, especially when you can do static address assignments on the tunnel interfaces. In such scenarios the simplicity of Wireguard shines through. But in those scenarios the popular solution is more often OpenVPN than IPSec. I simply don't see Wireguard replacing IPSec for corporate VPNs. I hope I don't ever see that because good VPN solutions should be deeply integrated with the host system (e.g. to help prevent leakage, integrate DNS resolution, etc), and you're just not going to see that with Wireguard-based solutions. The situation isn't perfect on modern platforms, but it's much better than it was 10 or even 5 years ago, and its getting better and the pace of improvement has (relative to the past 20 years) picked up considerably.
- zxcvbn4038 5y ago
  I’ve found that ipsec/ike based VPNs are easily blocked and often unusable at airports, businesses, and with mobile data — pretty much every situation where you would want a VPN. However OpenVPN based protocols running over port 443 seem to magically work everywhere. I started testing Wireguard over ports 53 and 123 right before the pandemic so I can’t say as much regarding that one but I imagine it will have the same qualities as OpenVPN once http/3 becomes mainline and UDP traffic to port 443 becomes common. I was thrilled to see that ProtonVPN recently added openvpn over tcp as an option — I really wanted to give them money but a vpn that only works on networks I control has limited utility. Express VPN has offered openvpn over tcp for a while and they have been my go-to because it worked everywhere.
  - beermonster 5y ago
    > I was thrilled to see that ProtonVPN recently added openvpn over tcp as an option They also support WireGuard though currently in beta.
    - zxcvbn4038 5y ago
      Very cool, I’m curious to see how that is implemented, you would think that having thousands of dummy interfaces on all your edge nodes would be a pain to manage. I am guessing they have developed some way of creating interfaces dynamically
implying 5y ago
Strange how this implies that the end-all-be-all of VPNs is IPsec. I would've loved to hear their opinion on wireguard and this generation of mesh VPNs
- er4hn 5y ago
  That's because wireguard uses non FIPS 140 compliant algorithms. What would be really interesting is if the NSA told us their thoughts on the wireguard algos.
  - beermonster 5y ago
    Would you trust the NSA’s thoughts on recommended algs given their chequered history?
    - Spooky23 5y ago
      You need read between the lines and look at the full context of what they recommend. Just saying “NSA bad” is a lazy argument.
      - z3ncyberpunk 5y ago
        > Just saying “NSA bad” is a lazy argument. Yeah, so is that, and a stupid one given how much they, NIST, and the CIA rig things like elliptical curve standards
    - er4hn 5y ago
      I don't necessarily trust the NSA, things like DUAL EC DRBG are an excellent reason why. However the govt standards for cryptography to use are known as FIPS 140. These standards are made by NIST, which has the NSA either heavily own or directly write the documents. This means that the NSA is defining the crypto standards for the rest of US Gov. The conclusion is that if you want wireguard in govt networks, the NSA must bless their crypto primitives and algorithms. That's why I want to know their thoughts on it.
- 5y ago
josnyder 5y ago
I'm saddened that the answer isn't "Just use BeyondCorp". Layer 7 solutions provide so much more capacity for granular AuthZ, and thereby eliminate the "soft underbelly" of corporate networks.
- silverfox17 5y ago
  You're expecting the NSA to recommend BeyondCorp?
  - nvr219 5y ago
    Why wouldn't they?
  - tptacek 5y ago
    CISA actively advocates for Zero Trust, which is the generic name for this stuff.
    - beermonster 5y ago
      And NCSC
- kerng 5y ago
  Ah, "beyond corp" the Google marketing term that many industry misunderstood and then exposed their entire internal infra...
- theginger 5y ago
  It would dilute the messages in the guidance, it was also be quite patronising for anyone who has just been through a lengthy decision making process and concluded they still need a VPN, to be told they shouldn't be using a VPN.
sharmin123 5y ago
Explore Happy And Healthy Relationship Tips To Be Happy In Life: https://www.hackerslist.co/explore-happy-and-healthy-relationship-tips-to-be-happy-in-life/ https://www.hackerslist.co/explore-happy-and-healthy-relatio...
iJohnDoe 5y ago
FWIW, the NSA documents on recommended hardening approaches are usually pretty good. Their Cisco PDF many years ago was really good. Anyone have a non-PDF version of this? :-p
- beermonster 5y ago
  Their RHEL hardening guide was pretty solid advice and well written.
Helmut10001 5y ago
Isn't there a lot that can be done beyond VPN, to protect VPN? - Pre-filtering per Geo IP - 2FA - VLAN separation, different users and different subnets, once connected I am using both IPSEC and OpenVPN - they have different application/purpose and I need both.
- rsync 5y ago
  Any time I bother to use a VPN I also use a network slug[1]. I don't want to worry about implementation errors or weird bugs or DNS leaks or anything like that. A slug, which is a "transparent layer 2 firewall running on a device with only two interfaces" generally breaks your entire network if your VPN is not working exactly as you hope it will. [1] https://john.kozubik.com/pub/NetworkSlug/tip.html https://john.kozubik.com/pub/NetworkSlug/tip.html
system2 5y ago
I would love to hear SonicWall explaining why their SSL is superior to IPSec. They've advertised and forced many clients (including ours) to choose SSL VPN with expensive licensing. Now I read this as a bad choice. Very annoyed.
- bink 5y ago
  Vendors have to balance usability and security. That's always been the trade-off between IPSec and TLS. I don't envy people who have to provide support for IPSec solutions.
- beermonster 5y ago
  SSL/TLS based ones will just be more interoperable and have fewer connectivity issues through intermediary network devices and access points. But TLS has traditionally been a nightmare, crypto-wise, to say secure. POODLE, CRIME, BEAST et al. At least WireGuard is either secure or off.
andrewSC 5y ago
Anyone have a good link for reference [1] in the PDF? I tried navigating to it but get a 404. Potentially related URLs [2][3] I found also 404? Hm. [1] https://www.nsa.gov/cybersecurity-guidance https://www.nsa.gov/cybersecurity-guidance [2] https://www.nsa.gov/What-We-Do/Cybersecurity/Advisories-Technical-Guidance/ https://www.nsa.gov/What-We-Do/Cybersecurity/Advisories-Tech... [3] https://www.nsa.gov/what-we-do/cybersecurity/ https://www.nsa.gov/what-we-do/cybersecurity/
- EastOfTruth 5y ago
  I think that the problem is temporary because I tried many other NSA URLs and they all 404s Also,the reference [1] is also the same URL as references 6, 9, 10, 13, 16, 18, 19, 20, 21
moochi 5y ago
what's wrong with a TLS VPN ? (apart from performace bottlenecks) TLS v1.2 and v1.3 are still secure. Or, NSA has already found something to break it ?
PLG88 5y ago
For me, the answer to 'hardening' is to use an open source zero trust solution which is always outbound only thereby cannot be subject to network level attacks (OSI 3-5), e.g., DDoS, brute force, CVE exploit etc

132 points by EastOfTruth 5y ago

A lot of warnings against TLS based VPN solutions. I imagine these solutions are popular because they are more likely to function through corporate firewalls, where IPsec might be blocked. Unsurprisingly no mention of wireguard, as it's not FIPS. However, unless you need FIPS compliance, it seems like the way to go these days.

mianos 5y ago
With something like OpenVPN, they seem to have strong issues with some exploitable parts of the startup/bring-up process. There are two ways to look at this: It's either too good for them or it's bad. :)
- collsni 5y ago
  Well yeah they're only going to recommend solutions they have a back door into :). Jk I hope..
Galanwe 5y ago
> I imagine these solutions are popular because they are more likely to function through corporate firewalls, where IPsec might be blocked. I implement IPSec at work, because we need the real deal. Though for my personal projects, my infra is using OpenVPN. The reason is simple: it's so much easier to configure and understand, and the desktop clients are usually more modern and stable. With IPsec, there's always these plethora of extensions and subtleties that each client will support or not. Clients will support Cisco IPsec but will bug with strongswan, strongswan clients will not play well with windows, Android client will not support IKEv2, etc etc etc. From my experience, there's a lot of "finding the right client for the right setup for each platform" with IPsec. For OpenVPN, usually the native windows/Linux(NM) clients will work out of the box, which is a much better experience than a third party client. As for TLS VPNs being more prone to vulnerabilities, that does not scare me all that much, since there's always SSH behind the VPN anyway, so it's usually "good enough" for non corporate security.
wahern 5y ago
> Unsurprisingly no mention of wireguard The hard part of a VPN, the part that everybody makes money at, isn't the IP-level encapsulation. Yes, Wireguard is both conceptually and in implementation simpler and more elegant in this regard. But IPSec per se isn't actually a real pain point in real world corporate road warrior deployments, at least not any more than with Wireguard, which can have very similar issues with MTUs, NAT timeouts, etc when dealing with the diversity of remote user networks. The hard part of a corporate VPN is authentication, address assignment, subnet routing, nameserver announcements, etc. Therein lies the hard, dirty, complex pieces. Many IPSec-based VPNs utilize IKE for that, although some don't and utilize bespoke, hacky solutions. Most of the horror stories of configuring IPSec relate to IKE, and much of the complexity there is irreducible. (Though I rejoiced when Android finally added native IKEv2 support--years after Windows, macOS, and iPhone--as IKEv2 substantially reduces some of the complexity relative to IKEv1.) Wireguard provides none of that. Instead, you have to build that stuff separately, and in the realm of Wireguard it's still the wild west, with people slapping together management frameworks with all the dubious quality and opaqueness that have made the traditional VPN ecosystem a nightmare. (The Wireguard team is working on and publishes a separate project for that aspect, but AFAIU it's not widely used and in any event is far removed by its nature from the stark elegance of the transport layer Wireguard protocol.) But the year is 2021. Every major platform today, including Debian- and RedHat-based Linux, FreeBSD, NetBSD, OpenBSD, macOS, Android, and iPhone, ships with a modern, native IPSec+IKEv2 stack that is highly interoperable and provides, at least in the simple case, certificate-based authentication, dynamic address assignment and subnet routing, and nameserver advertisement. And, importantly, they all support modern cipher suites so the old problem of finding compatible suites is (or could be, in new deployments) a distant memory--everybody supports ECDH P256, AES128-GCM, etc. On my work-issued macOS laptop the third-party VPN software simply uses native IPSec and a custom IKE daemon. Though as far as I can tell from the configuration the custom daemon is just technical debt from building the product before macOS' IKE daemon (racoon fork) was more mature. And in fact, AFAICT there's absolutely nothing of value, beside IT familiarity, that macOS' IPSec+IKEv2 stack doesn't provide. An equivalent VPN setup using the native stack requires nothing more than a username, password, certificate, and a hostname for the endpoint. You don't need to install a third-party client to automate entering that information; heck, you don't really even need to automate it at all, not any more than you need to automate sending a person to gmail.com or outlook.com for their e-mail. When you're comparing Apples + Apples, I personally don't think Wireguard is a serious choice for corporate, road warrior VPN access. On most key points, actual Wireguard-based systems are qualitatively worse. The story is different for static point-to-point, server-to-server communications, especially when you can do static address assignments on the tunnel interfaces. In such scenarios the simplicity of Wireguard shines through. But in those scenarios the popular solution is more often OpenVPN than IPSec. I simply don't see Wireguard replacing IPSec for corporate VPNs. I hope I don't ever see that because good VPN solutions should be deeply integrated with the host system (e.g. to help prevent leakage, integrate DNS resolution, etc), and you're just not going to see that with Wireguard-based solutions. The situation isn't perfect on modern platforms, but it's much better than it was 10 or even 5 years ago, and its getting better and the pace of improvement has (relative to the past 20 years) picked up considerably.
zxcvbn4038 5y ago
I’ve found that ipsec/ike based VPNs are easily blocked and often unusable at airports, businesses, and with mobile data — pretty much every situation where you would want a VPN. However OpenVPN based protocols running over port 443 seem to magically work everywhere. I started testing Wireguard over ports 53 and 123 right before the pandemic so I can’t say as much regarding that one but I imagine it will have the same qualities as OpenVPN once http/3 becomes mainline and UDP traffic to port 443 becomes common. I was thrilled to see that ProtonVPN recently added openvpn over tcp as an option — I really wanted to give them money but a vpn that only works on networks I control has limited utility. Express VPN has offered openvpn over tcp for a while and they have been my go-to because it worked everywhere.
- beermonster 5y ago
  > I was thrilled to see that ProtonVPN recently added openvpn over tcp as an option They also support WireGuard though currently in beta.
  - zxcvbn4038 5y ago
    Very cool, I’m curious to see how that is implemented, you would think that having thousands of dummy interfaces on all your edge nodes would be a pain to manage. I am guessing they have developed some way of creating interfaces dynamically

implying 5y ago

Strange how this implies that the end-all-be-all of VPNs is IPsec. I would've loved to hear their opinion on wireguard and this generation of mesh VPNs

er4hn 5y ago
That's because wireguard uses non FIPS 140 compliant algorithms. What would be really interesting is if the NSA told us their thoughts on the wireguard algos.
- beermonster 5y ago
  Would you trust the NSA’s thoughts on recommended algs given their chequered history?
  - Spooky23 5y ago
    You need read between the lines and look at the full context of what they recommend. Just saying “NSA bad” is a lazy argument.
    - z3ncyberpunk 5y ago
      > Just saying “NSA bad” is a lazy argument. Yeah, so is that, and a stupid one given how much they, NIST, and the CIA rig things like elliptical curve standards
  - er4hn 5y ago
    I don't necessarily trust the NSA, things like DUAL EC DRBG are an excellent reason why. However the govt standards for cryptography to use are known as FIPS 140. These standards are made by NIST, which has the NSA either heavily own or directly write the documents. This means that the NSA is defining the crypto standards for the rest of US Gov. The conclusion is that if you want wireguard in govt networks, the NSA must bless their crypto primitives and algorithms. That's why I want to know their thoughts on it.
5y ago

josnyder 5y ago

I'm saddened that the answer isn't "Just use BeyondCorp". Layer 7 solutions provide so much more capacity for granular AuthZ, and thereby eliminate the "soft underbelly" of corporate networks.

silverfox17 5y ago
You're expecting the NSA to recommend BeyondCorp?
- nvr219 5y ago
  Why wouldn't they?
- tptacek 5y ago
  CISA actively advocates for Zero Trust, which is the generic name for this stuff.
  - beermonster 5y ago
    And NCSC
kerng 5y ago
Ah, "beyond corp" the Google marketing term that many industry misunderstood and then exposed their entire internal infra...
theginger 5y ago
It would dilute the messages in the guidance, it was also be quite patronising for anyone who has just been through a lengthy decision making process and concluded they still need a VPN, to be told they shouldn't be using a VPN.

sharmin123 5y ago

Explore Happy And Healthy Relationship Tips To Be Happy In Life: https://www.hackerslist.co/explore-happy-and-healthy-relationship-tips-to-be-happy-in-life/ https://www.hackerslist.co/explore-happy-and-healthy-relatio...

iJohnDoe 5y ago

FWIW, the NSA documents on recommended hardening approaches are usually pretty good. Their Cisco PDF many years ago was really good. Anyone have a non-PDF version of this? :-p

beermonster 5y ago
Their RHEL hardening guide was pretty solid advice and well written.

Helmut10001 5y ago

Isn't there a lot that can be done beyond VPN, to protect VPN? - Pre-filtering per Geo IP - 2FA - VLAN separation, different users and different subnets, once connected I am using both IPSEC and OpenVPN - they have different application/purpose and I need both.

rsync 5y ago
Any time I bother to use a VPN I also use a network slug[1]. I don't want to worry about implementation errors or weird bugs or DNS leaks or anything like that. A slug, which is a "transparent layer 2 firewall running on a device with only two interfaces" generally breaks your entire network if your VPN is not working exactly as you hope it will. [1] https://john.kozubik.com/pub/NetworkSlug/tip.html https://john.kozubik.com/pub/NetworkSlug/tip.html

system2 5y ago

I would love to hear SonicWall explaining why their SSL is superior to IPSec. They've advertised and forced many clients (including ours) to choose SSL VPN with expensive licensing. Now I read this as a bad choice. Very annoyed.

bink 5y ago
Vendors have to balance usability and security. That's always been the trade-off between IPSec and TLS. I don't envy people who have to provide support for IPSec solutions.
beermonster 5y ago
SSL/TLS based ones will just be more interoperable and have fewer connectivity issues through intermediary network devices and access points. But TLS has traditionally been a nightmare, crypto-wise, to say secure. POODLE, CRIME, BEAST et al. At least WireGuard is either secure or off.

andrewSC 5y ago

Anyone have a good link for reference [1] in the PDF? I tried navigating to it but get a 404. Potentially related URLs [2][3] I found also 404? Hm. [1] https://www.nsa.gov/cybersecurity-guidance https://www.nsa.gov/cybersecurity-guidance [2] https://www.nsa.gov/What-We-Do/Cybersecurity/Advisories-Technical-Guidance/ https://www.nsa.gov/What-We-Do/Cybersecurity/Advisories-Tech... [3] https://www.nsa.gov/what-we-do/cybersecurity/ https://www.nsa.gov/what-we-do/cybersecurity/

EastOfTruth 5y ago
I think that the problem is temporary because I tried many other NSA URLs and they all 404s Also,the reference [1] is also the same URL as references 6, 9, 10, 13, 16, 18, 19, 20, 21

moochi 5y ago

what's wrong with a TLS VPN ? (apart from performace bottlenecks) TLS v1.2 and v1.3 are still secure. Or, NSA has already found something to break it ?

PLG88 5y ago

For me, the answer to 'hardening' is to use an open source zero trust solution which is always outbound only thereby cannot be subject to network level attacks (OSI 3-5), e.g., DDoS, brute force, CVE exploit etc