Reverse proxy of other services (Sonarr, Radarr, etc.) connected to the docker-transmission-openvpn network

[garret]

I have connected other containers (Sonarr, Radarr, etc...) to the docker-transmission-openvpn container by using the --network container:transmission-openvpn option. Everything works, thus all the containers are also under the vpn network.

However, I would like to access also their web interface outside my local network. I have been using the haugene/transmission-openvpn-proxy image to get the transmission web interface to be accessible from outside. That works, but what if I also want to add the other services (Sonarr, Radarr, etc...)?

May I ask for some help in how to modify the nginx.conf present in https://github.com/haugene/docker-transmission-openvpn/tree/master/proxy so that I could build my own image of the proxy?

[pkishino]

To be honest, for accessing any of my internal interfaces I went away from opening it up and instead closed down everything and setup WireGuard server in my local and only my setup devices can now access everything from everywhere as if they were local, it’s just more secure and simple

[garret]

@pkishino I agree, I had also actually set up a wireguard instance which was working as you mention. However, I recently moved to a new place where port forwarding is not possible and, thus, don't have the possibility to set up a wireguard server. To circumvent the problem I am using ZeroTier (for those who don't know what it is, it is just a solution like Hamachi for those old people who remember it).

Hope that explains why I unfortunately have to go via the annoying reverse proxy solution.

[pkishino]

had a quick look and should be simple if you google nginx config etc.. you would need to create new locations for the different services you want to use, that should be all and then rebuild locally. Will close for now.. if you get it working feel free to submit a PR that would update and allow other services as well

[garret]

@pkishino as I wrote before, I have always found this nginx stuff quite difficult to understand. I ended up solving by using ZeroTier as mentioned above. Hope someone will update with a more elegant solution anytime in the future.

[pkishino]

@garret I just pushed an updated nginx with an example added

[garret]

Sorry, I reopen this topic as only now I am finally having time to play around. I have transmission-openvpn and sonarr(from linuxserver on standard port 8989) that share the same network (so sonarr is also behind vpn too). I also started the transmission-proxy container to be able to access such container from "outside".

This is an extract of my docker-compose file (removed some not-needed lines to make it simpler):

version: '3'
services:
    transmission:
        container_name: transmission
        cap_add:
            - NET_ADMIN
[...]
# Ports disabled as I will have them enabled in the proxy to access from outside
#        ports:
#            - 9091:9091 #Transmission
#            - 8989:8989 #Sonarr
# ipv6 must be disabled for Mullvad to work
        sysctls:
            - "net.ipv6.conf.all.disable_ipv6=0"
        logging:
            driver: json-file
            options:
                max-size: 10m
        restart: unless-stopped
        image: haugene/transmission-openvpn

    transmission-proxy:
        container_name: transmission-proxy
        volumes:
            - ${CONFIG_FOLDER}/transmission-proxy/nginx.conf:/etc/nginx/nginx.conf
        ports:
            - 9091:9091 #Transmission
            - 8989:8989 #Sonarr
        links:
            - transmission:transmission
        restart: unless-stopped
        image: haugene/transmission-openvpn-proxy

    sonarr:
        container_name: sonarr
[...]
        network_mode: 'service:transmission'
        depends_on:
            - transmission
        restart: unless-stopped
        image: ghcr.io/linuxserver/sonarr

And this is the nginx.conf file from the transmission-proxy:

events {
  worker_connections 1024;
}

http {

  # In case of big files
  client_max_body_size 200M;

  server {
    listen 9091;

    location / {
      proxy_pass http://transmission:9091;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      # HTTP 1.1 support
      proxy_http_version 1.1;
      proxy_set_header Connection "";
    }
    location /sonarr {
      proxy_pass http://transmission:8989;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      # HTTP 1.1 support
      proxy_http_version 1.1;
      proxy_set_header Connection "";
    }
  }

}

I am able to access transmission through the 9091 port but I am not able to see Sonarr (on port 8989). Can you help me understanding what I am doing wrong?

EDIT: Ok I just realized that I should use http://ipaddress:9091/sonarr for the reverse proxy but I get a 404 Not Found error when accessing that address. Do you know why and how to fix it?

EDIT 2: It seems that the only way to solve is to create a second transmission-proxy container but this one is linked to the sonarr container(links: sonarr:sonarr). This is a "fix" but there is a way to solve without creating many nginx containers? I don't have only sonarr but also other services behind the transmission-openvpn.

[pkishino]

try changing location / to location /transmission also, if you change the listen to 80 then you could drop the port..

[garret]

@pkishino I already tried. In this way I can still reach transmission but this time at the new address http://ipaddress:9091/transmission but still no success with sonarr at http://ipaddress:9091/sonarr

[pkishino]

Hmm, strange.. is there anything in the logs of the proxy? Can you go inside the container and check nginx logs.. Have you tried setting port back to default 8080? I thought when I added examples I tested this and it worked.. perhaps I can take a look later this week

On Tue, Apr 20, 2021 at 20:23 Enzo @.***> wrote:

@pkishino https://github.com/pkishino I already tried. In this way I can still reach transmission but this time at the new address http://ipaddress:9091/transmission but still no success with sonarr at http://ipaddress:9091/sonarr..

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/haugene/docker-transmission-openvpn/issues/1737#issuecomment-823195758, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA7OFYRQHFLPH7XJGOTUFBLTJVP4PANCNFSM4YCGXTTQ .

[garret]

This is what I get in the nginx logs container when I try to go on http://ipaddress:9091/sonarr

2021/04/20 11:49:46 [error] 31#31: *199 open() "/etc/nginx/html/login" failed (2: No such file or directory), client: 192.168.0.50, server: , request: "GET /login?returnUrl=/sonarr HTTP/1.1", host: "X.X.X.X:9090"

192.168.88.50 - garret [20/Apr/2021:11:49:46 +0000] "GET /login?returnUrl=/sonarr HTTP/1.1" 404 153 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0"

2021/04/20 11:49:46 [error] 31#31: *199 open() "/etc/nginx/html/favicon.ico" failed (2: No such file or directory), client: 192.168.0.50, server: , request: "GET /favicon.ico HTTP/1.1", host: ""X.X.X.X:9090", referrer: "http://"X.X.X.X:9090/login?returnUrl=/sonarr"

192.168.88.50 - garret [20/Apr/2021:11:49:46 +0000] "GET /favicon.ico HTTP/1.1" 404 153 "http://"X.X.X.X:9090/login?returnUrl=/sonarr" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0"

At the same time I notice that the address in the address bar changes to http://ipaddr:9090/login?returnUrl=/sonarr (and to recap I get a 404 not found error page).

I have another container running (amule) in a setup like sonarr (so withnetwork_mode: 'service:transmission' and depends_on: transmission). If I go to http://ipaddress:9091/amule I can see the login page and everything works but just the images of the webpages are not loaded.

Thus, it seems to depend on the type container maybe? The ones from linuxserver (sonarr, jackett, bazarr, etc...) don't work at all for instance.

Again, the only way to solve seems to create a proxy container for each of my container that shares the same network with transmission-openvpn. The issue is that I have 6 containers "linked" to transmission-openvpn and thus it would mean to create 6 more nginx containers. I was hoping there was a cleaner way to achieve my end goal.

EDIT: I noticed that if I set the in urlbase settings of sonarr the field /sonarr/, then the reverse proxy works when I access http://ipaddress:9091/sonarr Now I have to figure out how to change somehow this urlbase in such containers where I cannot directly change it. Hope there is an easy fix to solve this by doing something on the nginx.conf file.

EDIT 2: I think I resolved. The issue was as I had already figured out above that in sonarr I have to setup such urlbase to /sonar/. I did the same for other services and the reverse proxy works in this way. Thank you very much for staying with me. I usually like to deep down things but this reverse proxy thing seems so obscure to me. Glad I managed to get it work and hopefully don't have to touch it more...

[pkishino]

@garret great, so to clarify, could you share your now working nginx conf ? I'll add it as an example on the wiki with the necessary changes needed.. also, could you try the following and see if this might be enough to fix it on nginx side alone? https://serverfault.com/a/379679

[tim0901]

Apologies for digging this up again, but having struggled with this issue myself I've managed to figure out a cleaner way to do it and thought it might be useful for the wiki. My docker-compose file is as above, while my nginx.conf file is now as follows:

events {
  worker_connections 1024;
}

http {

  # In case of big files
  client_max_body_size 200M;

  server { # transmission
    listen 9091;

    location / { 
      proxy_pass http://transmission:9091;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      # HTTP 1.1 support
      proxy_http_version 1.1;
      proxy_set_header Connection "";
    }
  }
  server { # sonarr
    listen 8989;

    location / { 
      proxy_pass http://transmission:8989;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      # HTTP 1.1 support
      proxy_http_version 1.1;
      proxy_set_header Connection "";
    }
  }
}

Doing it this way means you don't need to alter any URLBase values and allows your services to be accessed as normal - as if there isn't a proxy running at all. For this example that would be 192.168.1.XXX:9091 for transmission or 192.168.1.XXX:8989 for sonarr. I've also confirmed using curl ifconfig.co -4 from within the containers that the traffic is indeed being routed through the vpn.

For each additional service you want to add, you simply add an additional server stanza, changing the ports to those required by your service. Additional ports can be also directed to a container by listing them:

server {
    listen 80;
    listen 8000;
    ...
}

It might also be worthwhile linking the nginx docs page on the topic.

[garret]

I agree with @tim0901 that seem a more clean and easy way to setup things.