{"id":1957,"date":"2021-12-21T12:35:02","date_gmt":"2021-12-21T16:35:02","guid":{"rendered":"https:\/\/lowtek.ca\/roo\/?p=1957"},"modified":"2022-01-06T13:51:21","modified_gmt":"2022-01-06T17:51:21","slug":"wireguard-self-hosted-vpn","status":"publish","type":"post","link":"https:\/\/lowtek.ca\/roo\/2021\/wireguard-self-hosted-vpn\/","title":{"rendered":"Wireguard – self hosted VPN"},"content":{"rendered":"

\"\"<\/a><\/p>\n

After my recent adventures setting up IoT<\/a> devices with local only access, I now needed to sometimes be able to talk to those devices when I’m not home. There are plenty of solutions, including setting up SSH tunnels which I’ve done in the past. Wireguard<\/a> seems like a nice solution and it was high time I had VPN<\/a> access to my home network.<\/p>\n

The linuxserver.io<\/a> folks have a nicely curated wireguard container with documentation<\/a>. There are also plenty of good tutorials<\/a> on installing wireguard. You can even go deeper and build your own<\/a>, or explore alternatives.<\/p>\n

Here is a makefile – based on my template<\/a> for docker makefiles.<\/p>\n

#\r\n# wireguard - VPN\r\n# https:\/\/hub.docker.com\/r\/linuxserver\/wireguard\/\r\n#\r\n# Needs port forward in gateway\/router for 51820\/UDP\r\n#\r\nNAME = wireguard\r\nREPO = linuxserver\/wireguard\r\n#\r\nROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))\r\n\r\n# Create the container\r\nbuild:\r\n        docker create \\\r\n                --name=$(NAME) \\\r\n                --cap-add=NET_ADMIN \\\r\n                --cap-add=SYS_MODULE \\\r\n                -e PUID=1000 \\\r\n                -e PGID=1000 \\\r\n                -e TZ=America\/Toronto \\\r\n                -e SERVERURL=yourDomain.ca \\\r\n                -e PEERS=myPhone,myLaptop \\\r\n                -e PEERDNS=9.9.9.9 \\\r\n                -p 51820:51820\/udp \\\r\n                -v $(ROOT_DIR)\/config:\/config \\\r\n                -v \/lib\/modules:\/lib\/modules \\\r\n                --sysctl=\"net.ipv4.conf.all.src_valid_mark=1\" \\\r\n                --restart=unless-stopped \\\r\n                $(REPO)\r\n\r\n# Start the container\r\nstart:\r\n        docker start $(NAME)\r\n\r\n# Update the container\r\nupdate:\r\n        docker pull $(REPO)\r\n        - docker rm $(NAME)-old\r\n        docker rename $(NAME) $(NAME)-old\r\n        make build\r\n        docker stop $(NAME)-old\r\n        make start\r\n<\/pre>\n
Once you create this – go pull the .png files for the QR codes from the config directory. This will make it trivial to setup your phone.<\/p>\n
On mobile data – this just works. The local only Tasmota<\/a> devices I can now control when away from home and it’s super easy. What doesn’t work with this setup is accessing other docker containers on the same host as the wireguard container.<\/p>\n
I explored a few options to solve this, but it boils down to the problem of containers not easily being able to see each other. This bugs me, because while I can appreciate the security of containers being isolated from each other – if I expose a port on the host to a container – then other containers should be able to see that same port – but they can’t. This means that containers actually have less visibility into the host than an external machine – that seems wrong.<\/p>\n
You can solve the network visibility problem by giving the container a unique IP address. Here is a brief recap of creating a macvlan docker network<\/a> – details can be found in my previous post<\/a> on this topic<\/p>\n
$ docker network create -d macvlan -o parent=enp3s0 \\\r\n --subnet 192.168.1.0\/24 \\\r\n --gateway 192.168.1.1 \\\r\n --ip-range 192.168.1.64\/30 \\\r\n --aux-address 'host=192.168.1.67' \\\r\n myNewNet<\/pre>\n
Now from the makefile above, all we need to do is add --network myNewNet<\/code> to the docker flags and update the container and we’re good to go.<\/p>\n
It’s interesting that the docker ps<\/code> command seems to not show as much about the container when it is run in this mode (No port information – but yes, ports are exposed).<\/p>\n
CONTAINER ID   IMAGE                                       COMMAND                  CREATED          STATUS                 PORTS                                                                                                                                                                                                                                                                            NAMES\r\n434d19122529   linuxserver\/wireguard                       \"\/init\"                  36 seconds ago   Up 35 seconds                                                                                                                                                                                                                                                                                           wireguard<\/pre>\n
One thing to keep in mind, if you first setup the container just on the docker host without macvlan you may need to adjust your port mapping to account for the new IP.<\/p>\n
If I want the docker host machine to be able to see this container on the new IP we will need to use that --aux-address<\/code> to build a network path. This is optional, but useful so it’s worth doing.<\/p>\n
The version of Ubuntu I’m using doesn’t ship with rc.local enabled. I started down the path of enabling rc.local<\/a>, but the further I got the more it seemed this was the wrong answer. This post talking about rc.local<\/a>, pointed me at cron’s ability to execute on commands on reboot. The cron @reboot<\/a> capability seems like the easy path here, the other choice being to create a systemd service which is effectively what the rc.local solution is.<\/p>\n
Let’s create a script in \/usr\/local\/bin\/macvlansetup<\/code>, making sure it’s executable.<\/p>\n
$ cat \/usr\/local\/bin\/macvlansetup \r\n#!\/bin\/bash\r\n# Enable macvlan visibility for docker host\r\n#\r\nip link add myNewNet-shim link enp3s0 type macvlan mode bridge\r\nip addr add 192.168.1.67\/32 dev myNewNet-shim\r\nip link set myNewNet-shim up\r\nip route add 192.168.1.64\/30 dev myNewNet-shim\r\n \r\n<\/pre>\n
Then we’ll edit root’s crontab to call this on reboot<\/p>\n
$ sudo crontab -e<\/pre>\n
Adding the new job<\/p>\n
# One shot on reboots\r\n@reboot     \/usr\/local\/bin\/macvlansetup\r\n<\/pre>\n
Now we’re set. The wireguard container has a unique IP address and no visibility problems to any of my other containers on the same host. The IoT devices can also be seen just fine when I am remote and enable the VPN. The one trade-off is a slightly more complicated networking setup.<\/p>\n
With the default wireguard settings, this acts like a full tunnel VPN – meaning all of the network traffic runs over the tunnel. This is useful as a security measure if I’m on an untrusted wifi network – all the traffic will flow securely from my device to my home network then back out again to the internet. In my case with my pi-hole configured as the DNS server, I get ad-blocking over the VPN.<\/p>\n","protected":false},"excerpt":{"rendered":"
After my recent adventures setting up IoT devices with local only access, I now needed to sometimes be able to talk to those devices when I’m not home. There are plenty of solutions, including setting up SSH tunnels which I’ve done in the past. Wireguard seems like a nice solution and it was high time … Continue reading “Wireguard – self hosted VPN”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,12,21],"tags":[],"class_list":["post-1957","post","type-post","status-publish","format-standard","hentry","category-computing","category-how-to","category-network"],"_links":{"self":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1957","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/comments?post=1957"}],"version-history":[{"count":6,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1957\/revisions"}],"predecessor-version":[{"id":1987,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1957\/revisions\/1987"}],"wp:attachment":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/media?parent=1957"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/categories?post=1957"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/tags?post=1957"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}