Hi everybody!

I'm having some troubles using this container and I wonder if you could help me. 

Using the docker container in bridge mode seems to work just fine and I'm even able to use it to add vpn to other containers adding their ports in the config, and I'm able to access the webui using the host IP with the 8112 port.

My problem is that I would like to change it to a new network (br0) because I have my pihole and nginx proxy manager there.

The thing is that when I change the deluge container to the new network, nothing fails and I can curl the webpage from the docker container itself, but I can't access it from my computer.

This is the run command that it prompts the docker webpage in my nas:

 

docker run
  -d
  --name='binhex-delugevpn'
  --net='br0'
  --ip='10.168.2.135'
  --privileged=true
  -e TZ="Europe/London"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="NAS"
  -e HOST_CONTAINERNAME="binhex-delugevpn"
  -e 'TCP_PORT_8112'='8112'
  -e 'TCP_PORT_58846'='58846'
  -e 'TCP_PORT_58946'='58946'
  -e 'UDP_PORT_58946'='58946'
  -e 'TCP_PORT_8118'='8118'
  -e 'VPN_ENABLED'='yes'
  -e 'VPN_USER'=<myvpnusername>
  -e 'VPN_PASS'=<myvpnpassword>
  -e 'VPN_PROV'='custom'
  -e 'VPN_CLIENT'='openvpn'
  -e 'VPN_OPTIONS'=''
  -e 'STRICT_PORT_FORWARD'='yes'
  -e 'ENABLE_PRIVOXY'='no'
  -e 'LAN_NETWORK'='10.168.2.0/24'
  -e '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'
  -e 'DELUGE_DAEMON_LOG_LEVEL'='info'
  -e 'DELUGE_WEB_LOG_LEVEL'='info'
  -e 'DELUGE_ENABLE_WEBUI_PASSWORD'='yes'
  -e 'VPN_INPUT_PORTS'='8080,8090,7878,8989,9897,5055,6789,5454'
  -e 'VPN_OUTPUT_PORTS'='8080,8090,7878,8989,9897,5055,6789,5454'
  -e 'DEBUG'='false'
  -e 'UMASK'='000'
  -e 'PUID'='99'
  -e 'PGID'='100'
  -e 'UDP_PORT_9696'='9696'
  -e 'TCP_PORT_8080'='8080'
  -e 'TCP_PORT_8090'='8090'
  -e 'TCP_PORT_7878'='7878'
  -e 'TCP_PORT_8989'='8989'
  -e 'TCP_PORT_9897'='9897'
  -e 'TCP_PORT_5055'='5055'
  -e 'TCP_PORT_6789'='6789'
  -e 'TCP_PORT_5454'='5454'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8112]/'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/deluge-icon.png'
  -v '/mnt/user/Downloads/Torrents/':'/data':'rw'
  -v '/mnt/user/appdata/binhex-delugevpn':'/config':'rw'
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-delugevpn'

 

I have noticed that using `docker inspect binhex-delugevpn` the PortBindings section is empty when I use the br0 network, but filled up with all the ports when it's in bridge. 

Thanks for any help in advance!

Cheers,

Nestor

 

Just updated last night and realized I cannot connect.  Have to go to hospital for two procedures right now so can't post more.

 

\_ |__ |__| ____ |  |__   ____ ___  ___
 | __ \|  |/    \|  |  \_/ __ \\  \/  /
 | \_\ \  |   |  \   Y  \  ___/ >    <
 |___  /__|___|  /___|  /\___  >__/\_ \
     \/        \/     \/     \/      \/
   https://hub.docker.com/u/binhex/

2024-07-03 08:32:04.737222 [info] Host is running unRAID
2024-07-03 08:32:04.758591 [info] System information Linux 4147556f4dbf 6.1.79-Unraid #1 SMP PREEMPT_DYNAMIC Fri Mar 29 13:34:03 PDT 2024 x86_64 GNU/Linux
2024-07-03 08:32:04.776293 [info] SHARED_NETWORK not defined (via -e SHARED_NETWORK), defaulting to 'no'
2024-07-03 08:32:04.793744 [info] PUID defined as '99'
2024-07-03 08:32:04.813363 [info] PGID defined as '100'
2024-07-03 08:32:04.915804 [info] UMASK defined as '000'
2024-07-03 08:32:04.938860 [info] Permissions already set for '/config'
2024-07-03 08:32:04.961340 [info] Deleting files in /tmp (non recursive)...
2024-07-03 08:32:04.985296 [info] VPN_ENABLED defined as 'yes'
2024-07-03 08:32:05.003445 [warn] VPN_CLIENT not defined (via -e VPN_CLIENT), defaulting to 'openvpn'
2024-07-03 08:32:05.020984 [info] VPN_PROV defined as 'pia'
2024-07-03 08:32:05.041050 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/ca_toronto.ovpn
2024-07-03 08:32:05.075031 [info] VPN remote server(s) defined as 'ca-toronto.privacy.network,'
2024-07-03 08:32:05.090500 [info] VPN remote port(s) defined as '1198,'
2024-07-03 08:32:05.105898 [info] VPN remote protcol(s) defined as 'udp,'
2024-07-03 08:32:05.123468 [info] VPN_DEVICE_TYPE defined as 'tun0'
2024-07-03 08:32:05.141027 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2024-07-03 08:32:05.158545 [info] NAME_SERVERS defined as '1.1.1.1,8.8.8.8,1.0.0.1,8.8.4.4'
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error

 

Tried changing my DNS:

 

2024-07-03 08:45:27,752 DEBG 'start-script' stdout output:
2024-07-03 08:45:27 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2024-07-03 08:45:27,752 DEBG 'start-script' stdout output:
2024-07-03 08:45:27 TCP/UDP: Preserving recently used remote address: [AF_INET]149.88.97.241:1198
2024-07-03 08:45:27 UDPv4 link local: (not bound)
2024-07-03 08:45:27 UDPv4 link remote: [AF_INET]149.88.97.241:1198

2024-07-03 08:45:30,315 DEBG 'start-script' stdout output:
2024-07-03 08:45:30 [toronto402] Peer Connection Initiated with [AF_INET]149.88.97.241:1198

2024-07-03 08:45:30,345 DEBG 'start-script' stdout output:
2024-07-03 08:45:30 TUN/TAP device tun0 opened
2024-07-03 08:45:30 net_iface_mtu_set: mtu 1500 for tun0

2024-07-03 08:45:30,345 DEBG 'start-script' stdout output:
2024-07-03 08:45:30 net_iface_up: set tun0 up
2024-07-03 08:45:30 net_addr_v4_add: 10.21.112.9/24 dev tun0
2024-07-03 08:45:30 /root/openvpnup.sh tun0 1500 0 10.21.112.9 255.255.255.0 init

2024-07-03 08:45:30,355 DEBG 'start-script' stdout output:
2024-07-03 08:45:30 Initialization Sequence Completed

2024-07-03 08:46:27,525 DEBG 'start-script' stdout output:
[info] DNS failure, creating file '/tmp/dnsfailure' to indicate failure...

2024-07-03 08:46:27,528 DEBG 'start-script' stdout output:
[info] Attempting to get external IP using 'http://checkip.amazonaws.com'...

2024-07-03 08:46:27,563 DEBG 'start-script' stdout output:
[info] Failed on last attempt, attempting to get external IP using 'http://whatismyip.akamai.com'...

2024-07-03 08:46:27,573 DEBG 'start-script' stdout output:
[info] Failed on last attempt, attempting to get external IP using 'https://ifconfig.co/ip'...

2024-07-03 08:46:27,583 DEBG 'start-script' stdout output:
[info] Failed on last attempt, attempting to get external IP using 'https://showextip.azurewebsites.net'...

2024-07-03 08:46:27,593 DEBG 'start-script' stdout output:
[warn] Cannot determine external IP address, performing tests before setting to '127.0.0.1'...
[info] Show name servers defined for container

2024-07-03 08:46:27,594 DEBG 'start-script' stdout output:
nameserver 192.168.1.1

2024-07-03 08:46:27,594 DEBG 'start-script' stdout output:
[info] Show contents of hosts file

2024-07-03 08:46:27,594 DEBG 'start-script' stdout output:
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
ff00::0	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.17.0.3	8258d56b9091
191.96.36.104	ca-toronto.privacy.network
104.18.36.183	www.privateinternetaccess.com
104.19.240.167	serverlist.piaservers.net

2024-07-03 08:46:27,596 DEBG 'start-script' stdout output:
[info] Script started to assign incoming port for 'pia'

2024-07-03 08:46:27,596 DEBG 'start-script' stdout output:
[info] Port forwarding is enabled
[info] Checking endpoint 'ca-toronto.privacy.network' is port forward enabled...

2024-07-03 08:46:27,710 DEBG 'start-script' stdout output:
[info] Sending SIGTERM (-15) to 'openvpn' due to dns failure...

2024-07-03 08:46:27,764 DEBG 'start-script' stdout output:
2024-07-03 08:46:27 event_wait : Interrupted system call (fd=-1,code=4)

2024-07-03 08:46:27,764 DEBG 'start-script' stdout output:
2024-07-03 08:46:27 net_addr_v4_del: 10.21.112.9 dev tun0

2024-07-03 08:46:27,787 DEBG 'start-script' stdout output:
2024-07-03 08:46:27 /root/openvpndown.sh tun0 1500 0 10.21.112.9 255.255.255.0 init

2024-07-03 08:46:27,804 DEBG 'start-script' stdout output:
2024-07-03 08:46:27 SIGTERM[hard,] received, process exiting

2024-07-03 08:46:27,810 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2024-07-03 08:46:27,833 DEBG 'start-script' stdout output:
2024-07-03 08:46:27 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2024-07-03 08:46:27 WARNING: file 'credentials.conf' is group or others accessible

2024-07-03 08:46:27,833 DEBG 'start-script' stdout output:
2024-07-03 08:46:27 OpenVPN 2.6.11 [git:makepkg/ddf6bf6d2a135835+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Jun 20 2024
2024-07-03 08:46:27 library versions: OpenSSL 3.3.1 4 Jun 2024, LZO 2.10
2024-07-03 08:46:27 DCO version: N/A

2024-07-03 08:46:27,834 DEBG 'start-script' stdout output:
2024-07-03 08:46:27 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2024-07-03 08:46:27,836 DEBG 'start-script' stdout output:
2024-07-03 08:46:27 TCP/UDP: Preserving recently used remote address: [AF_INET]104.18.159.201:1198
2024-07-03 08:46:27 UDPv4 link local: (not bound)

2024-07-03 08:46:27,836 DEBG 'start-script' stdout output:
2024-07-03 08:46:27 UDPv4 link remote: [AF_INET]104.18.159.201:1198

 

Edited July 4, 20242 yr by craigr
shrank

And now it just connected... using my local unbound DNS 192.168.1.1

Edited July 4, 20242 yr by craigr
It did not connect

44 minutes ago, craigr said:

Just updated last night and realized I cannot connect.  Have to go to hospital for two procedures right now so can't post more.

 

\_ |__ |__| ____ |  |__   ____ ___  ___
 | __ \|  |/    \|  |  \_/ __ \\  \/  /
 | \_\ \  |   |  \   Y  \  ___/ >    <
 |___  /__|___|  /___|  /\___  >__/\_ \
     \/        \/     \/     \/      \/
   https://hub.docker.com/u/binhex/

2024-07-03 08:32:04.737222 [info] Host is running unRAID
2024-07-03 08:32:04.758591 [info] System information Linux 4147556f4dbf 6.1.79-Unraid #1 SMP PREEMPT_DYNAMIC Fri Mar 29 13:34:03 PDT 2024 x86_64 GNU/Linux
2024-07-03 08:32:04.776293 [info] SHARED_NETWORK not defined (via -e SHARED_NETWORK), defaulting to 'no'
2024-07-03 08:32:04.793744 [info] PUID defined as '99'
2024-07-03 08:32:04.813363 [info] PGID defined as '100'
2024-07-03 08:32:04.915804 [info] UMASK defined as '000'
2024-07-03 08:32:04.938860 [info] Permissions already set for '/config'
2024-07-03 08:32:04.961340 [info] Deleting files in /tmp (non recursive)...
2024-07-03 08:32:04.985296 [info] VPN_ENABLED defined as 'yes'
2024-07-03 08:32:05.003445 [warn] VPN_CLIENT not defined (via -e VPN_CLIENT), defaulting to 'openvpn'
2024-07-03 08:32:05.020984 [info] VPN_PROV defined as 'pia'
2024-07-03 08:32:05.041050 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/ca_toronto.ovpn
2024-07-03 08:32:05.075031 [info] VPN remote server(s) defined as 'ca-toronto.privacy.network,'
2024-07-03 08:32:05.090500 [info] VPN remote port(s) defined as '1198,'
2024-07-03 08:32:05.105898 [info] VPN remote protcol(s) defined as 'udp,'
2024-07-03 08:32:05.123468 [info] VPN_DEVICE_TYPE defined as 'tun0'
2024-07-03 08:32:05.141027 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2024-07-03 08:32:05.158545 [info] NAME_SERVERS defined as '1.1.1.1,8.8.8.8,1.0.0.1,8.8.4.4'
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error
Error: error sending query: Could not send or receive, because of network error

 

Please see Q35 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

25 minutes ago, binhex said:

Please see Q35 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

My question is then why does my local unbound DNS server work? 192.168.1.1. According to the Q&A it should not.  I do block other DNS servers with OPNsense, but until today your Docker worked fine.  I’ll have to look back, but I must have a rule to allow your docker to use another DNS server since it’s always worked.  
 

Deluge connected Monday morning because it was automatically shutdown for backup at 4:00 on the 2nd of July.  I was out of town.  I don’t let the deluge Docker auto update.  I manually updated it last night and went to bed.  Then realized this morning I was not connected and in that DNS loop.

Edited July 3, 20242 yr by craigr
Spelling

27 minutes ago, craigr said:

My question is then why does my local unbound DNS server work? 192.168.1.1. According to the Q&A it should not.

Local name servers will be able to resolve the endpoints but when a name resolution is triggered after the vpn tunnel is up you should find that name resolution fails and a /tmp/dnsfailure file will be created to indicate this, this will then result in the tear down and re-creation of the tunnel, which will cycle again doing the same, if this is not happening then i would be interested in seeing the output of your supervisord.log file with debug set to true.

29 minutes ago, craigr said:

 I do block other DNS servers with OPNsense, but until today your Docker worked fine.  I’ll have to look back, but I must have a rule to allow your docker to use another DNS server since it’s always worked.  

OK so the previous image allowed a small window on startup where name resolution for the endpoints would be done by whatever the host is set to use, in your case most probably local name server, it would then wipe the resolv.conf and re-create it with the defined NAME_SERVERS, this process of wiping out the resolv.conf has been brought forward and thus the window no longer exists (security reasons), forcing name resolution to only be done by the defined NAME_SERVERS, so that's how it previously did work and now does not.

So the fix - permit outbound name resolution on OPNSense, or roll back to the previous image (not recommended).

 

6 minutes ago, binhex said:

Local name servers will be able to resolve the endpoints but when a name resolution is triggered after the vpn tunnel is up you should find that name resolution fails and a /tmp/dnsfailure file will be created to indicate this, this will then result in the tear down and re-creation of the tunnel, which will cycle again doing the same, if this is not happening then i would be interested in seeing the output of your supervisord.log file with debug set to true.

OK so the previous image allowed a small window on startup where name resolution for the endpoints would be done by whatever the host is set to use, in your case most probably local name server, it would then wipe the resolv.conf and re-create it with the defined NAME_SERVERS, this process of wiping out the resolv.conf has been brought forward and thus the window no longer exists (security reasons), forcing name resolution to only be done by the defined NAME_SERVERS, so that's how it previously did work and now does not.

So the fix - permit outbound name resolution on OPNSense, or roll back to the previous image (not recommended).

 

When I left for the hospital I tried to connect with my DNS at 192.168.1.1 and it failed the first time.  I restarted deluge docker and it worked second attempt and deluge was running with clients connected when I left.  I’ll get you the files you request as soon as I am able.  I’m in my first surgery as we speak but will be incapacitated for second surgery.  I’ll try to get you info tomorrow but I have a full day.

 

OK, I did not think I had a DNS rule to allow deluge Docker to use alternate DNS.  Your change makes sense than and explains why the Docker worked using external DNS until this update (I guess because it was really using my local DNS).  Also explains why it’s Q&A 35 and the newest (or at least last) on your list  

Correction, I just checked and have no clients connected.  I’ll have to fix it when I get home.  Crap.

 

Your upgrade appears to be working as you intend.

Edited July 3, 20242 yr by craigr

16 minutes ago, craigr said:

 I’m in my first surgery as we speak but will be incapacitated for second surgery.

Hey no rush!, i hope it all goes well for ya.
 

13 minutes ago, craigr said:

Correction, I just checked and have no clients connected.  I’ll have to fix it when I get home.  Crap.

I am pleased about that, but i can understand you may not be 🙂 if it makes you feel any better i have done this change for a good reason, honest, thus my recommendation NOT to rollback.

49 minutes ago, binhex said:

Hey no rush!, i hope it all goes well for ya.
 

I am pleased about that, but i can understand you may not be 🙂 if it makes you feel any better i have done this change for a good reason, honest, thus my recommendation NOT to rollback.

Thanks.  I get it, it'll be fine, I just have to make some adjustments.

 

The drugs are kicking in so yeah, I'm good 🤪.

Edited July 3, 20242 yr by craigr
spelling and grammar

I can hardly think, but it looks like I have it working:

 

 

 

2024-07-03 12:49:51,081 DEBG 'watchdog-script' stdout output:
Setting "listen_ports" to: (41229, 41229)
Configuration value successfully updated.

2024-07-03 12:49:51,081 DEBG 'watchdog-script' stderr output:
<Deferred at 0x14b632742120 current result: None>

2024-07-03 12:49:53,475 DEBG 'watchdog-script' stderr output:
<Deferred at 0x1508d64ce570 current result: None>

2024-07-03 12:49:53,519 DEBG 'watchdog-script' stdout output:
[info] No torrents with state 'Error' found

2024-07-03 12:49:53,520 DEBG 'watchdog-script' stdout output:
[info] Starting Deluge Web UI...

2024-07-03 12:49:53,520 DEBG 'watchdog-script' stdout output:
[info] Deluge Web UI started

2024-07-03 12:58:53,270 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '41229'

Edited July 4, 20242 yr by craigr
shrank

I have a similar problem. I have the container on a VLAN. In the previous image I just used an extra parameter --dns 192.168.30.1 (I guess because of that small time window mentioned this no longer is allowed).  

 

I use opensense. Adding 192.168.30.1 to NAME_SERVERS and everything works again except I'm not able access the Web UI.  

 

"So the fix - permit outbound name resolution on OPNSense" 

@binhexCan you please provide some more details the right way to do this on what interface? I only need access on the same VLAN. Thx   

 

 

I’m sorry, but I use my Brocade switch to manage my vlans.  My only vlan that sees OPNsrnse is ve1.  I don’t know how to specify this in OPN or PF.

30 minutes ago, chr said:

I have a similar problem. I have the container on a VLAN. In the previous image I just used an extra parameter --dns 192.168.30.1 (I guess because of that small time window mentioned this no longer is allowed).  

 

I use opensense. Adding 192.168.30.1 to NAME_SERVERS and everything works again except I'm not able access the Web UI.  

 

"So the fix - permit outbound name resolution on OPNSense" 

@binhexCan you please provide some more details the right way to do this on what interface? I only need access on the same VLAN. Thx   

I can probably figure out sense when my brain is less foggy.  Right now I'm going to sleep.

16 minutes ago, craigr said:

I can probably figure out sense when my brain is less foggy.  Right now I'm going to sleep.

Appreciate it. I should do the same 🙂

4 hours ago, chr said:

Appreciate it. I should do the same 🙂

Here is my FLOATING rule.  Could you not just put the IP of your client in regardless of vlan?  Not sure, just woke and am very foggy.

 

 

 

 

Edited July 3, 20242 yr by craigr

On 4/21/2024 at 4:30 PM, socbutter said:

I forgot my web-gui password to binhex - DelugeVPN. I tried the following without success.

 

 

 I did not try the command-line since I don't know what I'm doing.

Any suggestion would be appreciated.

I've run into a weirdly similar issue, but after removing it and having it set back to the default it still won't let me log in.

Hi Everyone,

 

I am having a similar issue to the above. I am running a custom br network for my containers. Now my deluge container is not showing any container IPs or port mappings. I have restarted, redownloaded the image etc. and no luck. When i change the network type to bridge everything works likes normal. When I chnage it back, issue returns. This is causing issues accessing the webUI. Any suggestions? Been using this container for awhile now with no issues and this just started.

 

 

Thanks.

On 7/3/2024 at 4:00 AM, binhex said:

OK so i haven't dealt with bonded NIC's before, i can only assume creating a bonded NIC for some reason hides the port mappings, or perhaps changes the network type from bridge to another type.

As for your question about the WebUI shortcut, you can set it by left clicking the container icon, going to edit, then toggle 'basic view' to advanced view (top right) then look for WebUI: and change the value to be http://[IP]:[PORT:8112] then click on apply at the bottom

I've been using a bonded NIC for the past year as well as this container for nearly the past year.  When Unraid 6.12.8 came out I applied the fix for macvlan traces which involves disabling bridging and enabling Host access to custom networks for Docker.  Everything has been fine and working as expected throughout the past year until the container update that I applied June 30th.  I login to these containers at least every week.

 

The webUI shortcut is already set, just checked what you mentioned and exactly what you have as the value is already there.  I tried erasing it and putting it back, no difference.

 

It's not a huge deal since the container itself is working, but I can't be the only one with this issue.  I assume it has to do with something in this container's config and using a custom network in Unraid, like it can't detect the IP even though I'm using a fixed IP on the container.

50 minutes ago, Vynlovanth said:

I applied the fix for macvlan traces which involves disabling bridging and enabling Host access to custom networks for Docker. 

OK firstly a disclaimer, there is a ton of different network types you can use in Docker, i do not know all of them, and special edge cases such as bonding i have no knowledge of, but I do know that a 'network type' of 'bridge' will allow you to perform port mapping, whereas running the container in 'network type' 'host' does not permit this as there is no bridge to translate the ports, so you 'disabling bridging and enabling Host access' could be the cause of the loss of visibility of the ports.

FYI - If you want to get up to speed with docker networking I would highly recommend watching an awesome video by Network Chuck, stick with it and concentrate, it starts off slow and easy and gets more in depth:- 

 

15 hours ago, craigr said:

Here is my FLOATING rule.  Could you not just put the IP of your client in regardless of vlan?  Not sure, just woke and am very foggy.

 

 

 

 

 

I tried with client IP but get blocked "Default deny / state violation" rule.  Thanks for sharing - this will help me sort out my opnsense rules. I will get to it later when I find time. It's just access to the WebUI that gets blocked.

On 4/21/2024 at 3:30 PM, socbutter said:

I forgot my web-gui password to binhex - DelugeVPN. I tried the following without success.

 

 

 I did not try the command-line since I don't know what I'm doing.

Any suggestion would be appreciated.

 

12 hours ago, Trenchguns said:

I've run into a weirdly similar issue, but after removing it and having it set back to the default it still won't let me log in.

EDIT:  Deluge must be stopped to edit the file!

 

You can also brows your appdata folder, go to binhex-delugevpn, and manually edit the core.conf file with a plain text editor if you prefer GUI to CLI.

Edited July 4, 20242 yr by craigr

4 hours ago, craigr said:

 

EDIT:  Deluge must be stopped to edit the file!

 

You can also brows your appdata folder, go to binhex-delugevpn, and manually edit the core.conf file with a plain text editor if you prefer GUI to CLI.

Thanks, edit really helped

Did something happen with the newest update. The prior update my PIA with wireguard works perfectly fine 0 issues. New update, I keep getting resolving DNS errors left and right, with 0 changes.