WireGuard 1.0 for Linux 5.6
181–190 of 214 posts
Re: WireGuard 1.0 for Linux 5.6
#182Very exciting news, indeed! Finally WireGuard is in the Linux kernel 5.6 onwoards (will arrive soon in the next few days for those who are on rolling releases). I've been using WireGuard to replace IPsec (strongSwan - the whole stack is way too complex, plus client configuration issues, outweighs the benefits) and OpenVPN (latency, bandwidth / performance is the biggest complaint) for remote access and mainly encrypt…
Your first point: There's no part of WireGuard that inherently demands the use of a static IP address. You can run whatever dynamic IP protocol you want inside of it or outside of it. The entire interface configuration is dynamically configurable at runtime. We're working on one called wg-dynamic, but others have done others. Your second point: Obfuscation protocols can encapsulate WireGuard just fine.
I have been running 2 simple standalone WireGuard VPN servers for remote access and encrypting traffic (2 EC2 instances inside a VPC, scripted configuration). Admittedly I didn't dig deep enough to think about or leverage VPC's DHCP and/or DHCP servers running on other EC2 instances in the same VPC over the last 2+ years (facepalm), which also means, WireGuard has been set & forget (reliably working ;-)
Will dive into obfuscation and compare with (known to work) solution V2Ray (WebSocket + TLS + Web) / Trojan for next battle with the GFW.
BTW: Gravitational has built a WireGuard based overlay network CNI for k8s called wormhole [1] which can be used to replace flannel when encryption is required for in-cluster traffic across the overlay.
Re: WireGuard 1.0 for Linux 5.6
#183This is not an appropriate announcement post for a product, as it does not explain what the fuck a wireguard is, and given that it has been in beta up until now, the number of people who read hacker news and won't know what the fuck a wireguard is, is high enough to warrant only a proper announcement post for the product.
Re: WireGuard 1.0 for Linux 5.6
#184For anyone wanting to try it, WireGuard with Algo VPN [1] to set it up on a server is a great combination. I found it quite easy to setup and use. Algo has built-in support for various cloud providers, where, when you run it from, day, your desktop, it can setup the VPN server for you based on answers to some questions (with sensible defaults) and some information on connecting to the provider (like an API key, for e…
Algo vpn is the best way to set up wireguard.
Re: WireGuard 1.0 for Linux 5.6
#185So why is it so much better?
Is it because it's a new and simpler implementation than what we have for IPSec?
Is it because the protocol, being newer, is simpler and cleaner than IPSec?
Is it because, being newer, it can use a modern ciphersuite?
Are there fundamental advances in the design?
One of the nice things about IPSec is that it's a standard. There's a reasonable chance that two endpoints written by separate parties will be able to communicate. Introducing a whole new protocol whose main implementation is its definition seems like a step backwards.
Re: WireGuard 1.0 for Linux 5.6
#186Very exciting news, indeed! Finally WireGuard is in the Linux kernel 5.6 onwoards (will arrive soon in the next few days for those who are on rolling releases). I've been using WireGuard to replace IPsec (strongSwan - the whole stack is way too complex, plus client configuration issues, outweighs the benefits) and OpenVPN (latency, bandwidth / performance is the biggest complaint) for remote access and mainly encrypt…
Your first point: There's no part of WireGuard that inherently demands the use of a static IP address. You can run whatever dynamic IP protocol you want inside of it or outside of it. The entire interface configuration is dynamically configurable at runtime. We're working on one called wg-dynamic, but others have done others. Your second point: Obfuscation protocols can encapsulate WireGuard just fine.
In the meantime, can anyone recommend a obfuscation proxy for Linux?
Re: WireGuard 1.0 for Linux 5.6
#187I'm a bit baffled by WireGuard. From 10 000 feet, the protocol is similar to IPSec - encrypt packets, and send them over the internet using a connectionless protocol. So why is it so much better? Is it because it's a new and simpler implementation than what we have for IPSec? Is it because the protocol, being newer, is simpler and cleaner than IPSec? Is it because, being newer, it can use a modern ciphersuite? Are th…
Having deployed IPSec between vendors, this is only "sorta" true. IPSec can be an immense fiddle to actually get running between two vendors for the first time.
One of the other issues when using IPSec between vendors (or even just be default) is that the actual overlapping ciphers/hashes that are supported or even just work are normally the lowest possible.
> Are there fundamental advances in the design?
First party roaming makes dealing with mobile and CGNAT much nicer, anyone behind a IPSec VPN on a home CGNAT network will have a bad time (often it won't connect at all)
Finally. It's code base is actually pretty small, allowing sane audits to take place. In my eyes thats a huge win. People who have seen the sheer size of strongswan or openvpn might appreciate wireguard in comparison.
Re: WireGuard 1.0 for Linux 5.6
#188I'm a bit baffled by WireGuard. From 10 000 feet, the protocol is similar to IPSec - encrypt packets, and send them over the internet using a connectionless protocol. So why is it so much better? Is it because it's a new and simpler implementation than what we have for IPSec? Is it because the protocol, being newer, is simpler and cleaner than IPSec? Is it because, being newer, it can use a modern ciphersuite? Are th…
I would love to agree with this, but in practice, IPsec across vendors (or even across product lines from the same vendor) is often a nightmare. There are so many moving parts to IPSec, whereas Wireguard is drastically simpler.
Re: WireGuard 1.0 for Linux 5.6
#189I'm a bit baffled by WireGuard. From 10 000 feet, the protocol is similar to IPSec - encrypt packets, and send them over the internet using a connectionless protocol. So why is it so much better? Is it because it's a new and simpler implementation than what we have for IPSec? Is it because the protocol, being newer, is simpler and cleaner than IPSec? Is it because, being newer, it can use a modern ciphersuite? Are th…
I've been using / working [1] [2] with strongSwan since early 2014, admittedly, the hands-on experience lifted my Linux / Networking skills to a whole new level, but at cost (countless hours burnt). It requires a broad range of skills, has a relatively steep learning curve.
> The company I've worked for (in pre-IPO stage), had 800+ strongSwan instances served as site-to-site VPN gateways inside AWS VPCs, they were single point of failure from a design PoV but that simple design (with health check and recovery mechanism of course) worked surprisingly very well over a period of 3 years (thanks to simple design and stability & quality of strongSwan). Personally I've been using strongSwan based VPN gateways to punch holes in GFW and encrypt network traffic until mid 2018, happy with it (WireGuard is totally different design when I first migrated from strongSwan, simple, visible (interface, route-based), cryptokey routing, built-in roaming, small code base (minimal attack surface), performance (in kernel). Over time scalability and usability (all sorts of web UIs or GUIs) will improve, for large scale overlay we may better off with something else (nebula). For now officially it offers native client for most of the popular platforms.
For any new typical VPN (remote access, encryption in transit, site-to-site may not be as flexible as IPsec as I haven't done that, I used nebula instead to created an overlay) use cases, I'll pick WireGuard to start with ;-)
Re: WireGuard 1.0 for Linux 5.6
#190Any ideas how to get a client-server style VPN setup with WireGuard working with IPv6 so that it keeps working even if the public IP address of your VPN server changes? The configurations I've seen assign a statically configured IP address to a client. This works fine with NATted IPv4, but with IPv6, addresses are "public", so the client must basically know the prefix of the server to be able to configure a sane addr…