Unable to access WebUI - Githubissues

lcdt22890158 commented 1 year ago

The container launches successfully, the logs indicate that it has connected to the VPN successfully and launched Deluge successfully. But I'm not able to access the Web UI, I just get "The connection has timed out".

I'm using TrueNAS with bhyve running a Ubuntu Server 21.10 VM with Docker Swarm. My docker-compose.yml file looks like this:

version: '3.8'
services:
  deluge:
    cap_add:
      - CAP_NET_ADMIN
    deploy:
      mode: replicated
      replicas: 1
    image: binhex/arch-delugevpn
    environment:
      - VPN_ENABLED=true
      - VPN_USER=myprotonusername
      - VPN_PASS=hunter2
      - VPN_PROV=custom
      - VPN_CLIENT=openvpn
      - STRICT_PORT_FORWARDING=no
      - ENABLE_PRIVOXY=no
      - LAN_NETWORK=192.168.10.240/24
      - NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1
      - DELUGE_DAEMON_LOG_LEVEL=info
      - DELUGE_WEB_LOG_LEVEL=debug
      - DEBUG=true
      - PUID=1003
      - PGID=1004
    volumes:
      - /mnt/nas/working/deluge/config:/config
      - /mnt/nas/working/deluge:/data
    ports:
      - 8112:8112
      - 58846:58846
      - 58946:58946

Log files:

But when I access http://192.168.10.240:8112 the connection times out.

ProtonVPN doesn't currently support port forwarding on non-Windows platforms, so I've got STRICT_PORT_FORWARDING disabled. I also tried having LAN_NETWORK set to 192.168.10.0/24 with the same result. I tried configuring the Docker port as 9094:8112 and accessing http://192.168.10.240:9094 as well, also no luck.

I'm able to access other containers running on the same node (such as pyMedusa and Jackett) without any issues.

I'm not really sure what other steps I should take to troubleshoot the issue.

AngelaDMerkel commented 1 year ago

I had this issue recently too, and redeploying the container didn't immediately resolve the issue. After like 10 minutes the reverse proxy began working for be my DNS resolution fails. Editing /etc/resolv.conf doesn't fix the the problem. It seems there are other users with this issue. Can you check if you can ping google.com?

I read your log and it claims it was able to resolve google.com at some point.

lcdt22890158 commented 1 year ago

From within the container I can access WAN hosts and resolve DNS

[root@4cd2cc20f625 /]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=305 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=305 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 304.523/304.947/305.371/0.424 ms

[root@4cd2cc20f625 /]# ping google.com
PING google.com (142.250.65.206) 56(84) bytes of data.
64 bytes from lga25s72-in-f14.1e100.net (142.250.65.206): icmp_seq=1 ttl=116 time=389 ms
64 bytes from lga25s72-in-f14.1e100.net (142.250.65.206): icmp_seq=2 ttl=116 time=378 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 377.782/383.256/388.731/5.474 ms

as well as hosts on my LAN (notably this only works if LAN_NETWORK is set to 192.168.10.0/24, it does not work with 192.168.10.240/24.

[root@4cd2cc20f625 /]# ping 192.168.10.240
PING 192.168.10.240 (192.168.10.240) 56(84) bytes of data.
64 bytes from 192.168.10.240: icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from 192.168.10.240: icmp_seq=2 ttl=64 time=0.028 ms
^C
--- 192.168.10.240 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1013ms
rtt min/avg/max/mdev = 0.028/0.031/0.034/0.003 ms

and from within the container I can access Deluge on any interface except eth1:

[root@4cd2cc20f625 /]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.18.0.2/16 scope global tun0
       valid_lft forever preferred_lft forever
26105: eth1@if26106: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default 
    link/ether 02:42:0a:00:00:a8 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet 10.0.0.168/24 brd 10.0.0.255 scope global eth1
       valid_lft forever preferred_lft forever
26107: eth2@if26108: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:12:00:09 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet 172.18.0.9/16 brd 172.18.255.255 scope global eth2
       valid_lft forever preferred_lft forever
26109: eth0@if26110: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default 
    link/ether 02:42:0a:00:0c:ca brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.12.202/24 brd 10.0.12.255 scope global eth0
       valid_lft forever preferred_lft forever
[root@4cd2cc20f625 /]# curl --head 127.0.0.1:8112
HTTP/1.1 200 OK
Server: TwistedWeb
Date: Mon, 05 Dec 2022 11:11:34 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2284

[root@4cd2cc20f625 /]# curl --head 10.18.0.2:8112
HTTP/1.1 200 OK
Server: TwistedWeb
Date: Mon, 05 Dec 2022 11:11:41 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2284

[root@4cd2cc20f625 /]# curl --head 10.0.0.168:8112
^C
[root@4cd2cc20f625 /]# curl --head 172.18.0.9:8112
HTTP/1.1 200 OK
Server: TwistedWeb
Date: Mon, 05 Dec 2022 11:11:59 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2284

[root@4cd2cc20f625 /]# curl --head 10.0.12.202:8112
HTTP/1.1 200 OK
Server: TwistedWeb
Date: Mon, 05 Dec 2022 11:12:05 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2284

But from outside the container, Deluge WebUI is not accessible.

If I set iptables to allow all connections

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

then it lets me access WebUI from outside the container, so the issue is not with the Docker ports, it's definitely with the generated iptables rules.

I tried feeding the iptables rules to this simulator but it seemed to think the packets should be allowed.

maxfield-allison commented 9 months ago

I currently experiencing identical behavior right now on the qbittorrent container. did you ever resolve the issue?

zombielinux commented 7 months ago

Has this been looked at? I've got identical behavior.

i.e. Can't access the webui with VPN enabled, but can access without.

maxfield-allison commented 7 months ago

check out https://github.com/binhex/arch-qbittorrentvpn/issues/203 and https://github.com/binhex/arch-int-vpn/issues/32.

I've been working with binhex and we're now waiting on the fix.

binhex commented 7 months ago

i.e. Can't access the webui with VPN enabled, but can access without.

There are a 1001 reasons for this, its a bit like saying my car wont start, could be no fuel, could be no spark plugs, it could be no engine, etc, please do the following to give me a clue as to what is going on:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

if @lcdt22890158 is still watching this, your issue is incorrect lan_network, see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

binhex / arch-delugevpn

Unable to access WebUI #337