ANSWERED Connection refused (111) when all signs point to it being open

[Loadstone 0]

Hello, 

I've read through many many forum posts and tried to implement all the solutions I could find but it's beginning to feel like I might be out of luck with this problem. I have all 5 of my available ports open and only 1 of them is actually functioning. I'm trying to make a couple of things work with these ports but I'll use the docker apps as an example since they give the most information up front in Docker Desktop:

- .yml files ALL show that every port the container is using is open to ALL interfaces (80:80, 443:443, 81:81 for nginx) (5055:5055 for Overseerr) etc. 
- Using command prompt and powershell I used 

netstat -tuln | grep 5055 

to check the port, and it responded as listening with 

tcp6       0      0 :::5055                 :::*                    LISTEN

- used both 

nc -vz 10.183.158.119 5055 

and the same line using my LAN IP. With this method I find that when it's run from the same device that the apps are on, they show as open and listening (both IPs), but from any other device, they don't. 
- I've used iptables to find out if there are any rules preventing this connection from passing through, and there aren't
- I used the netsh commands to add rules explicitly allowing connections through these apps, still nothing. 
- I use ip route, ifconfig, and any command I could to gather as much information as I could, PIDs, docker compose info, network adapters, pinging, I feel like whatever anyone names, I've tried. 

These were all run with the containers open, restarted, ports tested at every turn, active listening for connections, but it's actually as if my computer is a prison and this VPN does not allow anything through it no matter what. I have tried to use the "test open" on the port page throughout all of this and made sure all the settings are right, I've changed port numbers, it just. won't. work. Someone please help. My logs don't show anything at all over the course of the whole day working on this. Not a single event recorded. I was hoping to set up an overseerr reverse proxy today but that's just not going to happen now and I'm starting to doubt if it's even possible. Of the threads I've found on this topic there are multiple that were ended by the authors because they figured out their stupid mistake, which is frustrating but I hope I can get around this that easily. 

[Staff 10114]

@Loadstone

Hello!

What is the value of the FIREWALL_VPN_INPUT_PORTS GlueTun environment variable? Does the problem persist or disappear if you operate directly on your host, without virtual environments?

Kind regards
 

[Loadstone 0]

Thank you so much for the quick response. 

I didn't have gluetun installed at all so I just went through that process. I believe I have it up and running correctly now, but have run into basically the same issue with reaching the app. Now it just connects to gluetun and shows as listening on the correct port, and I made exceptions in gluetun for it on top of that, but still, no external connections. It's like I can only add a layer between the apps and external connections, and never penetrate a single one. The value for the FIREWALL_VPN_INPUT_PORTS is empty, the lines in that section when inspecting on portainer look like this:

"PORT_FORWARD_ONLY=",
"FIREWALL_ENABLED_DISABLING_IT_SHOOTS_YOU_IN_YOUR_FOOT=on",
"FIREWALL_VPN_INPUT_PORTS=",
"FIREWALL_INPUT_PORTS=",
"FIREWALL_OUTBOUND_SUBNETS=",
"FIREWALL_DEBUG=off",

Should there be a specific number there? I was under the impression that that blank in the value defaulted to an actual number. Just so you have more info on the gluetun process I've gone through, I made sure that the app's settings.json network was going through gluetun, and was using ifconfig for the ip on the docker. Also when you ask about the problem persisting on my host, do you mean like if I were to install overseerr on my host pc, or if I wasn't using gluetun? The initial post was everything attempted without gluetun. But as I mentioned, there is an app that's able to work through this, Plex on its default port 32400. It can be accessed locally and externally. I'm just terrified of touching it because I feel like if it goes down I'm never getting it back. 

Edit: I'm coming back to this to ask if gluetun is necessary at all if I'm fine with the VPN affecting all of my traffic on the host device? I disabled it for now and will just keep trying out solutions. Edited ... by Loadstone
added info

[Staff 10114]

15 hours ago, Loadstone said:

The value for the FIREWALL_VPN_INPUT_PORTS is empty

Hello!

Since the firewall is enabled the FIREWALL_VPN_INPUT_PORTS environment variable must be set to the proper ports (in case of multiple ports, separate their values with a comma ",") in any Docker container where appropriate. The firewall blocks any unsolicited incoming packet to any port whose value is not contained in the mentioned variable.
 

15 hours ago, Loadstone said:

Also when you ask about the problem persisting on my host, do you mean like if I were to install overseerr on my host pc, or if I wasn't using gluetun? The initial post was everything attempted without gluetun

We meant to test without any container, without any virtual environment. The initial post clearly states that the tests "were all run with the containers open, restarted, ports tested at every turn, active listening for connections", so we assumed that they were run in some Docker container. Sorry for having assumed specifically GlueTun, anyway the suggestion remains valid (FIREWALL_VPN_INPUT_PORTS is a Docker environment variable).
 

15 hours ago, Loadstone said:

ask if gluetun is necessary at all if I'm fine with the VPN affecting all of my traffic on the host device

According to your needs any virtualization seems unnecessary indeed.

Kind regards