Setting Up WireGuard® on Unraid


Recommended Posts

Welcome to the Setting Up WireGuard® on Unraid discussion thread. A big thank you is owed to @T0rqueWr3nch for writing this guest blog guide and agreeing to answer questions and comments related to this blog. FYI: He also runs an excellent blog over at https://engineerworkshop.com/. Definitely check it out!

 

For more info related to WireGuard and Unraid set up, be sure to also check out @ljm42's excellent quick start guide or comment here on any questions or interesting use cases.

 

 

Link to comment

Thanks for the great work on getting WireGuard working.

 

I followed the guide to get Remote Tunnelled Access working, but I see that it uses UnRaid's Internet Connection.  How can I force the tunnelled traffic through a PiHole Docker?

 

Router that UnRaid and PiHole use: 10.3.1.1

PiHole DNS Output via 'br0' (ad-free): 10.3.1.2

Local tunnel network pool: 10.253.0.1

 

If I try to set a Peer's DNS to 10.3.1.2, traffic just fails when the VPN is turned on, assuming due to being in a different subnet.

 

 

Is there a way to get WireGuard Peers connected via Remote Tunnelled Access to also go through my PiHole Docker?

  • Like 1
Link to comment
2 hours ago, axipher said:

Thanks for the great work on getting WireGuard working.

 

I followed the guide to get Remote Tunnelled Access working, but I see that it uses UnRaid's Internet Connection.  How can I force the tunnelled traffic through a PiHole Docker?

 

Router that UnRaid and PiHole use: 10.3.1.1

PiHole DNS Output via 'br0' (ad-free): 10.3.1.2

Local tunnel network pool: 10.253.0.1

 

If I try to set a Peer's DNS to 10.3.1.2, traffic just fails when the VPN is turned on, assuming due to being in a different subnet.

 

 

Is there a way to get WireGuard Peers connected via Remote Tunnelled Access to also go through my PiHole Docker?

I have this issue too. I haven't figured it out.

I believe it has something to do with Unraid and Unraid's Docker containers not having access to communicate with each other.

Link to comment
4 hours ago, axipher said:

Is there a way to get WireGuard Peers connected via Remote Tunnelled Access to also go through my PiHole Docker?

Yes, you can, see

Make sure your pi-hole container is running on its own IP address and have the peer use that IP address as DNS server.

To allow communication between host (wireguard) and container (pi-hole), it is required the container runs on a VLAN or different interface.

 

Edited by bonienl
  • Thanks 1
Link to comment

  

14 hours ago, axipher said:

Thanks for the great work on getting WireGuard working.

 

I followed the guide to get Remote Tunnelled Access working, but I see that it uses UnRaid's Internet Connection.  How can I force the tunnelled traffic through a PiHole Docker?

 

Router that UnRaid and PiHole use: 10.3.1.1

PiHole DNS Output via 'br0' (ad-free): 10.3.1.2

Local tunnel network pool: 10.253.0.1

 

If I try to set a Peer's DNS to 10.3.1.2, traffic just fails when the VPN is turned on, assuming due to being in a different subnet.

 

 

Is there a way to get WireGuard Peers connected via Remote Tunnelled Access to also go through my PiHole Docker?

Minor point of clarification- PiHole is just a glorified DNS; it just prevents the resolution to IP address of domain names associated with ads; traffic does not go through it, but your point is well-taken. 

 

Just to give some background on the "why":

 

The problem is that Docker, by design, isolates bridged networks from each other:

 

Quote

In terms of Docker, a bridge network uses a software bridge which allows containers connected to the same bridge network to communicate, while providing isolation from containers which are not connected to that bridge network. The Docker bridge driver automatically installs rules in the host machine so that containers on different bridge networks cannot communicate directly with each other.

https://docs.docker.com/network/bridge/

 

(This may be a bit of an oversimplification since I think when you use the "custom" network type in the Docker container, you're actually using an ipvlan network, but the end result is apparently the same).

 

The way around this is to either move to another interface or set up a router-on-a-stick with VLANs as Hoopster/bonienl have suggested. 

 

However, I recognize that this isn't necessarily the most practical solution. VLANs carry a lot of overhead in the sense that your network has to be set up for them. And you don't necessarily have a second NIC for the alternative interface option.

 

It would be nice if you could just switch to the host network type in the Docker container, but unfortunately PiHole has to listen on 80 which then would create a conflict with unRAID which also uses :80 for the web GUI.

 

I personally don't use PiHole due to the last time I tried it, it was a bit overzealous in its blocking and started blocking Google-owned domains, so I'm flying a little blind here. It may be possible to surgically modify iptables to fix this. I'll try to stand up an instance of PiHole in my unRAID VM and see if I can reproduce the issue and then potentially fix it. Unfortunately, I'm about to fly out for an early Christmas vacation and might not be able to get to it for a week.

 

-TorqueWrench

Edited by T0rqueWr3nch
  • Like 1
Link to comment
1 hour ago, T0rqueWr3nch said:

It would be nice if you could just switch to the host network type in the Docker container, but unfortunately PiHole has to listen on 80 which then would create a conflict with unRAID which also uses :80 for the web GUI.

It is possible to run pi-hole on a host network on port 80.

This requires however the GUI to use a different port, which can be set under Management Access -> HTTP port.

 

Link to comment
30 minutes ago, bonienl said:

It is possible to run pi-hole on a host network on port 80.

This requires however the GUI to use a different port, which can be set under Management Access -> HTTP port.

 

So maybe this is an option we should present then as opposed to creating a VLAN set up that most probably don't have networks that are ready for one or an interface that requires hardware they might not have on hand?

Link to comment
2 minutes ago, T0rqueWr3nch said:

So maybe this is an option we should present then as opposed to creating a VLAN set up that most probably don't have networks that are ready for one or an interface that requires hardware they might not have on hand?

I haven't tested this, but if it works, it certainly is a plausible afternative.

Link to comment
1 hour ago, bonienl said:

I haven't tested this, but if it works, it certainly is a plausible afternative.

Got it working!

 

Running on the host network, there is a conflict with unRAID's dnsmasq listening on port 53. I killed the dnsmasq process, so we'll need a more elegant solution. Any idea what unRAID is using it for? It looks like it was listening on an IP address that's in a subnet I don't even use.

 

Update: Looks like we probably use the dnsmasq for libvirt, so probably not the best to just outright kill it...

Edited by T0rqueWr3nch
  • Like 1
Link to comment

Instructions For Pi-Hole with WireGuard:

 

For those of you who don't have a homelab exotic enough to have VLANs and who also don't have a spare NIC lying around, I have come up with a solution to make the Docker Pi-Hole container continue to function if you are using WireGuard. Here are the following steps I used to get a functional Pi-hole DNS on my unRAID VM with WireGuard:

 

1a) Since we're going to change our Pi-hole to a host network, we'll first need to change your unRAID server's management ports so there isn't a conflict with Settings > Management Access:

 

image.thumb.png.d7643ed7da9b4e1c5964c18b02eda423.png

 

1) Take your Pi-hole container and edit it. Change the network type to "Host". This will allow us to avoid the problems inherent in trying to have two bridge networks talk to each other in Docker. (Thus removing our need to use a VLAN or set up a separate interface).

 

image.thumb.png.ff7fd4359e7bd9c8f5d10803d30a3c03.png

 

You'll also want to make sure the ServerIP is set to your unRAID server's IP address and make sure that DNSMASQ_LISTENING is set to single (we don't want PiHole to take over dnsmasq):

 

image.thumb.png.51b0e9150ac7452de22019a6c34bb2b3.png

 

2) We'll need to do some minor container surgery. Unfortunately the Docker container lacks sufficient control to handle this through parameters. For this step, I will assume you have the following volume mapping, modify the following steps as needed:

 

image.thumb.png.6ad26b8911cf8f58edc6eb33f5b66c03.png

 

3) Launch a terminal in unRAID and run the following command to cd into the above directory:

 

cd /mnt/cache/appdata/pihole/dnsmasq.d/

4) We're going to create an additional dnsmasq config in this directory:

 

nano 99-my-settings.conf

5) Inside this dnsmasq configuration, add the following:

bind-interfaces

Where the listen-address is the IP address of your unRAID server. The reason this is necessary is because without it, we end up with a race condition depending on if the Docker container or libvirt starts first. If the Docker container starts first (as what happens when you set the container to autostart), libvirt seems to be unable to create a dnsmasq which could cause problems for those of you with VMs. If libvirt starts first, you run into a situation where you get the dreaded: "dnsmasq: failed to create listening socket for port 53: Address already in use". This is because without the above configuration, the dnsmasq created by Pi-hole attempts to listen on all addresses. By the way, this should also fix that error for those of you running Pi-hole normally (I've seen this error a few times in the forum and I can't help but wonder if this was the reason we went with the ipvlan set up in the first place).

 

Now, just restart the container. I tested this and it should not cause any interference with the dnsmasq triggered by libvirt.

Edited by T0rqueWr3nch
  • Like 5
  • Thanks 2
  • Upvote 1
Link to comment
2 hours ago, T0rqueWr3nch said:

Instructions For Pi-Hole with WireGuard:

 

For those of you who don't have a homelab exotic enough to have VLANs and who also don't have a spare NIC lying around, I have come up with a solution to make the Docker Pi-Hole container continue to function if you are using WireGuard. Here are the following steps I used to get a functional Pi-hole DNS on my unRAID VM with WireGuard:

 

1a) Since we're going to change our Pi-hole to a host network, we'll first need to change your unRAID server's management ports so there isn't a conflict with Settings > Management Access:

 

image.thumb.png.d7643ed7da9b4e1c5964c18b02eda423.png

 

1) Take your Pi-hole container and edit it. Change the network type to "Host". This will allow us to avoid the problems inherent in trying to have two bridge networks talk to each other in Docker. (Thus removing our need to use a VLAN or set up a separate interface).

 

image.thumb.png.ff7fd4359e7bd9c8f5d10803d30a3c03.png

 

You'll also want to make sure the ServerIP is set to your unRAID server's IP address and make sure that DNSMASQ_LISTENING is set to single (we don't want PiHole to take over dnsmasq):

 

image.thumb.png.51b0e9150ac7452de22019a6c34bb2b3.png

 

2) We'll need to do some minor container surgery. Unfortunately the Docker container lacks sufficient control to handle this through parameters. For this step, I will assume you have the following volume mapping, modify the following steps as needed:

 

image.thumb.png.6ad26b8911cf8f58edc6eb33f5b66c03.png

 

3) Launch a terminal in unRAID and run the following command to cd into the above directory:

 


cd /mnt/cache/appdata/pihole/dnsmasq.d/

4) We're going to create an additional dnsmasq config in this directory:

 


nano 99-my-settings.conf

5) Inside this dnsmasq configuration, add the following:


bind-interfaces

Where the listen-address is the IP address of your unRAID server. The reason this is necessary is because without it, we end up with a race condition depending on if the Docker container or libvirt starts first. If the Docker container starts first (as what happens when you set the container to autostart), libvirt seems to be unable to create a dnsmasq which could cause problems for those of you with VMs. If libvirt starts first, you run into a situation where you get the dreaded: "dnsmasq: failed to create listening socket for port 53: Address already in use". This is because without the above configuration, the dnsmasq created by Pi-hole attempts to listen on all addresses. By the way, this should also fix that error for those of you running Pi-hole normally (I've seen this error a few times in the forum and I can't help but wonder if this was the reason we went with the ipvlan set up in the first place).

 

Now, just restart the container. I tested this and it should not cause any interference with the dnsmasq triggered by libvirt.

Wow- thanks for looking into this! 

Link to comment

I'm more than impressed. Never had a VPN tunnel configured that fast and easy with all our devices. Respect.

 

May I ask two questions:

 

1.) I'm not quiet sure if I want Unraid/Wireguard vs. our router to be the endpoint in our house. What do you think?

 

2.) Do you guys use the Wireguard App on your remote devices or do you use the VPN settings in your mobile OS. I ask because 100,000 Downloads for this App are not that many. Is there a reason to avoid the App?

 

Thanks again for a thrilling addition to Unraid. I'm a customer since ~11 years and never thought that this was a bad decision ...

 

Link to comment
2 hours ago, hawihoney said:

1.) I'm not quiet sure if I want Unraid/Wireguard vs. our router to be the endpoint in our house. What do you think?

It is really up to the user to decide.   The advantage of the router supporting it is that it does not require the Unraid server to be operational.   You could of course use both with different profiles on the remote client.

 

2 hours ago, hawihoney said:

2.) Do you guys use the Wireguard App on your remote devices or do you use the VPN settings in your mobile OS. I ask because 100,000 Downloads for this App are not that many. Is there a reason to avoid the App?

You might want to have a look at the Wireguard web site?   You will see there that it is officially still classified as experimental by it's developers which is probably why it currently has limited real-world use.   However I can see that changing rapidly and early feedback from those who have tried it already is very positive.   Several of the major commercial VPN suppliers have stated that they are actively working on adding support for WireGuard to their offerings which is quite a good endorsement.

 

  • Like 1
Link to comment
  • 2 weeks later...
On 12/12/2019 at 8:45 PM, YouANinja said:

I have this issue too. I haven't figured it out.

I believe it has something to do with Unraid and Unraid's Docker containers not having access to communicate with each other.

Same issue. Pi-Hole is using a custom IP on br0. I can access any other device on my network except the Pi-Hole IP.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.