Webui always exposed to public IP

[inertia666]

I recently found out my Webui has been exposed on the public ip address of the vpn.

As a failsafe, I set the network interface in the advanced settings to tun0. I am not sure if this is the reason for the exposure or something else.

No matter what IP with subnet i put into the ip address under "web user interface", the webui is always accessible on the public ip address.

I have moved the port to get it off 8080 but the webui is not accessible on the LAN unless I add the port numer to the additional ports variable in Docker. Adding it just exposes the webui again.

I am on 4.5.2 and the latest docker images as of today.

[DyonR]

Sounds like more a VPN Provider problem to me. I can't imagine a VPN provider just opening all ports, especially since IPs are shared.
Did you for example test to connect to the qBittorrent Web UI via your phone data? Making sure you aren't connected to your home connect.

[inertia666]

Ah now you mention it, the vpn provides a unique IP with all ports forwarded for these kind of services. I will see if it works using the port forwarding vpns.

[inertia666]

I have done a few tests. If change the host address from my vpn provider it puts me on a shared ip but then no ports are open. 8080 is not reachable but a port scan shows the connection listening port is not open , so I think it will not connect to any peers.

When I add the "connection listening port" to the variable "additional ports" in the docker config then it seems to connect me to a totally different IP range with the listening port open and 8080 open. No other ports are open. I am not really familar with iptables or openvpn other than on a superficial level, but somehow their gateway knows to send me to a different server that will allow ports to be opened.

It looks to me that once I am on this server the iptables is exposing 8080 and the listening port, but i only want the listening port open.

The other thing is, adding 192.168.0.0/24 into the "web user interface ip address" does not help to only whitelist lan connections. I can still connect from my mobile phone and log into the webui on a non LAN ip. This shouldn't be the fault of the container though? Also, adding an https certicate and key works until reboot and then the changes are lost. Maybe this is a qbt bug.

The qbt wiki does not seem to document these settings either.

[inertia666]

I tested the haugene transmission container and it works as expected. The listening port is open and the webgui port is closed on the public ip but accessible from the LAN

Looking closely, it contains a script that requests a port opening from the providers api. I think i would need to migrate this script and rebuild your image to run it.

I am unsure why this script is needed though but I noticed it uses the same IP range as when i run your container without the "additional ports" flag and opens the port.

Running your container must somehow trigger their "all ports forwarded" server from the gateway when "additional ips" is used. I guess the script queries their api to randomly open a port and then send the result of this so that iptables can add it to its rule set.

[DyonR]

I still find it hard to believe that you would be able to access the WebUI from the Public IP.
No where in the code of this project it would make request to the api of the vpn provider. Are you sure the .ovpn config is fine?

The iptables.sh script that runs within this container literally only allows access for the port 8080 on the Docker Interface:

docker-qbittorrentvpn/qbittorrent/iptables.sh

Lines 111 to 113 in 0f22470

	# accept input to qBittorrent webui port
	iptables -A INPUT -i "${docker_interface}" -p tcp --dport 8080 -j ACCEPT
	iptables -A INPUT -i "${docker_interface}" -p tcp --sport 8080 -j ACCEPT

docker-qbittorrentvpn/qbittorrent/iptables.sh

Lines 165 to 167 in 0f22470

	# accept output from qBittorrent webui port - used for lan access
	iptables -A OUTPUT -o "${docker_interface}" -p tcp --dport 8080 -j ACCEPT
	iptables -A OUTPUT -o "${docker_interface}" -p tcp --sport 8080 -j ACCEPT

Together, these rules allow incoming and outgoing traffic on port 8080 for the Docker interface.

This is the part of the script responsible for the additional ports:

docker-qbittorrentvpn/qbittorrent/iptables.sh

Lines 115 to 132 in 0f22470

	# additional port list for scripts or container linking
	if [[ ! -z "${ADDITIONAL_PORTS}" ]]; then
	# split comma separated string into list from ADDITIONAL_PORTS env variable
	IFS=',' read -ra additional_port_list <<< "${ADDITIONAL_PORTS}"
	# process additional ports in the list
	for additional_port_item in "${additional_port_list[@]}"; do
	# strip whitespace from start and end of additional_port_item
	additional_port_item=$(echo "${additional_port_item}" | sed -e 's~^[ \t]*~~;s~[ \t]*$~~')
	echo "[INFO] Adding additional incoming port ${additional_port_item} for ${docker_interface}" | ts '%Y-%m-%d %H:%M:%.S'
	# accept input to additional port for "${docker_interface}"
	iptables -A INPUT -i "${docker_interface}" -p tcp --dport "${additional_port_item}" -j ACCEPT
	iptables -A INPUT -i "${docker_interface}" -p tcp --sport "${additional_port_item}" -j ACCEPT
	done
	fi

But in there, there is nothing odd naturally, just allowing incoming and outgoing traffic on the ports you specified

[inertia666]

We can close this issue. The provider gives you an "all ports open" server for torrenting so you don't need extra scripts to request a single port to be opened. This is a problem though because it forwards the webgui port at the same time regardless of how iptables is setup. I don't know how or why it does it as I do not have much competence with iptables.

The Haugene container I use contains a script for my provider's closed port servers but is able to open just the QBT listening port through their api service. Since your container doesn't use this kind of script it won't work properly with my provider.

I don't know how other providers work with this container but there seems to be a reason other containers use a lot of provider specific scripts other than for the convenience of just grabbing an appropriate vpn config.