Ugh! Figured it out after sufficiently banging my head against the wall. It was a firewall rule. The rule was activated a while ago, but this is the first time launching a VPN session with it in place. Which is a little weird because I guess it prevented the session handshake and it couldn't get off the ground.

 

I didn't think of it because the change happened weeks ago. Anyway, I'll leave my post below for anyone in might help the future.

 

 

 

My VPN for tunneled access for dockers suddenly stopped working. I had shut down to add a new drive and decided to change up my VPN config to a new server, which I do occasionally just because. The new config loaded, I flipped the active switch, but I have no access on that network. It says Last Handshake: Not connected and it sends a few kb and nothing received. I tried testing with a Firefox container and nothing. Also tried pinging 8.8.8.8 in the console of the container and nothing. I can successfully ping the peer endpoint. Peer tunnel address fails. 

 

Not sure if it matters, but I accidentally hit tunneled access for system when adding that new config. Could something there have made it go loopy? 

 

I'm using IPv4 only. I tried creating new configs, different servers. I tried the config file for the server that was just working for me and nothing. I tried going into /host/config and deleting everything in wireguard. I tried adding a config for Proton VPN which also worked for me in the past and that doesn't work either. I tried flipping it on/off countless time. I tried rebooting a few times. The log seems to indicate the VPN starts with no other entries. 

 

Nov 28 09:20:06 XXXXXX wireguard: Tunnel WireGuard-wg0 started
Nov 28 09:20:06 XXXXXX network: update services: 1s

 

Any suggestions or an approach to troubleshoot? 

 

Edited November 29, 20232 yr by flaminiom

Recently I had the problem that a Mullvad VPN Server went offline. Is it possible, for these cases, that it automatically chooses another server? For e.g., have multiple servers added in one configuration and selects the next one, if one server goes down?

I'm having a weird issue where all my containers, not only the one configured as wg0 will access through the VPN. My type of access is set as tunneled access for docker.

 

Can it be because I manually restarted my vpn using the CLI and restarted with a different config file? I wanted to change the endpoint server following a schedule.

 

Edit: if I restart via the web UI, then only the chosen container connects through the VPN. If I restart via the CLI, all dockers go through the VPN. I'm definitely not an expert here, but I checked the routing tables before and after in the web UI, and they are identical. Is there something I'm missing? When I restart using the CLI I use the interface settings from the config file generated using the web UI and the peer settings that I get from my provider.

 

Okay, I fixed the issue. I restarted the config through wg-quick up/down and then loaded a new config from a different location. I now backed up the default config generated by Unraid, stop/start through rc.d and then replace the config file in /etc/wireguard. This works well!

Edited January 7, 20242 yr by DrBlokmeister
Added more info on when this issue occurs.

On 11/22/2023 at 3:21 PM, xieve said:

 

I also have this problem with Surfshark.

Edit: I fixed it

I googled for a while and figured out that this was an MTU issue. My rough understanding (correct me if I'm wrong) is that the VPN provider limits the package size to below 1420 bytes, which seems to be a standard value for Wireguard. This is not correctly detected by MTU discovery and thus if we try to send larger packets (which HTTPS does) they are simply dropped.

So first, I figured out what the actual MTU should be by using differently sized ping like this:
 

ping -I wg0 -c 4 -M do -s [SIZE] 1.1.1.1

 

SIZE being the packet size to be tested minus 28 bytes, which seems to be the ping overhead.

 

After a bit of trial and error, I figured out that Surfshark has an MTU of 1370 (meaning the max size of a ping was 1342 bytes). I set this in the VPN settings (you have to enable the "advanced view" on the upper right) and tested it, but it still wasn't working. (It might work for you at this point.)

This is where MSS (maximum segment size) clamping comes in. I don't know exactly how it works, but it forces the packet size to always be under a specified limit, which is exactly what we need. I tested it by executing this in the host console:

 

iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

 

And it worked! Now all I needed to do was persist this change. I installed the User Scripts addon and created the script attached to this post. All you have to do is extract the archive to /boot/config/plugins/user.scripts/scripts, then go to Settings → User Scripts and set the schedule to "At First Array Start Only".

clamp-mss-to-pmtu.zip 750 B · 1 download

You are my hero. This is the solution anyone using Surfshark is looking for.

Thanks for the guide, it helped me!

Hello Community

 

I have been unsuccessful in getting WireGuard to work since my upgrade from 6.11.3->6.12.6, and I am in need of guidance.

1.  I have been using ZeroTier for remote access into my server and docker UI and access to my network.  Don't really want to give that up.

2.  My goal is to have system VPN tunneling access for updates (I am behind the Chinese firewall and cannot get at Github for plugins w/o VPN.  Dockers updates are OK w/o VPN).

3.  I also want to have select docker containers (Sonar, etc) running over VPN (not Plex, as my experience is that the remote access for playback does not like a double NAT). 

 

I have read through the guides, tried a number of different things, and the configuration below satisfies my goal of using ZeroTier (with complete access to server, dockers, file system) and Plex, but cannot get Wireguard working (No handshakes)

 

 

Note:  Need to reinstitute zt0 listening at any docker stop and start, even though is shows in “listening” in many cases.

 

 

("Host access to custom networks" breaks Zerotier,  as does using anything other than a HOST network setting in the Docker)

 

 

 

 

I have enabled UPnP both on the system and on my gateway router:

 

 

This is the VPN configuration:

 

Peer endpoint "ping" is working.

 

and clicking in the eyeball in with the "advanced" settings highlighted, I get this information:

 

WireGuard Configuration

Local server configuration

[Interface]

# Device_Steady Snake

PrivateKey=xxxx=

Address=10.66.39.132

PostUp=logger -t wireguard 'Tunnel WireGuard-wg3 started';/usr/local/emhttp/webGui/scripts/update_services

PostDown=logger -t wireguard 'Tunnel WireGuard-wg3 stopped';/usr/local/emhttp/webGui/scripts/update_services

PostUp=ip -4 route flush table 203

PostUp=ip -4 route add default via 10.66.39.132 dev wg3 table 203

PostUp=ip -4 route add 192.168.11.0/24 via 192.168.11.1 dev br0 table 203

PostDown=ip -4 route flush table 203

PostDown=ip -4 route add unreachable default table 203

PostDown=ip -4 route add 192.168.11.0/24 via 192.168.11.1 dev br0 table 203

 

[Peer]

#Tokyo 202_1

PublicKey=yyyy=

Endpoint=146.70.201.2:51820

AllowedIPs=0.0.0.0/0

 

Any guidance appreciated.  

 

Thank you in advance.

 

 

 

 

 

Edited January 28, 20242 yr by ShangHangin

On 3/6/2023 at 7:17 AM, mattmill said:

Does anyone know if port forwarding to rTorrent works when using VPN to Docker? Setup a WG connection to Mullvad with a port forward configured. However in ruTorrent the port is shown as closed. I have done a port mapping in the containers config but it seems unable to pass through the port.

 

 

Has anyone managed to successfully port forward using Unriads built in vpn manager?

Is there now a way to use the Wireguard Tunnel from the VPN provider as a gateway for local devices such as FireTV?
It works perfectly for me for docker, but I can't get it to work for local services.

Hey guys, I have had wireguard working for weeks now, moved  my computer into a better case and now cant connect to it at all the only thing thats changed is the Ip of the server. Can anyone help??

6 minutes ago, DavidDuffin said:

changed is the Ip of the server

Did you regenerate keys?

7 minutes ago, trurl said:

Did you regenerate keys?

Yes.

 

and I just see this when i apply changes.

Edited February 21, 20242 yr by DavidDuffin

Hey guys, is there a way to separate each docker container running through the Wireguard tunnel from the other container?

On 11/22/2023 at 4:21 PM, xieve said:

 

I also have this problem with Surfshark.

Edit: I fixed it

I googled for a while and figured out that this was an MTU issue. My rough understanding (correct me if I'm wrong) is that the VPN provider limits the package size to below 1420 bytes, which seems to be a standard value for Wireguard. This is not correctly detected by MTU discovery and thus if we try to send larger packets (which HTTPS does) they are simply dropped.

So first, I figured out what the actual MTU should be by using differently sized ping like this:
 

ping -I wg0 -c 4 -M do -s [SIZE] 1.1.1.1

 

SIZE being the packet size to be tested minus 28 bytes, which seems to be the ping overhead.

 

After a bit of trial and error, I figured out that Surfshark has an MTU of 1370 (meaning the max size of a ping was 1342 bytes). I set this in the VPN settings (you have to enable the "advanced view" on the upper right) and tested it, but it still wasn't working. (It might work for you at this point.)

This is where MSS (maximum segment size) clamping comes in. I don't know exactly how it works, but it forces the packet size to always be under a specified limit, which is exactly what we need. I tested it by executing this in the host console:

 

iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

 

And it worked! Now all I needed to do was persist this change. I installed the User Scripts addon and created the script attached to this post. All you have to do is extract the archive to /boot/config/plugins/user.scripts/scripts, then go to Settings → User Scripts and set the schedule to "At First Array Start Only".

clamp-mss-to-pmtu.zip 750 B · 38 downloads

 

LEGEND!

On 2/10/2024 at 12:37 PM, Fidel84 said:

Is there now a way to use the Wireguard Tunnel from the VPN provider as a gateway for local devices such as FireTV?
It works perfectly for me for docker, but I can't get it to work for local services.

Curious about this as well? FireTV’s and Kodi. Privoxy is causing issue with server timeouts and login using Emby.

On 11/22/2023 at 4:21 PM, xieve said:

 

I also have this problem with Surfshark.

Edit: I fixed it

I googled for a while and figured out that this was an MTU issue. My rough understanding (correct me if I'm wrong) is that the VPN provider limits the package size to below 1420 bytes, which seems to be a standard value for Wireguard. This is not correctly detected by MTU discovery and thus if we try to send larger packets (which HTTPS does) they are simply dropped.

So first, I figured out what the actual MTU should be by using differently sized ping like this:
 

ping -I wg0 -c 4 -M do -s [SIZE] 1.1.1.1

 

SIZE being the packet size to be tested minus 28 bytes, which seems to be the ping overhead.

 

After a bit of trial and error, I figured out that Surfshark has an MTU of 1370 (meaning the max size of a ping was 1342 bytes). I set this in the VPN settings (you have to enable the "advanced view" on the upper right) and tested it, but it still wasn't working. (It might work for you at this point.)

This is where MSS (maximum segment size) clamping comes in. I don't know exactly how it works, but it forces the packet size to always be under a specified limit, which is exactly what we need. I tested it by executing this in the host console:

 

iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

 

And it worked! Now all I needed to do was persist this change. I installed the User Scripts addon and created the script attached to this post. All you have to do is extract the archive to /boot/config/plugins/user.scripts/scripts, then go to Settings → User Scripts and set the schedule to "At First Array Start Only".

clamp-mss-to-pmtu.zip 750 B · 55 downloads

THANK YOU! This resolved my issue as well when setting up a surf shark wire guard tunnel. 
For those without an account this is the user script to run at first array start

#!/bin/bash

iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu && echo "Success!"

 

Looking to switch away from container hosted VPNs like binhex-delugeVPN etc. but have an issue I can’t figure out. I have flaresolverr going through wg0 and works. When I add Prowlarr to wg0, I lose the ability for Prowlarr to connect to any other local dockers such as the download clients deluge/nzb get etc. Deluge/NZB have static ipv4 addresses too but doesn’t seem to matter. How do I allow a docker that is router through wg0 to speak to other dockers on the local network 192.168.100.0/24? For now I resorted back to Prowlarr using a VPN proxy. 
 

A note that may help someone else. When I first setup wireguard for tunneled access for docker, I could not use the GUI for any dockers through it. This drove me nuts and I spent 4 hours trying to resolve. If this happens to you, RESTART the server. No idea why on the backend but this fixed whatever the Ip table issue was. 

I'd like to set up an outgoing VPN tunnel for one of my docker containers. I followed the guide from the official docs. After I import and enable the connection, the handshake happens, the tunnel works (can confirm via curl ifconfig.me using the container's console); however I can't access the given container's web ui from LAN. What could be the issue?

 

I've tried restarting the server without any luck. Using unraid 7.0.0

Edited January 12, 20251 yr by pugdudu
Added os version

Update, I was able to get it working. My setup:

• Docker network created by hand, called 'media_network': media server related stuff used by other containers as well
• The wg0 docker network created by unraid when I import the tunnel using the guide from the link above.
• I selected wg0 as the Network Type in the template for the container,
• and added --net media_network to the extra parameters section in the template

 

This way the container will have two network interfaces and I can reach it from LAN, as well as it can use the VPN.

 

However, no matter the order of the network settings, in my case this given container always had the 'media_network' as the default route, meaning all internet traffic went through there by default.

 

To solve it I needed two commands:

# Delete default route through media_network
ip route del default via 172.18.0.1 dev eth0

# Set default route to wg0
ip route add default via 172.31.200.1 dev eth1

 

To be able to run these, you need to add to the template

--cap-add=NET_ADMIN

which should be ok security-wise.

 

To have it persist after container restarts, I created an init script for the given container, which was pretty easy, the container being a linuxserver image: https://www.linuxserver.io/blog/2019-09-14-customizing-our-containers

 

After all this, the result is that all internet traffic goes through VPN (wg0), while the container is also reachable from LAN and is able to communicate with other containers within the my docker network (media_network). The performance is suprisingly good. By using ProtonVPN and Wireguard, the bottleneck is actually my array, not the VPN. 

Edited January 14, 20251 yr by pugdudu

On 3/6/2023 at 8:17 AM, mattmill said:

Does anyone know if port forwarding to rTorrent works when using VPN to Docker? Setup a WG connection to Mullvad with a port forward configured. However in ruTorrent the port is shown as closed. I have done a port mapping in the containers config but it seems unable to pass through the port.

 

 

 

On 2/9/2024 at 8:36 AM, mattmill said:

Has anyone managed to successfully port forward using Unriads built in vpn manager?

 

Same question for me. Trying to get qBittorrent with OVPN and port forwarding to work, but the connection keeps beeing firewalled no matter what I do. Any input about this problem would be really nice

On 1/14/2025 at 5:51 AM, pugdudu said:

Update, I was able to get it working. My setup:

• Docker network created by hand, called 'media_network': media server related stuff used by other containers as well
• The wg0 docker network created by unraid when I import the tunnel using the guide from the link above.
• I selected wg0 as the Network Type in the template for the container,
• and added --net media_network to the extra parameters section in the template

 

This way the container will have two network interfaces and I can reach it from LAN, as well as it can use the VPN.

 

However, no matter the order of the network settings, in my case this given container always had the 'media_network' as the default route, meaning all internet traffic went through there by default.

 

To solve it I needed two commands:

# Delete default route through media_network
ip route del default via 172.18.0.1 dev eth0

# Set default route to wg0
ip route add default via 172.31.200.1 dev eth1

 

To be able to run these, you need to add to the template

--cap-add=NET_ADMIN

which should be ok security-wise.

 

To have it persist after container restarts, I created an init script for the given container, which was pretty easy, the container being a linuxserver image: https://www.linuxserver.io/blog/2019-09-14-customizing-our-containers

 

After all this, the result is that all internet traffic goes through VPN (wg0), while the container is also reachable from LAN and is able to communicate with other containers within the my docker network (media_network). The performance is suprisingly good. By using ProtonVPN and Wireguard, the bottleneck is actually my array, not the VPN. 

 

Any idea on how this might be expanded to allow incoming connections to the containers' webUI's from the WAN through forwarded ports? I have the same issue as you with LAN access, but as my server is headless I manage every aspect of my server and all dockers from devices other than the server itself, both from within the server's LAN and through ports exposed to the WAN for specific container webUI's.

 

I'm just now finding it necessary to jump on the VPN wagon and was excited to see how simple it is to encapsulate containers in a VPN, but it seems there's important caveats to that I overlooked. I may need to consider a different approach.

 

 

 

I have ProtonVPN and trying to set up a on "VPN tunnel for docker containers only". 

I have selected a P2P one enabled. 

The firefox container now uses that as a network, and now I cannot even connect to the firefox container, it just loads an "ERR_CONNECTION_TIMED_OUT". 

 

Is there any option towards ProtonVPN to do, to make it work? 

On 11/22/2023 at 4:21 PM, xieve said:

 

I also have this problem with Surfshark.

Edit: I fixed it

I googled for a while and figured out that this was an MTU issue. My rough understanding (correct me if I'm wrong) is that the VPN provider limits the package size to below 1420 bytes, which seems to be a standard value for Wireguard. This is not correctly detected by MTU discovery and thus if we try to send larger packets (which HTTPS does) they are simply dropped.

So first, I figured out what the actual MTU should be by using differently sized ping like this:
 

ping -I wg0 -c 4 -M do -s [SIZE] 1.1.1.1

 

SIZE being the packet size to be tested minus 28 bytes, which seems to be the ping overhead.

 

After a bit of trial and error, I figured out that Surfshark has an MTU of 1370 (meaning the max size of a ping was 1342 bytes). I set this in the VPN settings (you have to enable the "advanced view" on the upper right) and tested it, but it still wasn't working. (It might work for you at this point.)

This is where MSS (maximum segment size) clamping comes in. I don't know exactly how it works, but it forces the packet size to always be under a specified limit, which is exactly what we need. I tested it by executing this in the host console:

 

iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

 

And it worked! Now all I needed to do was persist this change. I installed the User Scripts addon and created the script attached to this post. All you have to do is extract the archive to /boot/config/plugins/user.scripts/scripts, then go to Settings → User Scripts and set the schedule to "At First Array Start Only".

clamp-mss-to-pmtu.zip

This has finallly solved my problems, anyone running Surfshark needs to do this! @xieve you are a saint

Hello

 

Im not sure where to post this. But here we go

I saw this video: https://www.youtube.com/watch?v=yBF9c0u2wCE

and i tried to follow the steps, then ran into some problems, it says there was a firewall problem. I use asus router, and im not sure what to fix. (i have firewall in router enabled) The other isue is that im using protonvpn, and i dont know how to portforward into the docker image.. I am not sure if there is at killswitch so are there any??

Thank you!

On 7/6/2023 at 3:21 AM, SH4LT1S said:

What do I do if my DNS is leaking?

Hopefully this helps people out - I was poking my eyes out trying to figure this out

You need extra parameters set to (if there is already one there, add this after) --dns=x.x.x.x where x.x.x.x is the DNS IP address that is found in your wireguard configuration file per the first post readme

IF you are using the Firefox container to test, by default it has built in DNS over HTTPS which overrides local DNS settings. Go into Firefox privacy & security, scroll down to DNS and turn it OFF

Restart Firefox container and test with www.dnsleaktest.com or mullvad.net/en/check

For other containers if they have nslookup, you can use that as well

On 2/15/2026 at 9:20 PM, Zervun said:

Hopefully this helps people out - I was poking my eyes out trying to figure this out

You need extra parameters set to (if there is already one there, add this after) --dns=x.x.x.x where x.x.x.x is the DNS IP address that is found in your wireguard configuration file per the first post readme

Do you put this on one line, or on two?

e.g.

Key: --dns=

Value: xxx.xxx.xxx.xxx

or

Key: --dns=xxx.xxx.xxx.xxx