[Support] dyonr - passthroughvpn


39 posts in this topic Last Reply

Recommended Posts

 

passthroughvpn-icon-128.png.017b2943a4b071d35714a4ab563d5805.png

 

This container solves the problem of containers with no 'VPN' variant. After setting up this container, route your non-VPN Dockers through this one to protect your IP. Or, when you have no other 'VPN' containers.
Or host, for example a game or webserver by using your VPN Provider's IP, if your VPN Provider supports forwarding.
Both WireGuard and OpenVPN are supported.
Check out https://github.com/DyonR/docker-passthroughvpn for setup instructions.

 

 

Base: Debian 10-slim

Docker Hub: https://hub.docker.com/r/dyonr/passthroughvpn/

GitHub: https://github.com/DyonR/docker-passthroughvpn

Link to post

Hey there.  Looking to try this out tonight but had a question about the restart_container function which is set to no by default.  Please forgive my lack of knowledge in this area but in what scenario would I not want it to restart automatically?  If this is set to no and the connection is dropped for some reason such as if the VPN server goes offline, will the service begin working again once that specific VPN server comes online again or does the killswitch mean it stays offline until it restarts?

Link to post

I thought I would give this a run. It seems like it will be exactly what I am looking for. When I start the docker, after I configure it, It keeps scrolling  :

 

2021-02-19 16:27:38.492612 [INFO] OpenVPN config file is found at /config/openvpn/AirVPN_US-Atlanta-Georgia_Libra_UDP-443.ovpn
2021-02-19 16:27:54.823516 [INFO] VPN_ENABLED defined as 'yes'
2021-02-19 16:27:54.846987 [INFO] VPN_TYPE defined as 'openvpn'
2021-02-19 16:27:54.875854 [INFO] OpenVPN config file is found at /config/openvpn/AirVPN_US-Atlanta-Georgia_Libra_UDP-443.ovpn
2021-02-19 16:28:23.535725 [INFO] VPN_ENABLED defined as 'yes'
2021-02-19 16:28:23.559352 [INFO] VPN_TYPE defined as 'openvpn'
2021-02-19 16:28:23.588611 [INFO] OpenVPN config file is found at /config/openvpn/AirVPN_US-Atlanta-Georgia_Libra_UDP-443.ovpn

 

I have tried to get into the console, and it opens and closes the console window instantly. When I try to CLI into the console window, I  get told to "Wait until the container is started"

 

I have tried different config version for my openvpn config. I have tried with or without the keys and certs built in.  Since I can't console in to check logs, I am a little perplexed as to what to poke at next.  Any suggestions.

Link to post
17 minutes ago, robsch said:

I thought I would give this a run. It seems like it will be exactly what I am looking for. When I start the docker, after I configure it, It keeps scrolling  :

 


2021-02-19 16:27:38.492612 [INFO] OpenVPN config file is found at /config/openvpn/AirVPN_US-Atlanta-Georgia_Libra_UDP-443.ovpn
2021-02-19 16:27:54.823516 [INFO] VPN_ENABLED defined as 'yes'
2021-02-19 16:27:54.846987 [INFO] VPN_TYPE defined as 'openvpn'
2021-02-19 16:27:54.875854 [INFO] OpenVPN config file is found at /config/openvpn/AirVPN_US-Atlanta-Georgia_Libra_UDP-443.ovpn
2021-02-19 16:28:23.535725 [INFO] VPN_ENABLED defined as 'yes'
2021-02-19 16:28:23.559352 [INFO] VPN_TYPE defined as 'openvpn'
2021-02-19 16:28:23.588611 [INFO] OpenVPN config file is found at /config/openvpn/AirVPN_US-Atlanta-Georgia_Libra_UDP-443.ovpn

 

I have tried to get into the console, and it opens and closes the console window instantly. When I try to CLI into the console window, I  get told to "Wait until the container is started"

 

I have tried different config version for my openvpn config. I have tried with or without the keys and certs built in.  Since I can't console in to check logs, I am a little perplexed as to what to poke at next.  Any suggestions.

I was able to get mine running with ovpn no problem.  Just a shot in the dark but did you see his note about auth-user-pass for OpenVPN?

Link to post
4 minutes ago, Aegisnir said:

I was able to get mine running with ovpn no problem.  Just a shot in the dark but did you see his note about auth-user-pass for OpenVPN?

.... SOB. Okay, Nevermind!   Stupid User Error..... I completely missed that. Works like a charm!  Thanks for the headsup!

Edited by robsch
Link to post

BTW, for anyone who wants to double check that they set this up correctly and their traffic is being routed through the VPN, you can run the following in your Unraid console.  This will hit every container you have and check for and public IP address and Country.  I'm sure there is a cleaner/shorter way to do this but this is what I got and it works. 

Note if you don't have curl installed in a container, this will return a blank value.  Just install curl and re-run.

 

for I in $(docker ps --format '{{.Names}}'); do \
  location=$(docker exec -it $I curl -ks https://www.dnsleaktest.com \
  | grep flag | sed -e 's/.*from \(.*\),.*/\1/'); \
  printf "%-15s%s\n" "$I:" "$location"; \
  location=$(docker exec -it $I curl -ks http://bot.whatismyipaddress.com); \
  printf "%-15s%s\n" "$I:" "$location"; \
done

 

Edited by Aegisnir
Link to post
On 2/20/2021 at 2:41 AM, Aegisnir said:

BTW, for anyone who wants to double check that they set this up correctly and their traffic is being routed through the VPN, you can run the following in your Unraid console.  This will hit every container you have and check for and public IP address and Country.  I'm sure there is a cleaner/shorter way to do this but this is what I got and it works. 

Note if you don't have curl installed in a container, this will return a blank value.  Just install curl and re-run.

 


for I in $(docker ps --format '{{.Names}}'); do \
  location=$(docker exec -it $I curl -ks https://www.dnsleaktest.com \
  | grep flag | sed -e 's/.*from \(.*\),.*/\1/'); \
  printf "%-15s%s\n" "$I:" "$location"; \
  location=$(docker exec -it $I curl -ks http://bot.whatismyipaddress.com); \
  printf "%-15s%s\n" "$I:" "$location"; \
done

 

Also just: "curl ifconfig.io" works fine.

 

Link to post

Keen to give it a go, sounds like something useful, but I keep getting this in the log, I assume its not meant to be

 

2021-02-22 03:53:28.227194 [ERROR] Network is possibly down.
2021-02-22 03:53:29.243622 [INFO] Restarting container.

 

Link to post

 First of all, excuse me all for being late with replies. Unraid Forums does not auto-follow threads you post, so I did not receive any email notifications unfortunately.

 

On 2/19/2021 at 9:23 PM, Aegisnir said:

Hey there.  Looking to try this out tonight but had a question about the restart_container function which is set to no by default.  Please forgive my lack of knowledge in this area but in what scenario would I not want it to restart automatically?  If this is set to no and the connection is dropped for some reason such as if the VPN server goes offline, will the service begin working again once that specific VPN server comes online again or does the killswitch mean it stays offline until it restarts?

First question; in what scenario would I not want it to restart automatically

This depends, if you pass an torrent client through this container, it probably won't matter when it restarts, since most torrent clients will just continue downloading the files and move on. (Yes, there are VPN torrent Dockers, but this is an example of a 'less important' program). Another example would be a small private webserver that you host, or a reverse proxy host. These programs won't be affected by abruptly shutting down.

Some game servers, to give an example that I've had experience and 'issues' with is Minecraft. Minecraft does not continuously save player activity to the disk, so if the container thinks it is down, and abruptly restarts, this could result in a minor rollback or item loss. I consider programs that basically continuously access to disk to save unrecoverable progress 'important'.

The problem is that pinging a host to check if the connection is actually up or down is not really reliable in my opinion at all, even though this is exactly what the container does. I've had enough times that the container thought it was down based on 1 failed ping, but was actually still up. I did test this by sending my a Telegram message instead of abruptly shutting down the container. I might look into a better solution to do, for example 10 pings and see if >30% failed, if so, restart the container.

 

Second question; If this is set to no and the connection is dropped for some reason such as if the VPN server goes offline, will the service begin working again once that specific VPN server comes online again or does the killswitch mean it stays offline until it restarts?

This is actually an interesting question which I am not 100% certain about, this is not something I ever tested really. Since I just wanted the highest uptime for my containers.

For now, I believe this is the case:

If the connection is actually drops, and once again, one ping is actually a bad indicator, the connection will never come back, unless it restarts, since it can reestablish the connection before applying the iptables killswitch. OpenVPN uses tun0 as network interface and WireGuard uses the wg0 interface. The iptables killswitch is quite strict, it allows only connections to get in and out via tun0 or wg0 (with exception of the local network). So, if OpenVPN or WireGuard goes actually down it would never be able to communicate again.

I don't know if WireGuard or OpenVPN have some auto-reconnection going on, this is something I actually would like to look in to. This is something I will look in to, but I can't promise when.

 

On 2/20/2021 at 2:41 AM, Aegisnir said:

BTW, for anyone who wants to double check that they set this up correctly and their traffic is being routed through the VPN, you can run the following in your Unraid console.  This will hit every container you have and check for and public IP address and Country.  I'm sure there is a cleaner/shorter way to do this but this is what I got and it works. 

Note if you don't have curl installed in a container, this will return a blank value.  Just install curl and re-run.

 


for I in $(docker ps --format '{{.Names}}'); do \
  location=$(docker exec -it $I curl -ks https://www.dnsleaktest.com \
  | grep flag | sed -e 's/.*from \(.*\),.*/\1/'); \
  printf "%-15s%s\n" "$I:" "$location"; \
  location=$(docker exec -it $I curl -ks http://bot.whatismyipaddress.com); \
  printf "%-15s%s\n" "$I:" "$location"; \
done

 

I should probably also include something like this in the documentation on the GitHub page.

As @numblock699 said, 'curl ifconfig.io' is probably the quickest way to do this.

 

 

On 2/21/2021 at 4:30 AM, Darrell said:

Great container. Thanks! 

 

Are there any plans to add privoxy support?

Privoxy is something I've literally never worked with since I have always just been passingthrough containers through this container.

I do not know what the other usecase for Privoxy would be. I thought it was always used to proxy programs like Torrent clients, Sonarr, Radarr, Jackett, etc before there were any 'vpn' Dockers of those programs available. To be honest, I do not feel like supporting a product that I do not use myself.

Also, what about getting a Privoxy Docker and route that Privoxy container through this passthrough container? 😉 I think that would give the same result, wouldn't it?

 

On 2/21/2021 at 5:56 PM, bipolartuna said:

Keen to give it a go, sounds like something useful, but I keep getting this in the log, I assume its not meant to be

 


2021-02-22 03:53:28.227194 [ERROR] Network is possibly down.
2021-02-22 03:53:29.243622 [INFO] Restarting container.

 

This is intended behaviour, it is possible that your container loses connection with your VPN provider (Session timeout for example), so, if 1 test ping to HEALTH_CHECK_HOST (defaults to one.one.one.one if unset) fails, it will restart the container if RESTART_CONTAINER is set to 'yes'.

Although, basing this of one ping is not the best way to do it, to quote my reply above;
"The problem is that pinging a host to check if the connection is actually up or down is not really reliable in my opinion at all, even though this is exactly what the container does. I've had enough times that the container thought it was down based on 1 failed ping, but was actually still up. I did test this by sending my a Telegram message instead of abruptly shutting down the container. I might look into a better solution to do, for example 10 pings and see if >30% failed, if so, restart the container."

Link to post
9 hours ago, sonic6 said:

If i use "restart_container" "yes" and your container restarted, the container i passthroughed aren't connectable anymore. so i have to restart them manually. do you have a workaround for that?

I am working on a script right now that can be added to the User Scripts plugin.

This script will check every x seconds if the passthroughvpn container has restarted. If it did restart, it will also restart all the containers that are getting passed through

 

1 hour ago, nakedfbiagent said:

Is there anyway to use this as a gateway for other devices on the network ? not just docker containers?

THis would be supper useful.

thanks for the work.

No, not possible.

Link to post

@sonic6 I've made a script that will check every 10 seconds if the `passthroughvpn` container did restart. If it did restart, it will restart all containers that are routed through it.

 

To install this script:

  1. In Unraid, go to the Apps section and install "CA User Scripts" from Squid
  2. Open the terminal in Unraid and run the following 3 commands:
  3. mkdir -p /boot/config/plugins/user.scripts/scripts/passthrough_restart
    echo 'This script will check if the passthroughvpn container has restarted and restart the passed through containers' > /boot/config/plugins/user.scripts/scripts/passthrough_restart/description
    wget -q https://raw.githubusercontent.com/DyonR/docker-passthroughvpn/master/restart-passed-through-containers.sh -O /boot/config/plugins/user.scripts/scripts/passthrough_restart/script
  4. In Unraid, go to Settings -> (User Utilities at the bottom) -> User Scripts
  5. Here you will see a script called 'passthrough_restart'. Set the schedule to At Startup of Array. And press Apply.
  6. Select Run In Background to start the script immediately. 

I hope this helps 😁

You actually shouldn't run random script on your server from a stranger online, so you can read the source of the script here:

https://github.com/DyonR/docker-passthroughvpn/blob/master/restart-passed-through-containers.sh

Link to post
On 2/22/2021 at 10:05 PM, Dyon said:

 I should probably also include something like this in the documentation on the GitHub page.

As @numblock699 said, 'curl ifconfig.io' is probably the quickest way to do this.

@DyonTrue that would be quicker/simpler but my example will test each of my containers(run the command on host, not inside a container) and it pulls data from two sources to show me both the IP and the country I am routing through.  Just a nice little sanity check I can copy/paste and see what all my containers are doing and confirm one isn't misconfigured and getting my actual IP.  They do not all run through one VPN so its nice to see a list.

So far, this container is great.  Thank you for the extremely detailed reply above as well.  Is there any way to allow communication to a specific (or set of) local address?  For example, if I pass NZBGet and Sonarr/Radarr through the VPN but I want to use connections to update Plex on download/rename/import or I want to add one of the containers to Organizr/Heimdall, they cannot reach each other.  I know this is obviously the intended behavior as we don't want any network traffic going over the unprotected WAN, but a LAN whitelist could be useful.

Link to post
13 hours ago, Aegisnir said:

@DyonTrue that would be quicker/simpler but my example will test each of my containers(run the command on host, not inside a container) and it pulls data from two sources to show me both the IP and the country I am routing through.  Just a nice little sanity check I can copy/paste and see what all my containers are doing and confirm one isn't misconfigured and getting my actual IP.  They do not all run through one VPN so its nice to see a list.

So far, this container is great.  Thank you for the extremely detailed reply above as well.  Is there any way to allow communication to a specific (or set of) local address?  For example, if I pass NZBGet and Sonarr/Radarr through the VPN but I want to use connections to update Plex on download/rename/import or I want to add one of the containers to Organizr/Heimdall, they cannot reach each other.  I know this is obviously the intended behavior as we don't want any network traffic going over the unprotected WAN, but a LAN whitelist could be useful.

 

> my example will test each of my containers

Ah, yeah I see! That's quite nice then! 👍

 

I believe all containers use the IP of the passthrough containers. NZBGet, Sonarr and Radarr would all share the same IP. If you pass NZBGet through the VPN, in Sonarr and Radarr you would need to get the IP of the download client to either 127.0.0.1 or the IP of the passthrough container, which would be the 172-address that you can see on the Docker dashboard in Unraid.

If NZBGet, Sonarr/Radarr are passed through the passthrough container, they should still be able to communicate with your actual local network, since the LAN_NETWORK variable of the passthrough container is 'responsible' for that.

I hope it make sense 😉

Link to post

I'm using this container for Plex, but I'm having issues that local playback still goes through the VPN.

 

In the Plex dashboard it tells me the stream is 'Remote' and I can almost certainly confirm this because I can't local playback Remux 4K streams directly, becuase the download tops at my maximum upload speed of my internet speed.

 

How can I fix this? I already pointed the Plex port so I can access the Plex server internally using the IP of my Unraid server + Plex port. In the Plex installation I do still see the local 172.17.0.4 : 32400.

 

Thanks for helping!

Edited by JNCK
Link to post

 

5 minutes ago, JNCK said:

I'm using this container for Plex, but I'm having issues that local playback still goes through the VPN.

 

In the Plex dashboard it tells me the stream is 'Remote' and I can almost certainly confirm this because I can't local playback Remux 4K streams directly, becuase the download tops at my maximum upload speed of my internet speed.

 

How can I fix this? I already pointed the Plex port so I can access the Plex server internally using the IP of my Unraid server + Plex port. In the Plex installation I do still see the local 172.17.0.4 : 32400.

 

Thanks for helping!

 

In Unraid, you must see something like this in the Docker tab:

+----------------+--------------------------+-------------------------------------------+
| Application    | Network                  | Port Mappings                             |
+================+==========================+===========================================+
| Plex           | container:passthroughvpn | :32400/TCP <==> :32400                    |
+----------------+--------------------------+-------------------------------------------+
| passthroughvpn | bridge                   | 172.17.0.x:32400 <==> 192.168.0.100:32400 |
+----------------+--------------------------+-------------------------------------------+

(172.17.0.x and 192.168.0.100 would obviously be your own IPs)

 

This means that in order to access Plex, you must go to http(s)://192.168.0.100:32400

The 172.17.0.4:32400 you see in Plex is most likely the same 172.17.0.x IP the passthrough container has.

How do you try to access your Plex server right now? You should use the 2nd IP shown at the port mappings (for me that would be 192.168.0.100:32400).

 

Link to post
9 minutes ago, Dyon said:

 

 

In Unraid, you must see something like this in the Docker tab:


+----------------+--------------------------+-------------------------------------------+
| Application    | Network                  | Port Mappings                             |
+================+==========================+===========================================+
| Plex           | container:passthroughvpn | :32400/TCP <==> :32400                    |
+----------------+--------------------------+-------------------------------------------+
| passthroughvpn | bridge                   | 172.17.0.x:32400 <==> 192.168.0.100:32400 |
+----------------+--------------------------+-------------------------------------------+

(172.17.0.x and 192.168.0.100 would obviously be your own IPs)

 

This means that in order to access Plex, you must go to http(s)://192.168.0.100:32400

The 172.17.0.4:32400 you see in Plex is most likely the same 172.17.0.x IP the passthrough container has.

How do you try to access your Plex server right now? You should use the 2nd IP shown at the port mappings (for me that would be 192.168.0.100:32400).

 

 

Yes, this is what I'm seeing. My server Unraid server is on IP 192.168.2.11. I can access Plex using 192.168.2.11 : 32400.

 

When I'm playing back 4K media using one of my devices on the 192.168.2.0/24 network it's not streaming the file using the local network, but is pulling the stream from the VPN (I've opened port forwarding there).

 

I can confirm the above, because when I'm playing back a large file Netdata is showing a high upload and doing an upload speedtest with Speedtest.net is very slow at that same moment.

 

My devices in the local network are pulling the stream from the VPN instead using a local route. Can really find a solution for this :/

Link to post
6 hours ago, JNCK said:

 

Yes, this is what I'm seeing. My server Unraid server is on IP 192.168.2.11. I can access Plex using 192.168.2.11 : 32400.

 

When I'm playing back 4K media using one of my devices on the 192.168.2.0/24 network it's not streaming the file using the local network, but is pulling the stream from the VPN (I've opened port forwarding there).

 

I can confirm the above, because when I'm playing back a large file Netdata is showing a high upload and doing an upload speedtest with Speedtest.net is very slow at that same moment.

 

My devices in the local network are pulling the stream from the VPN instead using a local route. Can really find a solution for this :/

 

That is quite odd. I've made a note for myself to look at this later this week. I'll do some testing to see if I can find a solution, or find what's going wrong.

Link to post
 
That is quite odd. I've made a note for myself to look at this later this week. I'll do some testing to see if I can find a solution, or find what's going wrong.

Thanks for helping!

I have this same issue with Radarr that’s routed through passthroughvpn where the import from the local SABNZBd to the local media folder also seems to cap out on my maximum upload speed. It seems like to container is sending the file to the VPN and then getting it back again? Very weird.

The above makes the importing proces after a successful download very slow :/


Verzonden vanaf mijn iPhone met Tapatalk
Link to post

Hi @Dyon

It seems like I've fixed it and it had nothing to do with your Docker container, I'm sorry about that.

 

The Plex issue was fixed by setting up a route in my network, so my devices are able to access the Docker container IP.

The Sonarr issue was fixed by setting up Sabnzbd and Sonarr so they both have in the container a /data folder and both are pointing to /mnt/user/. I found this solution here: https://www.reddit.com/r/unRAID/comments/knl0tp/how_to_start_troubleshooting_slow_transfer_speeds/

 

 

 

 

 

Link to post

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.