Reverse Proxy with Network routed through DelugeVPN

[Coercri]

I have Jackett routed through DelugeVPN docker, using the command --net=container:binhex-delugevpn in the extra parameters (from an excellent SpaceInvaders video), but I would like to also access Jackett through reverse proxy using Swag.

 

Is there anyway to do this - please be gentle, newbie here.

(Unraid 6.8.3)

 

Cheers

[JonathanM]

Add the port mapping for jackett's gui to the vpn container.

[MikaelTarquin]

On 2/17/2021 at 5:13 AM, JonathanM said:

Add the port mapping for jackett's gui to the vpn container.

 

Would you mind providing more detail on how to do this? I am in a similar situation with NZBGet. NZBGet has its network type set to "None", and extra parameters as needed for routing through my DelugeVPN container. To the DelugeVPN container, I have added both a container port 6789 that I named "nzbget port" and uses host port 6789 with connection type TCP, as well as a container variable named "VPN Input Ports" with key "VPN_INPUT_PORTS" and value "6789". I can access NZBGet through the webui locally at <local ip>:6789, but trying to access through my reverse proxy (SWAG) just results in Error 502 Bad Gateway. 

 

I know the reverse proxy can work, since if I revert the network setup for the NZBGet container to be on the proxy net my SWAG container is on, it is accessible just fine (but obviously no longer on the Deluge container's VPN). 

 

Thank you for your help!

[JonathanM]

40 minutes ago, MikaelTarquin said:

I can access NZBGet through the webui locally at <local ip>:6789, but trying to access through my reverse proxy (SWAG) just results in Error 502 Bad Gateway. 

What address are you using in the SWAG config? You should be using the address that works locally.

[MikaelTarquin]

7 minutes ago, JonathanM said:

What address are you using in the SWAG config? You should be using the address that works locally.

Sorry, I'm not sure I understand your question. I am using subdomains in SWAG, and have the subdomain "nzbget", among others that I use, added to the "SUBDOMAINS" SWAG container variable. 

 

I use the container variable DOCKER_MODS with value "linuxserver/mods:swag-maxmind|linuxserver/mods:universal-docker|linuxserver/mods:swag-auto-reload|linuxserver/mods:swag-auto-proxy" in SWAG, and in the containers getting reverse proxied the container label "swag" with value "enable" to get them working with SWAG, which I learned from this Ibracorp video. Maybe this is the source of my problem? This method has worked great for every other container I have reverse proxied, but maybe I need to learn another way for this one being routed in an odd way.

 

[JonathanM]

9 hours ago, MikaelTarquin said:

Sorry, I'm not sure I understand your question.

In the conf file that has your nzbget section, what value is in the proxy_pass line?

[MikaelTarquin]

5 hours ago, JonathanM said:

In the conf file that has your nzbget section, what value is in the proxy_pass line?

Hmm, I'm not sure how to answer that one, either. The auto proxy docker mod seems to handle that part for me. I don't manually rename any of the sample conf files under swag/nginx/proxy-confs/, so the relevant one is still the default nzbget.subdomain.conf.sample for me. Renaming this to remove the .sample at the end doesn't appear to change the functionality for my setup, either. However, the proxy_pass lines (there are multiple) in that sample file all say:

proxy_pass $upstream_proto://$upstream_app:$upstream_port;

 

I'm not sure what happens under the hood to let the auto proxy work, but I would assume it uses the same settings for every container.

 

For now, I have simply reverted my nzbget container to the docker network "proxynet" that the rest of my swag containers are on, and am relying on SSL within the container rather than routing through deluge's VPN (which has also dramatically improved the performance of nzbget, by about 5x). I think I'd still like to figure out a VPN solution, but I don't think this particular method works well with my SWAG reverse proxy needs.

[JonathanM]

29 minutes ago, MikaelTarquin said:

seems to handle that part for me

Yeah, automation only works if all the prerequisites are met. When you step outside the box, you have to learn how to do this kind of stuff manually. It's not really that difficult, just have to step through each bit and follow it back to determine where the values came from, and override with your specific values.

 

33 minutes ago, MikaelTarquin said:

am relying on SSL within the container rather than routing through deluge's VPN

IMHO it's pointless to push usenet through a vpn if the connection is already encrypted. The usenet provider knows who you are, the ISP can see the amount of traffic but can't see the content, which is the same situation with any encrypted traffic. The only reason vpn is useful for torrents is anybody in the torrent group can see everyone else's IP as well as the content. Remove the knowledge of the content with the SSL pipe to the usenet provider, and there is no quick way to analyze you like there is with torrents.

[MikaelTarquin]

30 minutes ago, JonathanM said:

Yeah, automation only works if all the prerequisites are met. When you step outside the box, you have to learn how to do this kind of stuff manually. It's not really that difficult, just have to step through each bit and follow it back to determine where the values came from, and override with your specific values.

 

IMHO it's pointless to push usenet through a vpn if the connection is already encrypted. The usenet provider knows who you are, the ISP can see the amount of traffic but can't see the content, which is the same situation with any encrypted traffic. The only reason vpn is useful for torrents is anybody in the torrent group can see everyone else's IP as well as the content. Remove the knowledge of the content with the SSL pipe to the usenet provider, and there is no quick way to analyze you like there is with torrents.

This is the kind of affirmation I love to hear, thank you!