What is Reddit's opinion of
WireGuard?
From 3.5 billion Reddit comments
100 reviews of this app found across Reddit:
- Under 4k lines of code
- Kernel-space only (no context switching to userspace and back)
- Extremely efficient - fixed length fields in the protocol eliminates the need of parsers
- Fixed efficient modern encryption. Eliminates inconsistencies in encryption and simplifies configuration.
- No multilayer protocol handshakes.
- No connection state. You send your packet to the interface, it will be either delivered or not - everything is handled automatically.
- Built-in DDOS, anti-scan and attack protection - if encryption key is incorrect the server will simply not reply reducing potential threats to pretty much nothing.
- Tiny(hundreds of bytes) size allows using it on cheap routers with just a few megabytes of ROM, on IOT, microcontrollers...
- Very light on CPU means low battery usage. If you used OpenVPN on your phone you know how power hungry this piece of history is. Wireguard consumes nothing.
- Scalable. You can have thousands of tunnels on one server. You can route all your traffic to a tunnel with almost no overhead. You can even implement your whole network layer on Wireguard tunnels.
- Very easy to configure. Configuration is literally 2 lines - remote IP and key. You deal with the rest of the configuration just like if it was a local interface. And it works exactly this way.
Secure. Like REALLY secure. Developed by a security professional. 4k lines of code can be easily read and analyzed. And impressively it's one of the very few protocols that passed formal verification. Probably the only VPN protocol. You can read the whitepaper here
And it's FOSS! (no licensing controversy like with OpenVPN)
It's really a state-of-the-art project.
Oh, wow, I didn't expect anybody to post this to a high volume site. The Android work is in some intense alpha-development state right now, but things are coming along nicely. If anybody wants to contribute to the efforts, please don't hesitate to DM me.
If you don't know what WireGuard is, it's a next generation secure network tunnel: https://www.wireguard.com . The protocol has been formally verified in the symbolic model and the original whitepaper was published at NDSS this year: https://www.wireguard.com/papers/wireguard.pdf
I'm mailing out stickers to everybody who asks: https://lists.zx2c4.com/pipermail/wireguard/2017-May/001338.html
First of all. I would highly suggest you avoid a provider.
Providers can be catalogued and blocked easily. Also, they are selling your data.
Roll your own. use algo and digital ocean . It’ll be 5 bucks a month. You can choose any countries data center and it’s stupid simple with WireGuard
Designed by Trevor Perrin, who also designed the end-to-end encrypted Axolotl algorithm for Signal (that's now also used by WhatsApp, Riot, and others).
Fun fact: WhatsApp and WireGuard are already using Noise and Noise has a Rust implementation, too. Sounds like they've made Mozilla's job pretty easy!
Wireguard works differently..
If a packet isnt properly encrypted for the peer or data is not signed by a known peer, the packet is dropped.
Wireguard doesnt answer anything if these 2 requirements are not met.
See the protocol: https://www.wireguard.com/protocol/#dos-mitigation
> the server does not even respond at all to an unauthorized client; it is silent and invisible
>Instinctively, that feels very wrong and sounds like just anyone can brute force/monkey their own config file if they knew enough information.
Sure, good luck brute-forcing the 32 byte private key matching a public key for one of the configured peers on the server.
I'll call you back in a few thousand years to check how you're doing.
Read the official white paper if you actually want to understand how it works, instead of letting strangers on the internet explain it to you.
It is a client for the new-ish Linux VPN server called WireGuard. Everything is open source. It will likely be included into the Linux kernel soon.
WireGuard has been developed over the last few years as a simple, modern, fast, and secure alternative to the overly complex (and easy to implement) IPSec and OpenVPN, which information security people seem to have a low opinion of, perhaps because OpenVPN uses OpenSSL and both of those projects have had some embarrassing security vulnerabilities.
WireGuard uses modern (for 2018) cryptographic primitives that make it very fast and more future proof than IPSec and OpenVPN. Its code base is very small—just a few thousand lines—compared to the "gigantic" code bases of IPSec and OpenVPN. There is more information on the WireGuard homepage.
Looks cool! One thing to consider would be basing the protocol on something designed for network tunneling like Wireguard and contributing a go userspace implementation of it. You'll likely see much faster speeds and hopefully inter-operate with many other implementations of wireguard moving forward. https://www.wireguard.com/ There is even a standard UI spec for implementing userspace wireguard: https://www.wireguard.com/xplatform/
Possibly one of the reasons your seeing slow linespeeds is that TLS really isn't designed to be a network tunnel as it uses TCP. This means for many connections you'll be using TCP encapsulated in TCP which will create performance issues. Sorry if you already know all this!
WireGuard is not obfuscated as HTTPS. T-Mobile doesn't see it as HTTPS, they see it as WireGuard traffic. It seems misleading to claim that it looks like HTTPS.
The WireGuard project acknowledges this shortcoming of WireGuard being detectable by DPI. The purpose of WireGuard was never to obfuscate traffic, but to encrypt it. https://www.wireguard.com/known-limitations/
If you do want a VPN that is indistinguishable from HTTPS (and is obfuscated), try SoftEther VPN. It is frames of Ethernet over TLS. This is something T-Mobile cannot detect with DPI.
Like the webpage says, Wireguard is still pre-release software, and hasn't undergone proper security auditing. It may have exploitable security vulnerabilities, and the protocol may be subject to change.
I find it useful as a VPN tunneling method, but for the moment, I never use it for unencrypted traffic that I wouldn't be happy sending over the open Internet.
The very first paragraph from their website:
>WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPSec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it plans to be cross-platform and widely deployable. It is currently under heavy development, but already it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.
There is some room for a CPU Exhaustion attack. My guess would be that you’d have to hit a well-provisioned server with several Gb of traffic consistently to trigger that. There’s some mitigation around that type of attack built in; when a server is under load it will defer handshake processing and use a cookie instead which is apparently less CPU-intensive. I can’t say I fully understand it but it’s pretty well documented under the DOS Mitigation section of the protocol documentation.
This is a poor test methodology that doesn't demonstrate much beyond a lack of knowledge and that Pis are poor performing VPN servers.
Your baseline needs to route traffic through the Pi without VPN(if a Pi is what you're going to use). A test with no Pi in the channel and then a Pi AND a VPN is not a good comparison.
You say that the 50MB/s is up and down, and therefore equivalent to 100MB/s or more. This is inaccurate. Gigabit networks are full duplex. That means that if the VPN was capable of processing 1 Gbps, you would see those results as a gigabit ethernet connection can receive and transmit 1 gigabit at the same time. Using the incorrect up AND down concept that you state(like Cisco salesmen) a normal gigabit connection would technically run 2Gbps. 1Gbps in and 1Gbps out at the same instant. The slow down is processing and protocol overhead.
The proper way to test and compare VPN technologies is to use direct connections between two PCs, for example your Mac and the Pi. Though again, the Pi is a poor performer and not a good test subject for raw VPN performance testing. Then you should use a network performance testing tool such as iPerf, not a disk speed tool.
I would expect Wireguard to offer much better than ~400Mbps on a gigabit network, but not from a Pi.
> Theoretically WireGuard should offer: > Faster speeds
Than OpenVPN? Sure.
Than AES-GCM IPsec? It's not clear in practice or theory.
ChaCha20 is faster than unaccelerated AES, but given that most modern ARM and Intel/AMD cores implement instructions to accelerate AES, AES will be faster head-to-head if these instructions are used. Wireguard and IPsec using AES-GCM also have nearly identical framing overheads.
I've openly wondered how Wireguard obtains the 1011Mbps quoted on the site you point to for performance comparisons. After all, it's running over "Intel 82579LM and Intel I218LM gigabit ethernet cards", so 1011Mbps is impossible without some type of compression scheme. I suspect a measurement error, btw.
BTW, that site just quotes the Wireguard site for its numbers. I've asked Jason about it and gotten back a non-committal answer.
Might want to read this, too: https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-pudelko-vpn-performance.pdf
This is about wireguard, a vpn that is lightweight, secure and easy to set up.
The news is the fact that it is about to be included in the main Linux kernel(until now the setup involved compiling a kernel module in Linux).
Use your school email address to sign up for a public cloud provider.*
Get free cloud credits from said provider for being a student.
Spin up a small virtual private server running algo[1] to make a VPN. It's an auto provision install, very easy. Micro instances on GCP and AWS are free forever and all you need.
Leave your desktop plugged in. Algo handles dhcp renegotiation and dhcp punch through to your server in the cloud.
Configure algo on your machines
Route traffic on a subnet you won't use on a /24 to other hosts on your vpn network. (ie: 192.168.2.0)
(Optional) setup your vps to forward egress traffic so you have a free vpn service
(Optional) charge your friends for said vpn
RPI sysadmin won't do anything about it and all of your traffic will be encrypted.
This is called a road warrior setup. It'll work anywhere you go with an internet connection
[1] https://www.wireguard.com [1] https://github.com/trailofbits/algo * You can also get hosting from rpi with network access but they're keen on not doing their job well * You could also politely ask that they make a dhcp reservation for you but again, they suck
As has been stated its still not even had a major version release yet and is possibly insecure and subject to change. To write something now to support it could potentially be time wasted which could be spent on other things.
I run a private VPN server out of my home in California for when I travel. I'm currently in China and can confirm that since Thursday/Friday, I've been having intermittent issues across all devices. TGF is most likely doing deep packet inspection and dropping anything attempting to do VPN handshakes. It's unclear to me if they actually inspect everything or simply sample given that VPN comes back up at times. Anyways I don't think the fix is as simple as changing your DNS hostname to a static IP since that's what I already do and they flagged it. For me, current fix involves enabling obfsproxy on both server and client side (desktop only).
ps: Anyone looked into Wireguard? Pre 1.0 release but might be a decent option based on symptoms https://www.wireguard.com/
Wireguard is so simple and lightweight basically any device would work.
You probably wont get the full 100mbit with a rpi3 but i guess it would be near that if you internet is fast enough.
To install it i can recommend this Arch wiki page and the official website.
Note: since raspbian has a kernel without wireguard built in and because there is no dkms package availabe you need to built wireguard yourself.
But that is also pretty easy, you basically copy the repo, make it and make install it.
See here.
Just replace linux-headers-$(uname -r) with raspberrypi-kernel-headers while installing the dependencies.
Edit: and ofc you need to open a firewall port, and some sort of dynamic DNS may also help. But that basically applies to all VPN solutions.
It is still fairly new, but is has undergone some third-party validation already, at least of the protocol spec and the crypto components the reference implementation uses. The third-party clients haven't been audited though. IE the windows TunSafe for one.
IIRC there was also some drama with the original authors of WireGuard and people implementing compatible clients. Basically they didn't think it was a good idea to have non-mainline clients and suggested no one use them, meanwhile they still don't have a first-party non-linux driver or client. So "don't use that, and you can't use ours" uh huh.. it's unfortunate.
I am currently taking over the Haskell implementation of Wireguard, a user-space VPN.
I have been mostly focusing on the RPC part so far. Mostly by updating the code according to the latest spec and writing units/integrations tests. I should be done before next Tuesday.
Any kind of help/review would be much appreciated when I'm done :)
Read the whitepaper and documentation made by the Wireguard creator it explains everything you need to know about Wireguard in great details.
Maybe if you could explains your use case and how you intended to use Wireguard folks on here can guide you in the right direction.
Consider donating to the project! It's the best way to show your appreciation and make sure the project can continue.
edit: and if you're using it for your business it might be tax deductible, depending on your jurisdiction ;)
I've been going pretty full throttle in implementing wireguard in my environment (on a non-customer facing level), and was looking for a VPN provider (for personal use) that would support the protocol.
places like PIA had public statements like "No f***ing way we will implement it until its out of beta and survives an audit", while NordVPN was like "hell yeah we support it!"
I saw PIA in a negative light because of that (though TBF there's a 99% chance that wireguard is implemented securely), but now I respect that out of a security focused company.
TunSafe is a 3rd part application not made by the wiregaurd dev's. You may want to give the new pre-alpha made by the wiregaurd dev's. They have spent a long time working on a new driver for windows because the tap drivers for windows apparently sucked.
​
https://www.wireguard.com/install/?downloadwindowsprealpha=1
Traditional VPN tunnels are not tolerant to connection switching, they will always drop out and may not reconnect. Wireguard does not have this issue and PIA have said that they are keeping a close eye on Wireguard and are considering it. Until they switch to Wireguard though, remember that it's best to disable your VPN and reenable it when you switch connections.
>no windows client
damn tricksters leaving the important information to the end... blueballing little shits
as I keep reading it seems theres also no android or ios app, and theres no bds port so no pfsense/opnsense implementation.
I guess its left to
RemindMe! One Year
You should check out WireGuard. It's a new in-kernel VPN that is picking up traction in the information security community. The protocol design was recently formally verified, which speaks to its technical merit. Also, it is apparently very fast and hard to set up wrong (can't say the same about OpenVPN or IPSEC).
So in other words it has not been audited by experts as OpenVPN and WireGuard have been. Crypto is hard, independent review is critical.
For example: https://www.wireguard.com/papers/wireguard-formal-verification.pdf
And I was completely unable to find anything about who the project principals are IRL. That does not generate a good feeling.
Try WireGuard. https://www.wireguard.com/quickstart/
I use this to 'secure' my network services. I can access them from anywhere by using their local network IP's, because I configured my Wireguard peers (phones) to connect to those IP's via the tunnel. It's pretty neat! And secure because you only open a WireGuard port to the internet where only encrypted traffic is going through.
Wireguard uses ChaCha20, which doesn't have any hardware accelleration support in any current CPUs, so all encryption/decryption will be done in software on the CPU. This means you'll need a decent CPU to keep up. I don't have any data about minimum CPU, but you'll need at least a 3rd gen i7 it looks like. Keep in mind that 1Gbps is only one direction, so for full duplex 1Gbps you'd need even more horsepower.
The package you're referring to called wireguard-tools and is optional on OpenBSD. The kernel implementation wg(4) does not require them to be installed. The official documentation is available on their website, but the package contains the man pages wg-quick(1), wg(8) in addition to a pkg-readme in /usr/local/share/doc/pkg-readmes/wireguard-tools.
My understand is that the wireguard utilities originally supported a userland implementation of the protocol written in Go, which was used on OpenBSD previously, but they also exists for configuration compatibility with other systems.
You could do this but then you're paying for no reason whatsoever.
And quite frankly if you don't trust CloudFlare then you have no business trusting Hetzner or any other cloud provider either, because depending on who your adversary is every single one of them is vulnerable.
If you do choose this method then I recommend using WireGuard /r/WireGuard as your VPN.
> WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. There are experimental snapshots tagged with "0.0.YYYYMMDD", but these should not be considered real releases and they may contain security vulnerabilities
It would be interesting to compare it to ipsec as well, but ipsec is kinda horrible to set-up.
It's mainly interesting since wireguard is more comparable to ipsec than openvpn and the wireguard people claim it's faster than ipsec (but their test is on a gigabit link)
As has been said previously its still not a finished product until then they aren't planning to release anything for it.
"Warning: WireGuard is currently under development, and therefore any installation steps here should be considered as experimental. We are rapidly working toward mainline inclusion, at which point we will consider this codebase non-experimental."
Trevor Perrin explains Noise in this talk.
Basically, it's a toolkit for building secure communication protocols correctly, which has historically been difficult. (Note the many vulnerabilities found in network crypto code over the years.)
For an example of how Noise might be applied, have a look at WireGuard VPN.
Hi all, author here!
I'm not quite finished with this package yet (see issues), but now that I've got both the kernel and userspace APIs working, I figured it was time to share it to a more broad audience.
For those who aren't familiar, WireGuard (https://www.wireguard.com/) is a next-generation VPN that's in the process of being upstreamed into the Linux kernel. On top of that, there's a Go userspace implementation which works on other platforms as well.
This has been a fun project so far, and I'd appreciate your feedback. Thanks!
Recommendation for you: 1) set up a VPN using algo next time, 2) if you can, switch to Wireguard.
Algo is a set of Ansible scripts that automates the process of spinning up OpenVPN and Wireguard VPN servers. It's very useful for quickly setting up VPNs in a safe way that reduces most of the footgun configuration potential.
Wireguard is a new alternative to IPSec and OpenVPN that is significantly faster than both with stronger, more modern cryptography and a much smaller codebase. It achieves that by being pretty opinionated and removing cryptographic agility. It currently only supports Linux and (just recently) macOS.
No affiliation with either project, but I know the developers and use the software pretty extensively.
Highly recommended. Great post. Check out the WG Edgerouter releases for updates and a quick 'n dirty tutorial, along with wireguard.com for details.
Checkout these links https://www.wireguard.com/repositories/ https://www.wireguard.com/compilation/ https://www.reddit.com/r/linux/comments/hzyu8j/im_jason_a_donenfeld_security_researcher_kernel/
Wireguard is written in c (not c++, just c). Wireguard also has a go implementation. (A second clone which uses go language and not c)
I don't think wireguard devs use visual studio or a gui ide, or even windows (as a primary). Most of the core code is written by ""extremely"" high skilled programmers. If you are already not familiar with linux its not going to be any help. Maybe read the docs see if there is anything to fix or add. According to the reddit ama, jason uses vim and his ide of choice.
> In which case you need the kernel headers for the kernel.
That is the key part right there which you need to do. Then build Wireguard for whatever kernel you have.
Start with something like this:
apt search linux-headers-$(uname -r)
Here is a link that will help: https://howtoinstall.co/en/linux-headers-2.6-xen-amd64
Once you get your kernel headers installed, build Wireguard. See here: https://www.wireguard.com/compilation/
Spend a few bucks, buy a raspberry pi and install Pi-Hole. Combined with a traditional AdBlock, they're almost unstoppable on websites, with Pi-Hole offering decent blocking on everything that isn't a web browser.
Unfortunately, it only works on the local network out of the box. Of course, if you're willing to put in the time and effort, you can use something like WireGuard to extend it to anywhere in the world, but it's a whole different league of knowledge and requirements
wireguard is a connectionless protocol, so there isn't a connection at the protocol level. So, even you setup with a invalid wireguard server, it will appear to be connect, until your application data doesn't load ...
Look at WG, really - it faced a lot of scrutiny when being accepted into the kernel. It's much more performant than IPSec with acceleration. IPSec is good but very heavy and with a lot of bad decisions made decades ago. WG is fast because it's very bare-bone and uses modern crypto. While it sounds very counter-intuitive that WG without hw-accel beats IPSec with it is actually true. The new crypto algorithms are ridiculously fast on modern general-purpose CPUs because they were designed for that. IPSec isn't actually accelerated - only its crypto is, because normally it's orders of magnitude slower on general-purpose silicon (and thus needs a dedicated block).
Look at https://www.wireguard.com/performance/ - while it's not a definitive measure it shows the trend. I deploy WG mainly due to it's lack of chattiness, more stable ping, and the fact that it doesn't have problem with any networks (IPSec relies on GRE being allowed where it's often not b/c people often only allow TCP+UDP on firewalls... which is stupid but that's the reality).
You should specify what OS/platform and WireGuard version you're on. Processor scheduling is very specific to the operating system.
I presume you've read: https://www.wireguard.com/performance/ (top Google hit for "WireGuard CPU scheduling."
On one of My Linux systems I see
540416 ? I< 0:00 _ [wg-crypt-wg0] 962101 ? I 0:00 _ [kworker/2:2-wg-crypt-wg0] 962335 ? I 0:00 _ [kworker/6:1-wg-crypt-wg0] 962337 ? I 0:00 _ [kworker/5:2-wg-crypt-wg0] 962340 ? I 0:00 _ [kworker/7:2-wg-crypt-wg0]
... which are "kernel threads" and should be eligible for scheduling on multiple CPUs. Presumably these each handle some of the encryption/description (perhaps round robin peers assigned to each). There's probably just one thread (per interface) for dispatching the packets to these peer handling threads. So that thread could be the bottleneck if the CPUs are handling the encryption at a high enough rate. But you would have to read the source code (to the kernel patches) to learn how the scheduling actually works.
For example it might be that every thread can handle all peers and the interface dispatcher just round. robins each packet among them. I have no idea what would be more efficient --- for example in drivers with zero-copy then the hardware -> CPU affinity might be better than any SMP gains would be.
i think u want a virtual private network i use wireguard to solve those problems
it has a good documenation and is well defined
You didn't specify your OS, so I'm gonna asume you are using some linux distro.
The keyword you wanna search for is 'network namespace' or 'netns'.
Wireguard's official website has some docs on it, you can adapt it to suit needs.
VPN will be most secure, but your connection to BI will only work if you are using the VPN and as you've noticed the throughput on a VPN is going to be slower. Wireguard might be a little faster if you can setup the server on your PC instead: https://www.wireguard.com/
To increase WAF I would recommend a dynamicDNS and reverse proxy setup instead of the VPN. You trade some security, but make BI more accessible. Increase security with certs from Let's Encrypt
There have already been a few formal verifications, and the Linux kernel folks have been reviewing the core code. No security issues yet, which is to be expected considering who wrote it.
From Wireguards site: https://www.wireguard.com/install/
> Warning: WireGuard is currently under development, and therefore any installation steps here should be considered as experimental. We are rapidly working toward mainline inclusion, at which point we will consider this codebase non-experimental.
We will implement it when it is safe to do so. We are testing it internally and supporting development financially.
While WireGuard sounds interesting, maybe even great, Netgate is probably going to require a lot more vetting before it's integrated. I don't think WireGuard has been audited yet. Just look at their "Work in Progress" statement. Could be real good though...
But, the wireguard.com site still says the code is not ready to be relied on. Maybe I'm reading too much into this.
WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change.
https://www.wireguard.com/#work-in-progress
>Work in Progress > >WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. There are experimental snapshots tagged with "0.0.YYYYMMDD", but these should not be considered real releases and they may contain security vulnerabilities (which would not be eligible for CVEs, since this is pre-release snapshot software). If you are packaging WireGuard, you must keep up to date with the snapshots. > > However, if you're interested in helping out, we could really use your help and we readily welcome any form of feedback and review. There's currently quite a bit of work to do on the project todo list, and the more folks testing this out, the better.
Edit: Format. Bolds are mine.
>WireGuard securely encapsulates IP packets over UDP. You add a WireGuard interface, configure it with your private key and your peers' public keys, and then you send packets across it.
This is going to be big
If you are comfortable with SSH, I would stick with that. It's much simpler than setting up a VPN, and more secure (less services exposed to the internet, especially if you keep your SSH server too).
If you have a Linux server and a rooted Android client, you could look into WireGuard. It's much simpler than any existing VPN, and has a much simpler-to-understand security model. It can also deal with mobile clients that change IPs. The one big downside: It's kinda new, so not supported everywhere yet.
The crypto on this makes me really nervous in comparison to something like WireGuard. As far as I can tell in Vita there is no: Asymmetric crypto, Diffie-Hellman, Forward secrecy, or formal metthods
And they claim they do authentication, but ESP doesn't do that for the entire packet (that's what the Authentication Header is for in IPSec). WireGuard on the other hand is based on Noise and has a protocol level proof.
If I were to give one suggestion from my quick glance would be to talk to some cryptographers.
If you'd like to work on something like this for your master's thesis, I'd be happy to help out. Probably a good place to start is the actual WireGuard paper -- https://www.wireguard.com/papers/wireguard.pdf -- which has a description of the crypto and the protocol. I think doing a verified implementation of something like the key exchange wouldn't be very difficult, but the whole system might involve a bit more work. My personal plans for this included something in the F* sphere, but I haven't yet begun down that route.
It's just a new VPN. Suppose to be much easier to setup and maintain, as well as much faster than what's currently available.
www.wireguard.com gives a pretty straightforward explanation.
Its only 4000 lines of code and I think the idea is to eventually have it ship in the linux kernel.
The front page of the WireGuard describes its purpose and benefit very well, it’s open source software, they aren’t selling anything. The crypto key routing is the good stuff.
This video also goes to describe some of the core benefits but in layman’s terms, it’s probably a bit simplified for this audience. If anyone has a more in-depth technical overview video please post it.
https://www.wireguard.com/
https://youtu.be/mxpHRdO4rDU
I certainly wouldn’t call WireGuard the gold standard from an enterprise perspective, yet.
It is however an incredibly fast, simple, lightweight and very secure VPN technology that is fast become supported by all OS and Appliance vendors.
I manage many dozens of IPSec tunnels globally and have used Wireguard for personal implementations. It is excellent for inter-organisation, inter-site and roaming user VPN use cases.
Mark my words, WireGuard will supplant IPSec, OpenVPN and most other VPN technologies in use in the next 5-10 years.
WireGuard is very much branded as secure: https://www.wireguard.com/img/wireguard.svg
Also, from the front page of their website: >It is currently under heavy development, but already it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.
You will have to set an additional setting on the vpn client in order to be able to initiate connection from the vpn server, explained here: https://www.wireguard.com/quickstart/#nat-and-firewall-traversal-persistence
Yeah that should be possible, but not with only setting up Wireguard configurations. Routing comes into place with this setup. You could try to tackle this with policy based routing (PBR).
On the VPS:
echo "200 vpn" >> /etc/iproute2/rt_tables ip route add default via <home_wireguard_server> dev wg0 table vpn ip rule add from <vps_wireguard_client_subnet_or_ip> table vpn
Command explanation:
With the 1st command we create a new routing table called "vpn".
With the 2nd command we add a default route to route every traffic in that routing table to your home wireguard server
With the 3rd command we add a matching pattern based on the source address (from) to put the traffic in the correct routing table.
There are also other ways to tackle this, but I'd do it with PBR because I'm familiar with it.
​
Edit: other ways to do it: https://www.wireguard.com/netns/#routing-all-your-traffic
I believe the easiest and most secure solution would be to use namespaces. Adding different interfaces into namespaces makes it easier to separate the different interfaces as well as make sure the users traffic doesn't exit in any other than your wireguard.
You could follow the steps here: https://www.wireguard.com/netns/
​
Here is a basic example of a setup on your Raspberry (I haven't tried this out myself like this time but I have a similar setup at home):
ip netns add physical ip netns add wg0 iw phy phy0 set netns name physical ip -n physical link add wg0 type wireguard ip -n physical wg0 link set wg0 netns wg0
ip netns exec physical dhcpcd wlan0 ip netns exec physical wpa_supplicant -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf # or wherever your wlan config file is... ip netns exec wg0 wg setconf wg0 /etc/wireguard/wg0.conf ip netns exec wg0 ip addr add 10.2.4.5/32 dev wg0 # insert your ip address here, you have to disable that line in your wg0.conf file as well ip -n wg0 link set wg0 up ip -n wg0 link add eth0 ip -n wg0 link set eth0 netns 1 ip route add default dev eth0
echo 1 > /proc/sys/net/ipv4/ip_forward iptables -I POSTROUTING -t nat -o eth0 -j MASQUERADE
Now everything coming in from eth0 is passed via wg0 which is going through your wifi connection.
There is no IKE handshake. But Wireguard has a handshake to prevent all communication to be encrypted using the same key, which is a bad idea for obvious reasons :
That is a good idea for bypassing the cgnat. I have been toying with WireGuard recently - that may be a good option for the VPN on a VM. I could also host a MQTT server on that same VM so that I can access my external devices. Thanks for the good advice. I agree about the fragility/complexity of adding another step in my connections, but at least it would get me working again.
Comrades if you're having ad trouble it could be an issue w/ your ISP or network. If it would help, I can set you up an account on my (own personal) VPN so you can see how smooth the game *should* play... you'd just have to install WireGuard app lmk
Look at Wireguard VPN. easy to set up and super secure. You take a device (desktop, laptop, raspi) and it will be the VPN endpoint for your network. You generate login keys for your friends and all they have to do is set up a VPN connection pointed at your network and bam. Everyone can share everything.
Did I mention it's free?
I'm not sure I can help, but there are three configurations:
classic VPN: connect all devices on LAN A to all devices on LAN B
commercial VPN to public internet: let your client machine connect to a VPN server which then sends the traffic out to public internet
inbound to your home LAN: while you're at work or something, let your client device connect to your home LAN so you can access your home file-server or something
Which configuration do you want to talk about ?
In any case, I think the machines at both ends have to have key-pairs, and each has to know the public key of the other.
An "interface" is a device, such as (on Linux) you see when you run "ip addr". I think each Wireguard connection defined creates a new device called "wg0" or "wg1" etc.
See some info at https://www.wireguard.com/
Under linux you can simply start the desired applications in different network namespaces.
Generic instructions:
- Create a network namespace (netns) named "vdsl"
- Create a second netns named "wifi"
- Move each interface to the namespaces you've created, ie, move eth0 -> vdsl, and wlan0 -> wifi
- Move the desired PIDs to the desired netns, ie,
ip netns exec steam - Enjoy!
I'd recommend reading Wireguard's guide to network namespaces, while it's focused in containers and the Wireguard VPN protocol, it's very applicable in your use case.
Otherwise, read man ip-netns
For Windows I have no idea frankly =/
> Poly1305 uses AES.
RFC 7905 standardizes the Google ChaCha variant. Newer VPNs like WireGuard are ChaCha all the way down.
> Really, the one you should be talking about is elliptical curve cryptography.
I'm generally not as concerned with public key performance. Sure it's slow as hell, but it's only used for the protocol negotiation.
> I'd expect RISC-V to follow suit, and create dedicated instructions for AES, SHA256, and PMUL (or CLMUL).
Depends on how much they fear the VAX... Actually the B set includes CLMUL and CRCs too. Probably not packed 128-bit though.
VPN Gateway will do what you want it to do, via point-to-site connections. However, VPN gateway would be more expensive (even in the basic tier) than just setting up wireguard or OpenVPN on your existing IaaS Linux VM.
Don’t use WireGuard if you value privacy; it’s not been independent audited to be free of bugs and/or issues.
WireGuard is unfinished software that people are trusting to secure communications between devices and their own endpoint running on networks that have to be considered as hostile until proven otherwise. Software like this (based upon encryption and obfuscating communications) can not and should not be trusted until it’s been independently vetted/verified to be free of bugs/issues.
Yes, it’s being integrated into the Linux kernel but that still doesn’t mean it’s actually secure.
Until the software devs remove this info from their site it’s still valid.
> WireGuard configs are pointed to a vpn.domain.name address and work perfectly fine outside of my own LAN but will not connect inside which i kinda expected.
Actually, this should be working fine. If you don't run WireGuard on the router but rather a separate device - I imagine it has something to do with your port-forwarding only happening on the WAN interface. You should debug where the routing is going with this.
> Is there any way of making this scenario work automatically outside of me grabbing their tablets every time we leave and turning on WireGuard?
You could use the Tasker integration, so that WireGuard activates when you leave your home WiFi network.
>Next question i have. I believe i understand how the authentication works with the two public keys in the config.
The config has your client private key and server public key to be able to encrypt packets for it.
> Basically they are verified by the private keys on the server?
Likewise, your server only has its private key but the clients public keys to be able to identify them.
> Interface being first? Then peer inside tunnel? Can someone break down this better for me? Im more curious then second guessing anything.
I would suggest reading the "Simple key interface" section of the home page.
https://www.wireguard.com/formal-verification/ < maybe that answers some questions However it’s only recently it’s hit release version, it’s still very experimental, I expect an audit would arrive when it’s closer to prime time and businesses start to rely on it heavily
Since he’s been downvoted every single time and isn’t posting this anymore - credit to AtariDump:
Don’t use WireGuard if you value privacy; it’s not been independent audited to be free of bugs and/or issues.
WireGuard is unfinished software that people are trusting to secure communications between devices and their own endpoint running on networks that have to be considered as hostile until proven otherwise. Software like this (based upon encryption and obfuscating communications) can not and should not be trusted until it’s been independently vetted/verified to be free of bugs/issues.
Yes, it’s being integrated into the Linux kernel but that still doesn’t mean it’s actually secure.
Downvoted away; I don’t care. Until the software devs remove this info from their site it’s still valid.
Bonus points if you choose Wireguard, over OpenVPN server. I actually just made the jump this summer and have been pretty happy with it (although my RPi 3B+ is still running both, because the office Windows client, for my laptop, is fairly new).
If you wanna compare configs, yer welcome to poke around here, where I attempted to document the process: https://github.com/harrypnyce/raspbian10-buster
With wireguard I think the suggestion is to move the unencrypted connection in a new network namespace and use the wireguard interface to bridge traffic between them.
> [...] Debian
Did you follow https://www.wireguard.com/install/#debian-module-tools ?
Can you find the latest version on the mirrors? It's a pure maze to navigate, so I have no idea where to look for it.
Two people have suggested Wireguard, but I haven't seen the obligatory comments about how it hasn't yet undergone the full suite of security audits yet, so use with caution! To quote their website:
>WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change.
Hey man. I really doubt it is the IKev2 protocol. it has to be something that drains the battery.
While we are at it, it is really lovely to see that Open VPN will be added. There has come a new protocol for VPNs to the market, but its far from finished. Its still in early alpha beta stage, but some services have implemented it to mobile already. I have written to Protons team to see if they know about this. Take a look here :
https://www.wireguard.com
OpenVPN works great. There's no real reason to stop using it. With the --tls-auth option enabled it's probably quite safe in practice.
But WireGuard has a much, much simpler codebase, which is likely to be more secure. It's also much faster for a variety of reasons. Our experience with performance matches the data on the WireGuard performance page: https://www.wireguard.com/performance/
>WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change.
Is this your server instance? Just create the device and set an ip address manually.
Look at this link for details:
Thanks. Devil's always in the details, though - for example, it's possible to add a pre-shared key into the mix, and I don't yet know how important that is (or isn't) to the effective security of the tunnel.
I'm also still boning up on (for example) whether it's possible to specify the key size for any of the crypto stuff; with OpenVPN or OpenSSL there are not only algorithms to consider but multiple key sizes for multiple types of key (DH key as well as CA key, client key, and server keys, for example).
I just found the inner workings document, which seems to be answering most of these questions; I just hate to throw out a blanket HERE YOU GO, THIS WORKS! without a warning, when I haven't been down that primrose path yet.
https://www.wireguard.com/build-status/
x86, x64, PowerPC, ARM, MIPS, and 64bit ARM (or whatever aarch64 is). There's an OpenBSD branch on their Git server, and the Ubiquiti version is here.
https://www.wireguard.com/install/ has install instructions for a bunch of random Linux variants.
It's not quite version 1 yet but wireguard does >100Mb on my er-x.
Wireguard is a new vpn protocol that runs in the kernel and has a very good technical design and will be part of the linux kernel when its done, for now there are precompiled package for ubiquity devices. As someone that made a full mesh network using openvpn I think wireguard is better in every way.
https://www.wireguard.com/ https://community.ubnt.com/t5/EdgeMAX/Release-WireGuard-for-EdgeRouter/td-p/1904764 https://github.com/Lochnair/vyatta-wireguard
It's designed to be built into the kernel and it only supports some crypto algos:
>Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally. shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally. WireGuard uses a variant of Trevor Perin’s Noise [23]—which during its development received quite a bit of input from the authors of this paper for the purposes of being used in WireGuard—for a 1-RTT key exchange, with Curve25519 [5] for ECDH, HKDF [15] for expansion of ECDH results, RFC7539 [17]’s construction of ChaCha20 [3] and Poly1305 [8] for authenticated encryption, and BLAKE2s [2] for hashing.
This is the purpose of Netmaker. It takes multiple machines (usually Linux but can be other things), and connects them over WireGuard (the fastest VPN protocol available, and usually baked into Linux). The end result is a "virtual subnet" that acts like a typical subnet (e.g. 10.10.0.0/16) but over a virtual network.
Just to explain what's happening here: the wg_quick command has some extra magic it does when you set AllowedIPs = 0.0.0.0/0 instead of anything else. The function is defined here. This is also explained on this page in the docs. It uses a separate routing table so that the Wireguard packets themselves aren't routed through Wireguard.
Your solution with PreUp and PostDown commands works because it's set up so that it will always prefer more specific routes. However, since you seem to always want to route 192.168.5.0/24 locally and that's not specifically related to Wireguard (it would apply to any other VPN as well) I would strongly recommend just setting up a permanent static route. That makes it obvious that you're treating it differently and prevents headaches down the line.
Wireguard is stealth AF.
I change the ListenPort to something high but other than that standard 51820.
You can't port-scan for it.
Only someone monitoring the connection pathway would know that you're using Wireguard to connect to a specific port on that server.
Then, that attacker would have to attempt some brute force on that port -- and, wireguard has many mitigations built for that.
A denial of service attack is also tough to pull off: https://www.wireguard.com/papers/wireguard.pdf -- see page 8/20, section 5.3.
Of course, in any system, side-channel attacks are always a problem. So, make sure your clients are secured.
I use a raspberry PI to host a VPN service and I use WireGuard to connect to the VPN to access my home systems while I’m away from home or not on the WiFi
I’m sure there are Windows alternatives but I wouldn’t recommend hosting this on Active Directory server unless you’re happy with losing data in the event of a breach
https://www.wireguard.com/install/
You’ll have to open a port on your firewall for this to work so make sure you have a decent firewall
> windows
Yeah, windows networking is itself a hot mess, and PIA's app gets pretty funky when trying to work around its oddities.
> any banking/government websites
I'm yet to find one that doesn't work
> walmart
Works fine here through PIA
> Ideally, and what I was able to do for a long time, was just leave it running it 24/7 and that was that.
I'm doing this now, everything works fine - but then I'm using neither Windows nor the PIA app ;)
> Is anyone still able to do that without turning it off for every second website/program?
Yep!
> If so, how?
Linux shell scripts and a daemon that watches my local DNS resolver log to route specific websites' IPs outside the VPN
On mobile I use the same shell script to generate a config for the official Wireguard app for Android which also contains the per-app split routing feature and works dramatically better than the PIA app once connected.
In your case, the first thing you might like to try is changing the DNS setting to either built-in resolver or any public DNS service (eg cloudflare's 1.1.1.1) since apparently PIA's DNS is rather funky for some reason.
Wireguard has a faster setup and less overhead on packets. With TCP you save around 15% over OVPN and 5% for UDP traffic. It’s default in linux kernel (5.6) now as well.
I run high bandwidth over a NAT (can’t port fwd). Worked with both. Openvpn is great for cross platform and true tested security. Wireguard is modern, faster, and efficient, great for linux to linux.
Don't worry. Things just got a little more complicated because you basically want to deal with two default routes at the same time. One default route pointing to peer "Machine A" and one (old) default route pointing to the gateway 8.0.128.1. By default (with AllowedIPs = 0.0.0.0/0), the only thing that is going to use the old default route is Wireguard because it still needs to be able to reach its peers "the usual way". That's how wg-quick sets up policy-based routing. It puts the new default route into a new routing table which is used by default (via ip rule commands, see output of wg-quick up). And Wireguard uses a bit of magic to keep using the old default route (fwmark + ip rule). But you can tweak this or completely handle it yourself manually, if you want. The commands I added in my previous comment are about adding another exception to the rule of what IP packets get routed using the old default route.
On Linux, it's also possible to have multiple network namespaces each with their own set of network interfaces, routes and firewall rules. This gives you a pretty good isolation if you're interested in it. For example, you could have a VPN namespace that only has internet connectivity through Wireguard and launch certain processes in it while everything else works as usual (including the SSH service). Network namespaces provide good separation in that you don't need to worry about a process launched in the VPN namespace leaking anything.
WG-easy is ridiculously simple to set up on a docker host, maybe a Ubuntu server VM with docker and docker-compose installed.
Or set up a VM and use the WG quickstart guide to set up the server, then install WG Dashboard if you want a more configurable wireguard setup that can manage multiple tunnels.
Hi, here are more details of setup without veth, I have followed Ordinary Containerization part from this link wg in netns.
Inside the container
ip link show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
188: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
ip route show all
default dev wg0 scope link