search

guillaumedsde / alpine-qbittorrent-openvpn

qBittorrent docker container with OpenVPN client running as unprivileged user on alpine linux
https://guillaumedsde.gitlab.io/alpine-qbittorrent-openvpn/
GNU General Public License v3.0
216 stars 40 forks source link

write UDP: Operation not permitted (code=1) using ExpressVPN #59

Open Leiasticot opened 3 years ago

Leiasticot commented 3 years ago

Information

Here is what I got inside my portainer logs :

Mon Jan 11 22:40:40 2021 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.

Mon Jan 11 22:40:40 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]84.17.43.194:1195

Mon Jan 11 22:40:40 2021 Socket Buffers: R=[180224->360448] S=[180224->360448]

Mon Jan 11 22:40:40 2021 UDP link local: (not bound)

Mon Jan 11 22:40:40 2021 UDP link remote: [AF_INET]84.17.43.194:1195

Mon Jan 11 22:40:40 2021 write UDP: Operation not permitted (code=1)

Mon Jan 11 22:40:42 2021 write UDP: Operation not permitted (code=1)

Mon Jan 11 22:40:46 2021 write UDP: Operation not permitted (code=1)

Mon Jan 11 22:40:54 2021 write UDP: Operation not permitted (code=1)

Mon Jan 11 22:41:10 2021 write UDP: Operation not permitted (code=1)

Mon Jan 11 22:41:40 2021 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Mon Jan 11 22:41:40 2021 TLS Error: TLS handshake failed

Mon Jan 11 22:41:40 2021 SIGUSR1[soft,tls-error] received, process restarting

Mon Jan 11 22:41:40 2021 Restart pause, 5 second(s)

Current setup

I'm using a Raspberry pi 4 running on Raspberry pi OS. I use a manual config.ovpn (I run a first time without and I got an error, then I move my config.ovpn inside /openvpn/config.ovpn then I restart the container.

docker-compose.yml file or docker run command

version: "3.7"
services:
  alpine-qbittorrent-openvpn:
    container_name: qbittorrentvpn
    volumes:
      - /mnt/BLACKPEARL/seedbox:/downloads
      - ~/docker/qbittorrent:/config
      - /etc/localtime:/etc/localtime:ro
    environment:
      - OPENVPN_USERNAME=expressvpnusername
      - OPENVPN_PASSWORD=expressvpnpassword
      - PUID=1000
      - PGID=1000
      - LAN=192.168.1.0/24
    ports:
      - "8080:8080"
    cap_add:
      - NET_ADMIN
    image: guillaumedsde/alpine-qbittorrent-openvpn:latest

Here is my config.ovpn

dev tun
fast-io
persist-key
persist-tun
nobind
remote france-paris-2-ca-version-2.expressnetw.com 1195
remote-random
pull
comp-lzo no
tls-client
verify-x509-name Server name-prefix
ns-cert-type server
key-direction 1
route-method exe
route-delay 2
tun-mtu 1500
fragment 1300
mssfix 1200
verb 3
cipher AES-256-CBC
keysize 256
auth SHA512
sndbuf 524288
rcvbuf 524288
auth-user-pass

CERTIFICATE

Attempted Fix(es)

Tried to change the server inside the config.ovpn Tried to use NordVPN (but I can't make it work)

Thanks !

vadimstasiev commented 3 years ago

I have the same issue with HMA (HideMyAss) Here is the command that I run:

sudo docker run --restart unless-stopped --cap-add=NET_ADMIN -d \
              -v /etc/docker-configs/qBittorrent:/config/qBittorrent/data/BT_backup \
              -v /etc/docker-configs/qBittorrent/GeoDB:/config/qBittorrent/data/GeoDB \
              -v /etc/docker-configs/qBittorrent/rss:/config/qBittorrent/data/rss \
              -v /etc/docker-configs/qBittorrent/config:/config/qBittorrent/config \
              -v /etc/docker-configs/qBittorrent/cache:/config/qBittorrent/cache \
              -v /home/server/Media/library/torrent:/data \
              -e OPENVPN_PROVIDER=HIDEMYASS \
              -e OPENVPN_USERNAME=user \
              -e OPENVPN_PASSWORD=pass \
          -e PUID=1000 \
              -e PGID=1000 \
              -e LAN=192.168.0.0/24 \
              -p 8080:8080 \
              guillaumedsde/alpine-qbittorrent-openvpn:latest
chrispalka commented 3 years ago

Having same issue, this is literally the only container for ARM that I could get semi working with ExpressVPN. In a prior post, it was recommended to only have one remote in your config.ovpn file which I double checked, but still running into this issue.

inertia666 commented 3 years ago

Having same issue, this is literally the only container for ARM that I could get semi working with ExpressVPN. In a prior post, it was recommended to only have one remote in your config.ovpn file which I double checked, but still running into this issue.

If you need something working for now then you should consider using the Transmission container

https://haugene.github.io/docker-transmission-openvpn/building-blocks/

It will get you up and running with something until these issues with QBT are fixed.

chrispalka commented 3 years ago

Thank you, I was not looking to do so, but may be worth the switch for now.

fischy667 commented 3 years ago

I'm using https://hub.docker.com/r/binhex/arch-qbittorrentvpn until this is fixed.

LuisPerez64 commented 3 years ago

Issue comes up in the setup of the IP Tables. It's due to the way the VPN_PROTO env variable is defined. The multiple wrap arrounds of the quotes causes it to expand incorrectly. Excerpts of running /etc/cont-init.d/03-setup-iptables with set -x below

+ VPN_PROTO=''"'"'udp'"'"
... redacted 1 line
+ DNS_SERVER=1.1.1.1
... redacted 1 line
+ '[' -z ''"'"'udp'"'" ]
+ '[' ''"'"'udp'"'" '=' tcp-client ]
... redacted N unaffected lines
+ iptables -A OUTPUT -j ACCEPT -d usa-newyork-ca-version-2.expressnetw.com -o eth+ -p ''"'"'udp'"'" -m ''"'"'udp'"'" --dport 1195
iptables v1.8.4 (legacy): unknown protocol "'udp'" specified
Try `iptables -h' or 'iptables --help' for more information.
+ iptables -A INPUT -j ACCEPT -s usa-newyork-ca-version-2.expressnetw.com -i eth+ -p ''"'"'udp'"'" -m ''"'"'udp'"'" --sport 1195
iptables v1.8.4 (legacy): unknown protocol "'udp'" specified
Try `iptables -h' or 'iptables --help' for more information.

Quick fix is doing docker cp {CONTAINER_NAME}:/etc/cont-init.d/03-setup-iptables {LOCAL_PATH}; modifying VPN_PROTO VPN_PROTO=udp and mounting the modified file into the container {DOCKER_CMD} -v {LOCAL_PATH}:/etc/cont-init.d/03-setup-iptables.

ishaanx commented 3 years ago

I am facing the same issue with Surfshark. On latest docker image.

Here is my config - 

# QBT
  qbt:
    image: guillaumedsde/alpine-qbittorrent-openvpn:latest
    container_name: qbt
    cap_add:
      - NET_ADMIN
    volumes:
      - $DCDATA/qbt/config:/config
      - $DCDATA/qbt/downloads:/downloads
      - /mnt/hdd1:/hdd1
      - /mnt/hdd2:/hdd2
    environment:
      - OPENVPN_PROVIDER=
      - OPENVPN_CONFIG=$DCDATA/qbt/config/openvpn/config.ovpn
      - OPENVPN_USERNAME=$VPN_USERNAME
      - OPENVPN_PASSWORD=$VPN_PASSWORD
      - PUID=$PUID
      - PGID=$PGID
      - LAN=192.168.0.1/16
      - VIRTUAL_HOST=$TORRENT_VHOST
    expose:
      - 8080
    devices:
      - /dev/net/tun
    restart: always

Here is the error - 

qbt                 | 2021-09-29 16:38:29 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
qbt                 | 2021-09-29 16:38:29 TCP/UDP: Preserving recently used remote address: [AF_INET]156.146.62.46:1194
qbt                 | 2021-09-29 16:38:29 Socket Buffers: R=[212992->212992] S=[212992->212992]
qbt                 | 2021-09-29 16:38:29 UDP link local: (not bound)
qbt                 | 2021-09-29 16:38:29 UDP link remote: [AF_INET]156.146.62.46:1194
qbt                 | 2021-09-29 16:38:29 write UDP: Operation not permitted (code=1)
qbt                 | 2021-09-29 16:38:31 write UDP: Operation not permitted (code=1)
qbt                 | 2021-09-29 16:38:35 write UDP: Operation not permitted (code=1)
wivaku commented 2 years ago

Not clear why this is still an issue. The workaround @LuisPerez64 mentioned worked for me. Instead of his suggested hardcoded udp in 03-setup-iptables just remove the quotes.

So:

I have submitted a pull request to implement this fix.

mortiis commented 2 years ago 
VPN_PROTO="${CONFIG_PROTO:=udp}"

This fix does not work for me, I'm still getting write UDP: Operation not permitted (code=1).

wivaku commented 2 years ago

@mortiis: does your OpenVPN config file have a proto line in it, and if so does it have udp in quotes? The scripts tries to get the protocol from the OpenVPN config file and if that does not exist it defaults to udp.

After applying the workaround make sure this command

docker exec alpine-qbittorrent-openvpn grep -e "^VPN_PROTO" /etc/cont-init.d/03-setup-iptables

returns:

VPN_PROTO="${CONFIG_PROTO:=udp}"

So: without quotes around udp.

mortiis commented 2 years ago

@wivaku: It does have a proto udp line, exactly like that.

[user@host ~]# docker exec qbittorrent grep -e "^VPN_PROTO" /etc/cont-init.d/03-setup-iptables returns VPN_PROTO="${CONFIG_PROTO:=udp}"

wivaku commented 2 years ago

@mortiis That's strange. You could check what iptables thinks of it. Mine (after the workaround):

docker exec qbittorrent-openvpn iptables -S | grep udp | grep -v 53

-A INPUT -s <ipaddressofvpn>/32 -i eth+ -p udp -m udp --sport 1194 -j ACCEPT
-A INPUT -s <ipaddressofvpn>/32 -i eth+ -p udp -m udp --sport 443 -j ACCEPT
-A OUTPUT -d <ipaddressofvpn>/32 -o eth+ -p udp -m udp --dport 1194 -j ACCEPT
-A OUTPUT -d <ipaddressofvpn>/32 -o eth+ -p udp -m udp --dport 443 -j ACCEPT

And if yours looks the same then I guess there can be other issues as well. The workaround is still useful for setting up iptables correctly though.

mortiis commented 2 years ago

@wivaku

[~] # docker exec qbittorrent iptables -S | grep udp | grep -v 53
-A INPUT -s <ip>/32 -i eth+ -p udp -m udp --sport 0 -j ACCEPT
-A OUTPUT -d <ip>/32 -o eth+ -p udp -m udp --dport 0 -j ACCEPT

Seems there's an issue with sport and dport! So I checked how 03-setup-iptables got its ports, then checked my ovpn config file and found it lacked port definition after remote <server>. I added the port and now everything works as expected, even on a fresh image without the workaround! Notable is that I'm using a custom ovpn, so, my bad. However, the config file worked for the haugene/transmission-openvpn image.

Thanks for the help!

tinoucas commented 2 years ago

I have been having this same issue, and none of the workarounds shown here worked. But looking at my iptables: I had different IP addresses for input and output.

I tried to ping my VPN server (the 'remote' in the .ovpn file) and I get a different IP almost every time (using Surfshark). For now, I chose one of those IP and set it as vpn 'remote' in the .ovpn file. And it worked!

It would be nice for openvpn to connect first (to whatever IP responds at that moment) and then make iptables rules based on the connection.