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

31–40 of 41 posts

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

#31

Post by nuker »

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…

> Wireguard provides none of that.

What she said. I’d go with Strongswan. Or openbsd iked

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

#32

Post by eptcyka »

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…

WireGuard is more of a replacement of OpenVPN. And really, it's a protocol with no side-channel to negotiate config and auth. I think that eventually the side channel will be made, either as WireGuardv2 or as an extra service besides a WireGuard implementation.

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

#33

Post by beermonster »

iJohnDoe wrote: post #7

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

Their RHEL hardening guide was pretty solid advice and well written.

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

#34

Post by michaelbuckbee »

knownjorbist wrote: post #21
wahern wrote: post #19

Earlier quoted context omitted.

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

It's just a slang term for people in a company that travel frequently. Sales execs, tradeshow folks, in person kickoff project managers.

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

#35

Post by Spooky23 »

beermonster wrote: post #26
er4hn wrote: post #5

Earlier quoted context omitted.

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?

You need read between the lines and look at the full context of what they recommend.

Just saying “NSA bad” is a lazy argument.

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

#36

Post by EastOfTruth »

andrewSC wrote: post #15

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 [2] https://www.nsa.gov/What-We-Do/Cybersecurity/Advisories-Tech... [3] https://www.nsa.gov/what-we-do/cybersecurity/

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

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

#37

Post by closeparen »

knownjorbist wrote: post #21
wahern wrote: post #19

Earlier quoted context omitted.

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

A road warrior VPN is as opposed to a site to site VPN. A laptop that might be anywhere.

The site to site problem is a little easier, as it can be handled by the network hardware at each site and doesn’t need a desktop/mobile UI or personal authentication.

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

#38

Post by z3ncyberpunk »

Spooky23 wrote: post #35
beermonster wrote: post #26

Earlier quoted context omitted.

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

You need read between the lines and look at the full context of what they recommend. Just saying “NSA bad” is a lazy argument.

> 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

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

#39

Post by zxcvbn4038 »

beermonster wrote: post #25
zxcvbn4038 wrote: post #22

Earlier quoted context omitted.

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.

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

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

#40

Post by er4hn »

beermonster wrote: post #26
er4hn wrote: post #5

Earlier quoted context omitted.

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?

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.

Post reply on HN