Add Gluetun VPN Support for Apps

Feature Requests
, ,
1

Problem/Justification
When it comes to specific apps, like qBittorrent / torrent in general, or other more privacy-focused apps, it would be great to guarantee that all traffic is going over a VPN connection.

Impact
After the move of TrueCharts, a lot of users left behind with apps without native VPN support (which was a reason to use TrueCharts app for a lot of users in the first place). When having a native VPN integration, like Gluetun, right into an app chart, users could easily decide if they want to relay the specific app traffic over a VPN.

User Story
When setting up a new app, let the user decide, if they want to use a VPN. If so, let them provide the very few gluetun configuration values. Alternatively, let them provide OpenVPN config files or wireguard.

3 Likes
2

I’m not sure if I agree with this. If there are special routing/tunneling requirements, it may be better suited that they app be hosted in a VM, or that your network be properly configured with corresponding out-bound NAT rules. TrueNAS is not a router.

3 Likes
3

Gluetun has a docker-compose file that can already be deployed inside a jail or when electric eel launches natively with the future docker support. As far as i understand it all you have to do is add the docker container to the gluetun network for it to work. There’s not really a need for iX to invest time for this if all you have to do is customize the gluetun compose file with your vpn providers data and add a line to the compose file of the app that should use the vpn…

4 Likes
4

…plus there’s a crapton of other VPNs out there, and dealing with all of them would take quite some time.

3 Likes
5

This is the docker compose solution that can work with any app… Example is qbit but any app can use this process or even multiple apps using one VPN…

I would suggest familiarizing yourself with docker compose, it is the future

services:
  gluetun:
    container_name: qbit-gluetun
    image: qmcgaw/gluetun:v3.38.0
    user: 0:568
    ports:
      - 6881:6881 # Torrent
      - 6881:6881/udp # Torrent
      - 8085:8085 #path to qbit
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    restart: unless-stopped
    environment:
      - PUID=568
      - #VPN_SERVICE_PROVIDER=Enter Provider name
      - #VPN_TYPE=wireguard
      - #WIREGUARD_PRIVATE_KEY=Enter Key
      - #WIREGUARD_PRESHARED_KEY=Enter Key
      - #WIREGUARD_ADDRESSES=Enter IP
      - #SERVER_COUNTRIES=Enter Country
      - #TZ=Enter Timezone
      - FIREWALL_OUTBOUND_SUBNETS=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    volumes:
      #- /mnt/pathonhostforgluetunstorage:/gluetun
  qbittorrent:
    container_name: qbittorrent #temporary passowrd in container logs
    image: ghcr.io/linuxserver/qbittorrent:libtorrentv1-release-4.6.5_v1.2.19-ls31
    restart: unless-stopped
    environment:
      - #PUID=Enter PUID
      - #PGID=Enter GUID
      - #TZ=Enter Timezone
      - WEBUI_PORT=8085
    network_mode: service:gluetun
    depends_on:
      - gluetun
    volumes:
      #- /mnt/pathonhostforqbitconfigstorage:/config
      #- /mnt/pathonhostforqbitdownload:/mnt/download
4 Likes
6

To clarify things, this was a feature request to make the official apps more accessible for users, who don’t want to make their own custom apps.

I know how to use docker (compose) and already running multiple apps with custom networking. I just thought, embedding this would be quite easily to integrate, as the move to docker is coming anyway, and would make users, who were left behind by TrueCharts, happy.

Oh well, seems thats not the case. I didn’t want guides, how to use custom apps, there’s already plenty. I just wanted to make clear, that users, who don’t want to deal much with anything outside of normal GUI, would be happy to see this feature.

As some of you already pointed out, this is a quite easy setup with compose, so why not make it native in iX apps?

7

No clue, what you’re trying to say, as my request is not for a specific VPN provider, but for gluetun (or alternatively wireguard-client or openvpn-client).

8

Well you’ll have to learn eventually since the next Version removed the current kubernetes apps system and implements docker. Therefore it’s very unlikely for iX to invest manpower to implement Something that’ll be gone in 3 months

9

Ah, now I see, this is a complete missunderstanding, it seems…
The request is for the upcoming release, I should point that out.
Edit: It seems, I’m not allowed anymore to edit my initial feature request.

Again, it’s not about me having to learn something, I made this purely for conveniency. I already run compose stuff, as pointed out in my above reply.

10

No clue as to what you’re not understanding: There’s a crapton of VPN clients out there and dealing with all of them would take much more time and resources that iX is willing to invest (i.e. as little as possible).
Users dealing with custom apps and custom setups is the plan all along.

1 Like
11

Thats exactly the reason, why I mentioned gluetun, which supports openvpn and wireguard ootb (not really sure about any other widely used clients, these are de facto the gold standard).
If the plan is to just let users set up custom apps, why offer an official catalogue in the first place? I thought, it’s for the ease-of-use of TrueNAS in general.

Edit: I just wanted to make a feature request, that makes TrueNAS easily accessible for normal users and VPN integration was one of the main reasons for users switching to the Truecharts apps. For me personally, it’s fine to use custom apps, but I still think, implementing this would be a HEAVY improvement to the official apps.

12

With the switch to docker, you don’t have to rely on iX or anyone else to implement a vpn solution. Since its just native docker in the future just use the gluetun compose file, add the docker container you want to the gluetun network and you’re good to go.
No need to rely on iX ore anyone else to implement a vpn solution.

13

I don’t understand the negativity here–this is something that was do-able (and done, by TrueCharts) in Apps 1.0. It’s entirely reasonable, IMO, to suggest that app configuration include routing its traffic via a VPN of the user’s choice. That it’s possible to do it some other way doesn’t mean it’s an invalid request for the apps themselves.

By this logic, there’s no reason for iX to put in any effort developing or maintaining apps at all. Which, coincidentally, is exactly what I expect them to conclude.

Edit: not voting for this one because I’m just not interested in iX’ apps any more. It’s evident to me that they don’t really want to do this–in the 15 years they’ve been advertising them, they’ve never put adequate resources into maintaining them. I don’t see any reason to expect it will be any different this time around. But, of course, I could be wrong.

2 Likes
14

The TrueCharts implementation leaked peoples real IPs. There are other instances and examples of this if you look in their support Discord.

The implications of this are real legal and privacy concerns. The official catalog should not get involved in any of that, at least in my opinion. As linked above, you can do whatever you want with compose.

2 Likes
15

Was this a bug in their implementation, or was it something that could not have been helped? Because “someone else did it wrong” doesn’t sound like a very good reason to not try to do it right. Or to let the community try to do it right. Oh, wait, they’re taking that option away.

2 Likes
16

I believe it was a race condition, where the torrenting application would start before the tunnel was established.

I think my position is more along the lines of “Why should iX spend engineering hours trying to help people do legally questionable activities”

You can, with compose. Or in a VM. Or with proper firewall policies.

17

Its an interesting project with one primary developer.
It looks like it should work with Electric Eel & Docker Compose.
I’d suggest testing it with Electric Eel next month and identifying any issues.

For longer term, the question will be whether Gluton or native Wireguard is easier to support/deploy? Would native wireguard be sufficient?

18

I think, any major client would be sufficient, so wireguard or openvpn would be great. :slight_smile:

1 Like
20

I know this topic is a little old, so I’d to add my 2c as a new TrueNAS user who just went through this. I wanted to install qBittorrent to download Linux ISOs and route the traffic through a VPN, so I did some research and found many different solutions from various people: using Gluetun, making a custom docker-compose with qBit+gluetun, etc. What I finally ended up doing was installing the regular qBit from the community apps, and adding an init script to start a Wireguard VPN with the built-in wg-quick command. Then, in qBit, I just set it to use the “wg0” network interface. This seemed like the most straightforward way of accomplishing this without having to do a custom app, using Portainer/Dockge to manage things, etc.

The only thing I don’t like is that TrueNAS doesn’t have built-in support for Wireguard, aside from including wg-quick in the build. It would be nice if there were an app in the UI to either point to a .conf file, or edit one directly there, and then have the tunnel show up in the networking tab of the UI. It’d be even better if the routing could be configurable so that only particular containers’ traffic used that interface.

21

I have invested time setting up and configuring several native truenas apps. It would be great to have an option have those apps use a VPN without re-configuring them as docker compose apps.
I have setup gluetun with qbittorrent via docker compose on electric eel. While it was not complicated, it would be nice to have this ability from within the native app UI config.

3 Likes