[ghayes]

Off topic: Does anyone have a good tutorial on setting up Wiregaurd on a cloud server to act as a VPN? I’m currently using Algo from Trail of Bits, which is great, but takes a lot on control out of my hands through its Ansible scripts.

[mirimir]

Others have posted great links. But one great aspect is how simple it is. The hardest part is getting a kernel module that works with your kernel. In my experience, the best way to do that is to build it. And that's the hardest part in getting WireGuard working. In Debian, that means using the latest stable release (at least) with the latest kernel.

Once you have WireGuard working, creating tunnels is utterly trivial. For a toy implementation:

    peer 0 with IPv4 address 1.2.3.4
    
    # ip link add dev wg0 type wireguard
    # ip link list
      [see wg0]
    # wg genkey | tee privatekey | wg pubkey > publickey
    # mkdir wg
    # mv privatekey publickey ./wg/
    # ip address add dev wg0 10.0.10.1 peer 10.0.10.2
    # wg set wg0 listen-port 51820 private-key ~/wg/privatekey
    # ip link set wg0 up
    # wg
      interface: wg0
        public key: 0GS...0U=
        private key: (hidden)
        listening port: 51820
    # wg set wg0 peer IlC...QI= allowed-ips 0.0.0.0/0 endpoint 6.7.8.9:51820
    
    peer 1 with IPv4 address 6.7.8.9
    
    # ip link add dev wg0 type wireguard
    # ip link list
      [see wg0]
    # wg genkey | tee privatekey | wg pubkey > publickey
    # mkdir wg
    # mv privatekey publickey ./wg/
    # ip address add dev wg0 10.0.10.2 peer 10.0.10.1
    # wg set wg0 listen-port 51820 private-key ~/wg/privatekey
    # ip link set wg0 up
    # wg
      interface: wg0
        public key: IlC...QI=
        private key: (hidden)
        listening port: 51820
    # wg set wg0 peer 0GS...0U= allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:51820

[rsync]

"Others have posted great links. But one great aspect is how simple it is."

(generate new keys to manage, create new network interfaces, assign new IPs, run wireguard ...)

I would agree that this is relatively simple but only compared to the other mainstream options (namely, OpenVPN and IPSEC) but it is much, much more complicated than sshuttle[1] which distinguishes itself by allowing you to use any ssh server as a VPN endpoint.

No server side software install is required - all you need on the endpoint is an ssh login.

[1] https://github.com/sshuttle

[zx2c4]

I think sshuttle is pretty cool. It does layer 3 tunneling over TCP in the right way. Usually when VPNs (like OpenVPN) try to tunnel IP packets over TCP, if those IP packets contain TCP data itself, then you have this problem with tunneling TCP over TCP, and the rate and congestion control algorithms of the two instances of TCP step all over each other, and performance becomes miserable. But sshuttle has done something pretty neat to fix that: it actually parses the TCP in the packets it receives, reconstructs those packets into a normal byte stream, and then sends that over TCP, reflowed, to then be converted back into the original TCP stream on the other end. It's a tiny bit involved, but they made it work well, and most of the time sshuttle "just works."

[beagle3]

Indeed. It even has (or at least had in previous versions) a configurable ping-time monitor that traded some bandwidth for interactivity - which is another part of what makes it work so well.

[beagle3]

shuttle is indeed magic, but it does require python (and permission to run it) at the other end. That’s almost always there, but there are exceptions (miniaturized docker/vm images or tiny image routers)

[half-kh-hacker]

My only issue with sshuttle is that getting IPv6 to work with it is a real pain.

[voltagex_]

That's... not trivial.

[chrisper]

Compared to ipsec it is.

[mirimir]

There are just 10 lines on each peer!

But I do admit that the kernel stuff can be painful.

However, if it goes mainline, that will be moot.

[oarsinsync]

That's about as trivial as compiling a custom kernel. Possibly less so, as compiling a kernel in Debian/Ubuntu takes less than 10 commands.

[mirimir]

Yes. I used the latest version of Debian stable available from the VPS host. In most cases, I just upgraded to buster and installed headers. On one VPS that I didn't want to upgrade, I built a custom kernel. The WireGuard build didn't take long, and was no hassle.

[berti]

Your distro's wireguard-dkms package is your friend.

[mirimir]

That didn't always make the nut :(

[zwily]

https://github.com/StreisandEffect/streisand will do WireGuard.

[bubblethink]

Official documentation and the arch wiki (https://wiki.archlinux.org/index.php/WireGuard) are good sources

[iampims]

https://www.timdoug.com/log/2018/08/04/#wireguard_macos

https://www.stavros.io/posts/how-to-configure-wireguard/

should be sufficient to help you set it up.

[zigzaggy]

Just finished spinning up streisand to run Wireguard on my home network. This is my second time around with this set up, and it works great for me.

https://github.com/StreisandEffect/streisand

[trumped]

using a cloud server as your VPN? what made you come to that decision? how is that better then your ISP?

[jlgaddis]

In my case, I work for an ISP -- althoug not my ISP -- and the "cloud server" is a small virtual guest (that I manage) in one of $work's facilities. Between $work and AT&T (my home ISP), who do you think I trust more?

Many people have very little choice when it comes to the ISP they use. By setting up a "cloud server", at least they get to decide who, i.e. which cloud provider, has access to their traffic -- and can switch between providers much easier and at any time they wish.

[trumped]

that's a good point, but if you go with any of the major "cloud" providers, I don't think that you would be in a better position.

[beagle3]

Many of the isps modify your stream - Verizon used to add a subscriber id (so anyone can track and correlate you despite your best effort). Comcast used to add their messages into incoming html.

Does any major (or minor) cloud provide do that?

[hueving]

The cloud providers havent shown themselves to be scum like some of the ISPs that happily inject Javascript into your http traffic.

[trumped]

might be true today

[cookiecaper]

Comcast connections are metered for most residential users. Additional costs are incurred after 1TB of transfer. Also, home uplinks are generally pretty slow, and the VPN will be bottlenecked by its up speed.

[trumped]

you should be aware that VPN traffic still goes toward your 1TB data cap... actually, it probably uses a tiny more data then if you were not using a VPN...

[icebraining]

I think cookiecaper read your earlier message as "why don't you run the VPN endpoint in your home" rather than "why use a VPN at all if you're going to put the endpoint at a cloud service".