Feature request: Protonvpn port forwarding with multiple ports

[qdm12]

What's the feature 🧐

Protonvpn supports up to 5 ports (TCP+UDP count as 1). One just needs to request the port with the natpmp protocol specifying 5 different internal ports of their choosing. The external port won't match the internal ports though. Right now it's only one port (we send internal port 0 and external port 1), but the external and internal ports match.

Extra information and references

• See https://www.reddit.com/r/ProtonVPN/comments/zv3dva/comment/jlgkq6r/
• Initially discussed in P2P Proton VPN Ports qdm12/gluetun-wiki#66

[github-actions]

@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:

• do not ask for updates, be patient
• 👍 the issue to show your support instead of commenting
  @qdm12 usually checks issues at least once a week, if this is a new urgent bug,
  revert to an older tagged container image

[GordonFreemanK]

Hi!

This would be really nice in that it would allow running more than one application relying on incoming connections, or an application relying on multiple incoming ports, on a single gluetun instance. I have two comments.

External & Internal port numbers

The reddit link indicates that at best you get 6 ports in total (UDP+TCP). 1 is automatic and is the one that gluetun already supports, and 5 are additional and have a different external and internal values; the internal value is set by the VPN client (gluetun in this case) but the external port is selected by ProtonVPN on connection (like is already the case for the single port currently supported by gluetun). I think out of the box most clients do not allow advertising a different external port than the one they listen to, so the internal port needs to then be redirected again, within the gluetun container, to the same value as the external one in order for this to be usable. For instance, if you establish port forwarding to internal port 50000 and you get a random external port of 34567, you need to reroute the internal port 50000 to 34567, so that an application can listen to AND advertise 34567 as the incoming port.

I think this is possible via ip tables (see here) but I just thought I'd point that out.

Port number advertising

There's also the question of how gluetun would advertise these ports to the container(s) containing the listening application(s), since the external port is not known in advance. Currently the port randomly selected by ProtonVPN on connection is advertised by gluetun by writing to /tmp/gluetun/forwarded_port and also on the control server (GET /portforwarded).
I imagine backwards compatibility need to be maintained. Maybe a new directory with files in them (e.g. /tmp/gluetun/forwarded_ports/x where x is a number, like they did it here) and the possibility of specifying a port index on the control server (e.g. GET /portforwarded?index=x)?

Once that's done, the client containers also need to change to support it. This is beyond the scope of gluetun though.

[SpaghettiBorgar]

I played around with the mechanics a bit and made a little script to be run as a separate docker container that can request more random ports form the VPN by first requesting them to fixed local ports and then remapping them symmetrically using iptables.

Example compose.yaml:

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add:
      - NET_ADMIN
    environment:
      - VPN_SERVICE_PROVIDER=protonvpn
      - SERVER_COUNTRIES=Lithuania
      - PORT_FORWARD_ONLY=on
      - VPN_PORT_FORWARDING=off
    ...
  forwarder:
    build:
      context: .
      dockerfile_inline: |
        FROM alpine:latest
        RUN apk add --no-cache bash iptables libnatpmp curl wget
        ADD https://gist.githubusercontent.com/SpaghettiBorgar/83dccbcec9edcd2951bbd5debde67136/raw/portforward /usr/local/bin/portforward
        RUN chmod +x /usr/local/bin/portforward
        CMD ["portforward"]
    network_mode: service:gluetun
    cap_add:
      - NET_ADMIN
    environment:
      PMP_ROUTER: 10.2.0.1
      PMP_INTERVAL: 50
      PMP_PORT_UP_CMD1: >
        echo "Got Port1 at $$PORT";
        echo "$$PORT" > /ports/port1;
      PMP_PORT_UP_CMD2: >
        echo "Got Port2 at $$PORT";
        echo "$$PORT" > /ports/port2
    volumes:
      - port_mappings:/ports
    depends_on:
      gluetun:
        condition: service_healthy
        restart: true
volumes:
  port_mappings:

Up to (theoretically) 9 ports can be forwarded by defining the NAT_PORT_UP_CMDn variables which hold the command to be executed when the port gets acquired. The commands are evaluated as-is within the script's bash context, so unlike gluetun's port-up command you get access to the port by using the $PORT variable, which has to be escaped as $$PORT within the compose file. You can then use curl etc. for applications with an API or write it to a file in a stack-wide volume.

Note that currently there is no command for when the port goes down and that the script will run the command on every mapping request at each interval, not just when the port changes.

[JC-LB]

That would be excellent for cross seed with qBitorrent, alongside the port set command.

[qdm12]

Can anyone try :pr-3208 with VPN_PORT_FORWARDING_PORTS_COUNT=2 for example? It should also work with up to 5. If it works fine, proceed with testing by adding variable VPN_PORT_FORWARDING_LISTENING_PORTS=7001,7002,7003,7004,7005 to check if redirection works fine as well with 5 different ports (basically does not crash the container somewhere)

EDIT: you can also use the VPN_PORT_FORWARDING_UP_COMMAND (and down) command using the {{PORTS}} template variable which would be for example 8931,43241 and have your script handle the csv parsing etc.