Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Selecting and Hardening Remote Access VPN Solutions [pdf]

media.defense.gov

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Selecting and Hardening Remote Access VPN Solutions [pdf]

#21

Post by knownjorbist »

wahern wrote: post #19
WatchDog wrote: post #2

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.

> 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…

Can you explain the "corporate, road warrior" references?

Secondly, what are your thoughts on Tailscale?

Re: Selecting and Hardening Remote Access VPN Solutions [pdf]

#22

Post by zxcvbn4038 »

WatchDog wrote: post #2

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.

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.

Re: Selecting and Hardening Remote Access VPN Solutions [pdf]

#23

Post by kerng »

josnyder wrote: post #4

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.

Ah, "beyond corp" the Google marketing term that many industry misunderstood and then exposed their entire internal infra...

Re: Selecting and Hardening Remote Access VPN Solutions [pdf]

#24

Post by theginger »

josnyder wrote: post #4

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.

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.

Re: Selecting and Hardening Remote Access VPN Solutions [pdf]

#25

Post by beermonster »

zxcvbn4038 wrote: post #22
WatchDog wrote: post #2

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.

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 sam…

> I was thrilled to see that ProtonVPN recently added openvpn over tcp as an option

They also support WireGuard though currently in beta.

Re: Selecting and Hardening Remote Access VPN Solutions [pdf]

#26

Post by beermonster »

er4hn wrote: post #5
implying wrote: post #3

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

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.

Would you trust the NSA’s thoughts on recommended algs given their chequered history?

Re: Selecting and Hardening Remote Access VPN Solutions [pdf]

#27

Post by beermonster »

implying wrote: post #3

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

> Strange how this implies that the end-all-be-all of VPNs is IPsec

And no mention of poor configurations such as IKEv1, pre-shared keys and aggressive mode?

The NSA did like breaking IPSec VPN configurations according to documents exposed by Snowden

Re: Selecting and Hardening Remote Access VPN Solutions [pdf]

#28

Post by beermonster »

system2 wrote: post #13

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.

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.

Post reply on HN