I’m having persistent problems with remote access to a server behind double NAT. My ISP provides a NATed connection, and I use a TP-Link Archer AX50 as my router behind that. However, I’ve configured my ISP’s modem to “DMZ mode”, so that all incoming connections are forwarded to the TP-Link, and the TP-Link has uPNP support enabled. This uPNP functionality is good enough that other clients on the internal network can accept incoming connections just fine, for instance, a torrent client works fine.
However, when I try to enable remote access to my Plex server (running on a Raspberry Pi 4 with Linux) it grinds for a while with “Connecting server”, then says “Fully accessible outside your network” for anything from a couple of seconds to a full minute, then changes to a red “Not available outside your network”. This happens regardless of whether I use uPnP or manually set up a port forward. If I use uPnP, I can see in the router configuration that the uPnP-requested port forwards do indeed get added, but it still says my server is not available outside my network, and indeed, trying to connect to that port from the outside, using either a Plex player or any other tool, does not work.
What I’m confused about here is that other programs do indeed get working inbound connections, using uPnP, and I can’t see any difference in the forwards, and either way, a manual forward should work no matter what.
Any ideas what might be causing this, or how to debug in more detail?
The documentation states that as long as both devices do port forwarding, remote access should work through double NAT:
" * You can try to set up a port forward in the service provider’s modem/router (in addition to your own). The process is similar to what was outlined earlier, except that you’re using your router’s WAN/Internet/External IP address where you would otherwise enter the local IP address. (See above for information about port forwarding.)"
This seems to be my case, given the DMZ mode on the modem, and the port forwarding on the TP-Link, so as far as I can tell, it should work.
Turn remote access off.
Manually set your port forwards on each router for port 32400.
Find out what your public IP address is on the ISP side.
Set “Custom server access URL” to https://yourlocalip:32400,https://yourpublicip:32400
Activating the DMZ mode is a bad idea, no matter the circumstances.
The fact that your ISP is performing NAT does not mean that they are also performing port forwarding for you.
Do you know for sure that they provide port forwarding? If they did, they would provide you with the port number(s) which is forwarded to your home.
You might have already covered this… but what about your server’s own firewall? Is that active?
If using Ubuntu, the utility “ufw” can give you the status of that.
The firewall would probably not show any moments of connectivity if it was the culprit. And, I found that the PMS installer did a good job of poking the right hole in the firewall. But, investigating it is a good idea.
(ufw is terrible, it’s a layer on top of iptables and it’s all too easy to get the systems into a situation where they fight and ufw rules are not executed as you would expect… for this kind of troubleshooting I would disable ufw and work with iptables directly.)
Why is DMZ mode a bad idea, when I’m using it to forward all ports to a second router/firewall? AFAIK that’s exactly what it’s supposed to be used for.
Ask them to change you to “bridge” mode, which should end NAT and give you a public IP. They are probably going to warn you that it might disable their firewall and wireless. If you have that on your router and have access points inside your network, you do not need that.
Some ISP’s block certain ports even if you get public IP. For example, one provider here keeps some ports blocked unless you have a static IP account with them.
And yes, I know, UFW is a front end for iptables. But it’s far easier to use than iptables.
Personally, I like the firewall that comes with BSD unix (FreeBSD & such). I’d actually rather use FreeBSD, I’ve always liked it, but the rest of the world decided it likes Linux better, so, when in Rome…
