Perfect-Privacy and Port-Management/-Forwarding

[olvier]

Hi,

i'm try to troubleshooting my problem with connection to perfect-privacy.
I'm using gluetun in docker with standard "docker run" from the wiki here.
Everything is fine, gluetun obtains an ip-address and it seems to be everything fine.

I'm using vpn for linux-image sharing via torrent.
Also at the trackers and torrent-checker is shown the right IP and Port.

But with those port-checkers from the web, the ports are "all" closed.
At the trackers I'm not connectable, too.
Of course, I just need one port, but i tried those 3 ports from the port-calculator and i also tried a pre-defined port.
Non of them are open. I don't have any further idea, where to look for an error.

Somebody has an idea, hint or experience?

System:
Synology NAS, newest gluetun image.

[bnhf]

@olvier

Have you logged into your account at Perfect-Privacy to setup an open port?

Have you configured gluetun to open that same port through its firewall?

Have you mapped that port in your container stack?

The gluetun wiki covers this topic:
https://github.com/qdm12/gluetun/wiki/VPN-server-port-forwarding

[olvier]

@olvier

Have you logged into your account at Perfect-Privacy to setup an open port?

Yeah. I did both. The last year I worked totally noiseless (with another container) with those self-calculated ports by the internal container-IP ( ifconfig tun0 ) and a script, which tells qbit the right port.
For error-potential-reduction I now the created a "static" port in the web-gui. ll are staying closed

Have you configured gluetun to open that same port through its firewall?

Puh. How do I do that? I mean, the port is calculated AFTER the containter starts, because its calculated by the IP, which is obtained while create connection. I just forwarded the static ports for qbit-web-gui. I never used to forward other ports. Maybe because of --cap-add=NET_ADMIN?

Have you mapped that port in your container stack?

The gluetun wiki covers this topic: https://github.com/qdm12/gluetun/wiki/VPN-server-port-forwarding

Same as above, but i will read about it. I never stumbled about that before.

[bnhf]

@olvier

As it says in the wiki, each VPN provider has their own method of opening a port. In the case of AirVPN, which I use, that port is valid across all of their servers (though I only use their servers from one country). Their built-in port checker will test a number of servers, but will only show as open for the server I'm connected to at that time.

[olvier]

"Getting VPN port forwarding set up when using containers can be a pain since the port number is dynamic. This plugin automatically updates the incoming port for Deluge based on the current forwarded port." SOURCE linked TO

I guess, this is a problem I already solved a year before. In perfect-privacy, the port is calculated in dependency of the internal vpn-ip. The calculated port I "send" to qbittorrent, what worked very well, the whole last year.

As mentioned, also the tracker sees the right IP and port where I am sharing from. But the ports are all closed. I never had any troubles with forwarding of ports.

Do I need this? Its in the Deluge Tutorial.

But my setup is dead simple. Its from the wiki and I just added the city and the ports for the qbit-webgui.

[bnhf]

@olvier

So I spun-up a qBittorrent container to take a look at the setup, and it actually seems quite similar to Deluge.

The Linuxserver.io Docker image has a recommended docker-compose that looks like this:

version: "2.1"
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - WEBUI_PORT=8080
    volumes:
      - /path/to/appdata/config:/config
      - /path/to/downloads:/downloads
    ports:
      - 8080:8080
      - 6881:6881
      - 6881:6881/udp
    restart: unless-stopped

Looking at the ports, 8080 would be the WebUI, and 6881 and 6881/udp would be the listening ports (though these can be changed).

And within qBittorent, you can see that same listening port set, with the option to generate a new random one:

So adapting this to a gluetun setup where qBittorrent would use the VPN exclusively, you'd be using a docker-compose like this:

version: "3"
services:
    gluetun:
        image: qmcgaw/gluetun:latest
        container_name: gluetun
        cap_add:
            - NET_ADMIN
        ports:
            - 8080:8080 # qBittorrent webui
            - 6881:6881 # qBittorrent listening port
            - 6881:6881/udp # qBittorrent listening port/udp
        environment:
            - VPN_SERVICE_PROVIDER=perfect privacy
            - OPENVPN_USER=abc
            - OPENVPN_PASSWORD=abc
            - OPENVPN_CITIES=Amsterdam
            - FIREWALL_VPN_INPUT_PORTS=6881
            - PUID=1000
            - PGID=1000
            - TZ=Europe/Amsterdam
        volumes:
            - /data/openvpn:/gluetun
 
    qbittorrent:
        image: lscr.io/linuxserver/qbittorrent:latest
        container_name: qbittorrent
        environment:
            - PUID=1000
            - PGID=1000
            - TZ=Europe/Amsterdam
            - DELUGE_LOGLEVEL=error
        volumes:
            - /data/qbittorrent:/config # Change to your desired config directory mapping
            - ~/Downloads/complete:/downloads # Change to your desired download data directory
        network_mode: 'service:gluetun'
        depends_on:
            - gluetun

With the above setup, you can either open a port through your VPN provider or not. Both should work -- though there should be some performance advantage to configuring an open port through your provider's setup pages. They'll likely assign you a different port than 6881, in which case you'll need to update the port # in your docker-compose and in your qBittorrent interface.

[bnhf]

Keeping in mind it's not a requirement to forward a specific port through your VPN, Perfect Privacy looks to support custom forwarding of up to 5 addresses:

You'd be looking at the 1-to-1 forwarding with automatic renewal I would think. Use the port number they generate and plug it in to your docker-compose and qBittorrent options page. Restart your container stack, and you should be good-to-go.

[olvier]

Dear bnhf,

you absolutely pointed me into the right direction.
Everything what you mentioned, I did before. The last year my setup ran exactly like this.

But what changed now?

The months before, I used those 3 calculated ports, as mentioned before. Everytime the internal container-ip changes, the ports changed. This worked quite well, with the container from dperson/openvpn-client. (I automatically changed the ports in the qbit-instance with some scripting)

Now, for error-potential-reduction I tried your mentioned 1:1 forwarded port, which unfortunately changes after one week. but for testing its okay.

I added the points

-e FIREWALL_VPN_INPUT_PORTS=48111 \
-p 48770:48770/udp \

to my docker-config.

I guess, the last one is useless here, but the important one is that FIREWALL-thingy (its just a suppose, I will find out later)

After starting the container, i tried the before mentioned port-checker, whether they are open or not. And guess what, the 1:1 is open, those calculated one not. (Maybe just because the firewall-thingy?)

After some time, the connection-"button" in the bottom of qbit colored green (means connected), after round about 20 minutes, in the linux-iso-trackers i was connectable again.

So now, there are the new problems to solve:
Why do I need to define the open port? Because in the other container (dperson/openvpn-client) it worked without. And the second problem is, i need to re-build the container every week again, with the newly created port -.-

But for now, I'm one or two steps beyond today in the morning :)

So, a big big thanks for your patience and your interest and invested time :)

If I find a solution for the newly created problems, I will update here. If you or some others have further ideas, your'e welcome.

[olvier]

Small update here, for some others, who need to run with perfect privacy.

For error reduction, you should disable those TrackStop-Feature from PP #1144, so the container connects w/o any errors.
This leads to a cleaner, and less misleading log-overview.

For getting connectable in torrent via perfect privacy, you have to options. (at least from my point of view ;) hopefully there are some others?)

First option:
Take the docker run or compose from here and add
-e FIREWALL_VPN_INPUT_PORTS=40152,60220 << its for docker run
The ports you create in the PP-preferences at "1-to-1 port forwarding to random port"
Maybe you just need one, I'm using 2, because of 2 torrent instances.
cons: they got deleted/refreshed every week, so you need to rebuild the container every week.

Second option:
Take the docker run or compose from here and add
-e FIREWALL=off << its for docker run
Then you could use the "automated port-forwarding" from PP, which creates 3 calculated ports, in dependency from the internal(!!) vpn-IP (ifconfig tun0 in your gluetun-container).
Those calculated ports are still closed, when checking it with a port-scanner, but becomes opened, when added to your torrent-instance. Me didn't know either.

The second option sounds also like editing the ports in all your client-instances from time to time,
but with some clever scripting, there is no need of it.
In the FAQ from PP is a script for calculating the ports.
And with this calculated ports, you can maybe edit your clients by script.
For qbittorrent for example, you can change the port via web-API. It's a one-liner.

So for now, I guess I'm done for the next year with editing or changing the ports :)

I giant thank you again, to @bnhf for the fresh view and the right ideas for further researching and testing.

@qdm12, is FIREWALL=off the best idea, to do so? A disabled firewall sounds not that much trustworthy.

But maybe you could add my lessons-learned to your PP-config. It was an experience with blood, sweat and tears ;)

[bnhf]

@olvier

Just curious about one thing: The way I read Perfect-Privacy's website, if you select 1-to-1 port forwarding and you tick the box to "Automatically renew expired forwardings" it suggests that those same ports are renewed. Is that not the case? If not, what does that tick box actually do?

[olvier]

@olvier

Just curious about one thing: The way I read Perfect-Privacy's website, if you select 1-to-1 port forwarding and you tick the box to "Automatically renew expired forwardings" it suggests that those same ports are renewed. Is that not the case? If not, what does that tick box actually do?

What do you mean with "those same ports are renewed"?
How could PP renew the same ports?
After one week, you get some new random ports.
Those new random ports you have to fill into your service-clients (torrent for example).

[jagaimoworks]

@olvier #2368 implements native port forwarding for Perfect Privacy's automatic portforwarding feature. You just need to put VPN_PORT_FORWARDING=on in your Gluetun environment.

You can check the forwarded ports via the built-in control server.

To reliably test if the ports are actually forwarded you can host a simple webserver with the port-checker script. You then access the server at http://external-vpn-ip:forwarded-port. Just make sure that the browser you are checking with is not using your VPN (see Port Fail mitigation.

[qdm12]

Note the (3) ports forwarded are also logged in the Gluetun logs 😉

[olvier]

@jagaimoworks, i've read about this implementation, but i did not needed that in the past.
I had a working routine for about two years (?) with gluetun an PP.
The only negative aspect was, that the firewall was off ;)

But after moving to another location with my NAS, i wasnt able to get gluetun with full functionalities, again.

You just need to put VPN_PORT_FORWARDING=on in your Gluetun environment.

i already did, while testing and reading about #2368, nothing changed.

You can check the forwarded ports via the built-in control server.

Didn't knew that, thank you for that. But the forwarded ports are "port": 0
Don't know, how the behavior was before, because it worked as supposed to.
I guess, all ports where open, because of --env=FIREWALL=off.

To reliably test if the ports are actually forwarded you can host a simple webserver with the port-checker script.

Should be the same as testing with external services ala portchecker.de and portchecker.co?

edit:
i'm a little bit confused!
the api and the logs tell me ip 10.204.XXX.111, where torrenting site and wget -qO - icanhazip.com say 10.204.XXX.113
Any idea why?

[qdm12]

The only negative aspect was, that the firewall was off ;)

Maintainer here. Do not, I repeat, do not turn the firewall off. It got recently renamed from FIREWALL_ENABLED to FIREWALL_ENABLED_DISABLING_IT_SHOOTS_YOU_IN_YOUR_FOOT for a reason 😭 !

@olvier What image version are you using - it's logged at the start of the gluetun logs - ? I suggest you try re-pulling the latest image and re-create the container, since that perfect privacy port forwarding implementation is rather recent. That's probably why it doesn't work. It should also log it's executing port forwarding in your logs.

[olvier]

Hey @qdm12, do you have written about some scenarios, what could happen, when disabling the firewall?
I'm really interested in it!

I've read about the new implementation for PP, but i re-created afterwards. In the logs i didn't stumbled about the 3 mentioned ports. So, because i remember, that the compose wasn't that big, i re-created from scratch.
And what should i say, it works ;) Also i find now the 3 calculated ports. Little bit weird, but it works for now.
I also don't know, what's the difference in the old and the new one.
I mean, i also tried the old config with an old build ;)

So, I'm absolutely happy, again.

[qdm12]

what could happen, when disabling the firewall?

All your traffic can go through your normal network interface and not use the VPN at all. So kind of bad and makes Gluetun completely useless really.

Little bit weird, but it works for now.

It's probably Docker wrappers such as Portainer tend to not re-create the container using the newer image. It's just buggy 🤷