Port 32400 forwarded correctly, but can't connect remotely, baffled

Plex Media Server Remote Access
1

I’m having the strangest problem with port forwarding.

My firewall system is a FreeBSD server, and I use ipf for NAT and firewall duties. I’m pretty darn sure I know how to set up port forwarding on this system, having done it many times for other gadgets. For example I have a camera system recorder which I can access remotely on port 8000. This works fine, 100% of the time.

Yet the same kind of configuration to make my Ubuntu 20.04 PMS visible on port 32400 fails. https://canyouseeme.org/ confirms I have no connection. I am as sure as I can be that the configuration is correct both at the firewall and in PMS. If there is a config error it must be off the beaten path.

I know my way around BSD a bit but not much about the differences in Linux. Is there a mysterious Mess with BSD guys by randomly screwing up network connections = TRUE directive somewhere? Is there anything in Ubuntu which would make it treat WAN packets differently than LAN packets? I am completely stumped.

FWIW Plex’s own remote access detection may briefly show I am good to go, but CanYouSeeMe always shows a fail and a remote client always fails to connect.

An additional weird factor is remote access worked fine when my server was a Shield–more evidence that there’s nothing wrong with my port forwarding directives.

2

You could try some different port to rule out your ISP is selectively filtering some (e.g. 32400)

3

Check to see if Ubuntu’s firewall (UFW) is enabled:
sudo ufw status

If so, you may need to add a rule to allow TCP 32400.

Or, perhaps iptables is active:
sudo iptables -L

If you want to eliminate Plex from the equation entirely, stop the service and then run the following:
python3 -m http.server 32400

This will run a simple HTTP server which will respond to any requests on TCP 32400; be careful to do this in a directory with nothing important in it as the server will serve any file in that directory and will list it in a directory listing.

4

That is a good thought @tom80H , but I already ruled it out. I’m on business class internet which is supposed to have no such filters, and by the use of iftop on my firewall machine I can verify that the connection attempt is reaching me.

When I test the connection is “refused” (RST) and I need to figure out if the fault is at my firewall, or downstream at the Ubuntu box.

@pshanew thanks a ton, this is just the kind of thinking I needed.

ufw was on when I started looking at this stuff this morning, but I turned it off when I started testing, and I just verified it has remained off.

Here’s my iptables output… I don’t know this system at all but all those ACCEPTs look good.

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Great minds think alike; I didn’t do the python server, but I had installed Nginx (as I already knew it) and told it to listen on port 32400 while PMS was off. There was no difference when testing to see if anything was listening… no sign of life. I just tried the python http server too (cool trick!) and there was no difference with it.

Assuming that my iptables output looks kosher, the fault must lie with my port forwarding. On the one hand, cool, progress! On the other, why the heck isn’t it working?! So weird.

Thanks guys!

5

I create a firewall rule on my Ubuntu server and found this old post I created How to unblock Port 32400 - #4 by dokuro

Assuming your port forwarding is setup right on the router I’d give the above a go.

6

Those iptables rules look fine (they’re the default, allow everything rules). With UFW disabled, I don’t think that there’s anything else local to the system which would be blocking the traffic. You could always test by browsing to ip.address.of.server:32400 from another system on the same network to see if either nginx or the Python HTTP server respond. That would pretty much isolate the server from being the issue and definitively prove your firewall is causing the issue.

7

Thanks for that! Unfortunately it didn’t do the trick… it must be my port forwarding. Drat.

That’s a good tip though, I’ll check out that firewall system more once I have this problem figured out.

8

I did, and they did. LAN operations seem 100% good.

With Ubuntu and PMS both blameless… there must be a flaw in my ipf/ipnat rules. Drat.

9

MYSTERY SOLVED!

As I suspected, there was a truly dumb error in my configs!

Thanks for trying to help this moron… I did learn some cool stuff along the way, though!

10

Glad to hear you figured it out!