Live data from Hacker News

WireGuard is now in Linus' tree

lists.zx2c4.com

271–280 of 293 posts

Re: WireGuard is now in Linus' tree

#271

Good news (rare) in Jan 2020 ;-) Using WireGuard to establish a mesh network seems good to start with but it does not scale well (even with the help of subspace web UI). Nebula (from Slack) seems to be a better option which is simple, secure and scales well so far, docs are not that well at this stage but usable. My main use case of WireGuard is to secure network traffic on Laptop/Workstations, replacing old-school c…

Forgot to mention a potential problem with WireGuard, server keeps the list of clients' virtual IPs (AllowedIPs used for routing/ACLs), not ideal for VPN service providers in terms of privacy.

It's not a problem for overlay network (e.g. Nebula) though, as it is considered a `requirement`.

Re: WireGuard is now in Linus' tree

#272

Earlier quoted context omitted.

More pedantic: Linus' is correct because Linus is a proper noun.

As far as I understand it, that's not the general rule. This is hardly a authoritative citation, but it cites a number of authority and comports with my understanding as someone whose name ends in `s`: "Nearly all authorities agree that if you want to make a possessive out of a singular noun like Kansas that ends in an s, you need to add ’s at the end. Just call it “Ross’s Rule.”" https://www.legalwritingpro.com/arti…

The Chicago Manual of Style which is pretty much the authority in the USA says you do apostrophe-s for all possessives even if it ends in an “s”. So “Ross’s” if it is a singular Ross.

But if you’re describing a family possession, it would be Rosses’ as is possessed by more than one Ross.

Re: WireGuard is now in Linus' tree

#273
post #266
post #193

Earlier quoted context omitted.

Are you using TLS over TCP to route to the DBs?

I think I was doing TLS at one point, but removed it temporarily in an effort to focus on other infrastructure stuff.

Just checked and I'm doing TLS. You can easily do this with Traefik (which I will include in my upcoming post).

Re: WireGuard is now in Linus' tree

#274

Earlier quoted context omitted.

While WG is pretty cool, you're starting to describe a simple version of ZeroTier. You can achieve exactly what you say with it, along with multiple networks, chosen/assigned ips, p2p routing, shared keys for authentication to the network, etc. You can put extra filtering or routing rules on top of each of the networks.

Do u maybe know when wireguard would be better than ZeroTier?, been using it for months for p2p(Hamachi like), and for access to the internet like a VPN service. Seems to be most versatile since it works everywhere even behind the deepest nat jungle, and with blazing fast speeds (compared to openvpn haven't tried wireguard yet)

If you want an open source ZeroTier, try Slack's Nebula.

https://github.com/slackhq/nebula

Re: WireGuard is now in Linus' tree

#275
post #257

Earlier quoted context omitted.

"No reason to run DNS." Hmmm, it was a yes or no question. Are you suggesting it work would if you did.

Yes, pretty much since most ISPs do not block UDP port 53. I have no reason to run DNS on a home internet connection. What would a sane use case be? They don’t block it because it would be stupid to use it anyway. Ports that are typically blocked include 67, 139, 161, 520, 547, etc.. ie dhcp, rip, smb, snmp... none of them are any great loss to those that want to run a vpn. Running a VPN or ssh service is another sto…

As someone else pointed out, the issue is mainly NAT not necessarily just "blocked" ports. What works with your ISP may not work with someone else's.

Re: WireGuard is now in Linus' tree

#276
post #44

Earlier quoted context omitted.

FD.io uses the VPP stack under the hood, which ultimately uses DPDK[1] for the actual IO acceleration. The reason it's faster is because it's polling your hardware. You spend a lot of cpu time to buy the lower latency. [1] http://doc.dpdk.org/guides/prog_guide/overview.html

It's possible to write a driver that doesn't use polling - for example https://arxiv.org/pdf/1901.10664.pdf which discusses using vfio though doing so is apparently much harder than polling alone due to the complexity of the vfio interface and that most users care more about maximizing PPS performance at peak vs saving CPU cycles when less busy. Presumably one other option would be to try and tune the CPU to run slow…

> It's possible to write a driver that doesn't use polling

Yup, definitely possible. It just doesn't give the PPS numbers as polling does. The project you linked to is really cool, but it is an academic project. It's not trying to compete with DPDK or anything.

IO is one of those things in computer science that forces us to make trade ofs. What is more important to you? Raw throughput? Latency? Overall resource usage? You can't optimize all three.

> it sounds like you might want to look at pinning cores to workloads, such that only one of your CPU cores is polling

Correct again. It may take more than one cpu (DPDK is commercial software running on 88+ cpu systems) but cpu pinning is definitely the recommended way to go. In the spirit of spending CPU to buy IO speed, dedicating physical cores to the task always gives you the best bang for your buck.

Re: WireGuard is now in Linus' tree

#277

Earlier quoted context omitted.

I'm not "seriously" interacted, but I have VPN server and I'm using it on all devices in my hope (laptop, PC, phone) which are behind WiFi NAT. They work just fine. I'm using strongswan and IKEv2 on server.

Your NAT behaves and likely has (working) IPSEC ALG stuff, plenty of setups don't.

More likely is that both ends are using IPSec NAT-T (https://tools.ietf.org/html/rfc3947), which has been widely supported for some time. NAT-T encapsulates IP packets inside UDP, with the IKE daemons (usually) as the UDP endpoints.

Re: WireGuard is now in Linus' tree

#278
post #219

Earlier quoted context omitted.

It does look very nice. It's a shame that it depends on third parties for authentication, and that they have gems like this in their documentation: > No app-level integration or reconfiguration is required, because security is built into the network itself. If you configure your network to require Tailscale, every one of your internal services will be subject to multi-factor authentication. Which is simply not true.…

> That does not mean my applications I access through the VPN are now magically subject to MFA. Why not? Doesn't the VPN authenticate you via VPN before you can access the apps?

Network authentication is not the same as application authentication.

If I plug a cable into your LAN, I am not subject to MFA to login to a server on your LAN.

If you have a lock on the network port that requires me to type in a PIN code and stick in a key to unlock, and expose the port, that then results in MFA to connect to your network. Your applications behind your network remain without MFA.

MFA VPN is essentially the same thing as the above, but for remote access to the LAN. Applications should still be properly secured.

I suppose it could be argued that this provides a client-side agent to authenticate the end user as well (mumble mumble 802.1x), and if so, then it's arguable whether or not you need another layer of authentication on the application, or if this qualifies as SSO to authenticate you to everything you have access to in the network (so passwordless login to servers, desktops, webapps, etc)

Re: WireGuard is now in Linus' tree

#279

Earlier quoted context omitted.

> As someone who regularly deals with IPSec in conservative network environments, Wireguard can’t gain broad adoption soon enough, in my opinion. As someone who does not do heavy NetOps, can you speak more about what's wrong with IPsec?

The over-summarized version is: IPSec is extensible and it's rather tedious to get every implementation to interoperate securely with every other implementation simultaneously (and in the correctly secure way). While using IPSec between supported devices, in an ideally configured setup, yield slight but real benefits with respect to attack resistance, a practical comparison of the difficulty involved and possible con…

The 1995 is a little unfair to the current IPsec: The complicated part of the protocol had a compatibility breaking & simplifying major revision in 2005 (IKEv2).

I think the main reason of the less than polished IPsec experience is that operating systems didn't really promote it as a out of the box working feature, but instead just offered APIs that were mainly used by corporate VPN product vendors who didn't really want interoperation except as a checkbox feature. The early interop hassles are just a symptom of lack of testing and effort - when vendors are motivated and actually everyone's implementation of a standardised protocol to interoperate they organise interoperation testing events etc and make sure their products ship with configurations that actually do interoperate in the real world.

Your linked StackOverflow answer muddies the water too much - IKE was always the official keying protocol[1]. Yes you can use lower level IPsec parts without it with manual keying if you are a masochist or have a very simple topology (like a 2-host tunnel with static IPs), but the other keying methods are fringe or academic.

[1] IKE was finished later than the lower level parts of IPsec, technically there was a period in the beginning when it didn't exist and you had only manual key setup

Re: WireGuard is now in Linus' tree

#280
post #277

Earlier quoted context omitted.

Your NAT behaves and likely has (working) IPSEC ALG stuff, plenty of setups don't.

More likely is that both ends are using IPSec NAT-T ( https://tools.ietf.org/html/rfc3947 ), which has been widely supported for some time. NAT-T encapsulates IP packets inside UDP, with the IKE daemons (usually) as the UDP endpoints.

NAT-T is unfortunately not very reliable.
Post reply on HN