What's new

Solved UPNP/port forwarding not working on ax56u plex

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Wwweh

New Around Here
I’ve been trying to figure this out and it’s driving me crazy

I’ve recently installed plex on this router and it’s runs great locally - the only issue I’ve been having is I can’t get it exposed outside my network directly

I’ve got a static IPV4 from my ISP but when I try to port forward 32400 it doesn’t work!

I can expose the router webconfig just fine (port 8443) and I’ve checked the iptables for that vs mine and they’re exactly the same!
I’ve enabled logs and I can see the requests getting dropped

anyone had experience with this? How do I fix?

logs from the router:
Code:
Jul  3 20:16:55 kernel: DROP IN=eth0 OUT= MAC=a8::4f:d0:08:00 SRC=45.33.50.110 DST=192.168.50.1 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=13909 DF PROTO=TCP SPT=36128 DPT=32400 SEQ=672005233 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40402080AD7AFCA580000000001030307) MARK=0x8000000
“OUT=“ kinda looks suspicious?
 
Last edited:
I’ve been trying to figure this out and it’s driving me crazy

I’ve recently installed plex on this router and it’s runs great locally - the only issue I’ve been having is I can’t get it exposed outside my network directly

I’ve got a static IPV4 from my ISP but when I try to port forward 32400 it doesn’t work!

I can expose the router webconfig just fine (port 8443) and I’ve checked the iptables for that vs mine and they’re exactly the same!
I’ve enabled logs and I can see the requests getting dropped

anyone had experience with this? How do I fix?

logs from the router:
Code:
Jul  3 20:16:55 kernel: DROP IN=eth0 OUT= MAC=a8::4f:d0:08:00 SRC=45.33.50.110 DST=192.168.50.1 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=13909 DF PROTO=TCP SPT=36128 DPT=32400 SEQ=672005233 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40402080AD7AFCA580000000001030307) MARK=0x8000000
“OUT=“ kinda looks suspicious?
Not a good idea to expose anything on the router. A wonderful way to get hacked! Recommend turn off UPnP as it is a security risk and web access to the router, even from a secure port, is asking for trouble.

You will put your entire network to risk for music?
 
Not a good idea to expose anything on the router. A wonderful way to get hacked! Recommend turn off UPnP as it is a security risk and web access to the router, even from a secure port, is asking for trouble.

You will put your entire network to risk for music?
UPnP is no more of a security risk than the devices on the network. ASUS has never exposed UPnP to the WAN. If you trust the devices on your network then UPnP can be used with minimal risk.
 
Technically, you do NOT port forward when accessing a service hosted on the router. You just open the port. Port forwarding is only when the target is NOT the router, but elsewhere on the LAN.

I'm NOT even sure UPnP applies to the router (as mentioned above, I keep that service OFF for the same reasons).

Now in some cases, the firmware *might* let you port forward to the router (192.168.50.1 in this case) because the developers know users will make this mistake, and adjust accordingly (iirc, DD-WRT works this way). But that's NOT always the case. If they don't, then the firewall rule will be incorrect. It will NOT allow access to that port on the INPUT chain of the filter table (as it needs to be), but the FORWARD chain, because it expects the traffic to be routed from the WAN to LAN.

Using Merlin (I assume the OEM firmware will behave the same), I enabled remote access to the router's GUI and a port forward to the plex server on the router. The following is a dump of the VSERVER chain of the nat table.

Code:
Chain VSERVER (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8443 to:192.168.1.1:8443
2        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:32400 to:192.168.1.1:32400
3        0     0 VUPNP      all  --  *      *       0.0.0.0/0            0.0.0.0/0

Looks good so far. But a dump of the INPUT chain shows a problem.

Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        1    96 ACCEPT     all  --  eth0   *       192.168.61.0/24      0.0.0.0/0            state NEW
2        0     0 INPUT_PING  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
3     5155 1588K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
4        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
5    11181 2281K PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0           
6     1088  106K PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
7     1088  106K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
8        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
9        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
10       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.1          ctstate DNAT tcp dpt:8443
11       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
12       0     0 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
13   11181 2281K OVPNSI     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
14   11181 2281K OVPNCI     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
15   11181 2281K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Notice in line #10, *only* port 8443 is being allowed remote access over the WAN, NOT port 32400! And that's because as part of enabling remote access to the GUI, the router does NOT use port forwarding, but just opens that port separately. If you use the port forwarding feature of the GUI for plex, access to the router remains BLOCKED unless YOU do likewise and explicitly open it.

I suppose it's possible the plex service might be opening this port by itself, and it's some other issue. But you'd have to dump the firewall to verify.

Code:
iptables -t nat -vnL
iptables -vnL INPUT
iptables -vnL FORWARD
 
Last edited:
You absolute hero!!! That makes an incredible about of sense!

I dumped the iptables as you suggested and found another command relating to the 8443 that didn't match up with the 32400.

In the end I disabled port forwarding and now manually expose the port using the info from the iptables dump. Plex is now exposed to the WAN and works perfectly. Thank you so much!

For those curious:

Code:
iptables -I INPUT 1 -d 192.168.50.1/32 -p tcp -m conntrack --ctstate DNAT -m tcp --dport 32400 -j ACCEPT
iptables -t nat -A VSERVER -p tcp -m tcp --dport 32400 -j DNAT --to-destination 192.168.50.1:32400
 
And that's because as part of enabling remote access to the GUI, the router does NOT use port forwarding, but just opens that port separately.
This is incorrect. If you look again you can see that it is using port forwarding (DNAT) from the WAN interface to the LAN interface (VSERVER). The difference is that's there's no corresponding ACCEPT in the INPUT chain for this DNAT'ed traffic, unlike the FORWARD chain where all DNAT'ed traffic is accepted.

So the solution is to either add an explicit rule for the DNAT'ed traffic in the INPUT chain. Or remove the port forwarding altogether and insert a rule that accepts traffic from the WAN interface (assuming Plex is also listening on that interface).
 
Last edited:
This is incorrect. If you look again you can see that it is using port forwarding (DNAT) from the WAN interface to the LAN interface (VSERVER). The difference is that's there's no corresponding ACCEPT in the INPUT chain for this DNAT'ed traffic, unlike the FORWARD chain where all DNAT'ed traffic is accepted.

So the solution is to either add an explicit rule for the DNAT'ed traffic in the INPUT chain. Or remove the port forwarding altogether and insert a rule that accepts traffic from the WAN interface (assuming Plex is also listening on that interface).

We're getting into semantics here.

I was aware of the *redirect* that's the first part of port forwarding. But because this is NOT a case of port forwarding (if it was, it would have worked), the second phase never takes place, namely, the need to have that redirection processed through the INPUT chain. Instead, port forwarding assume the target will be a different device and processed through the CNAT of the FORWARD chain.

That's why I don't technically consider this port forwarding (at least not from the perspective of the GUI). The redirect alone does NOT fully define a port forward.

Other than that, I agree w/ your proposed solutions. But I never got that far in the discussion w/ the OP. They had already chosen a solution before I could offer my own (I had already typed it out, but didn't want to overload the OP w/ that information until the OP responded and confirmed).
 
Last edited:
FYI. Here's what I had planned to say (it might still be useful).

To add to the confusion, there's another issue here.

The reason remote access to the router's GUI *looks* like a port forward in iptables, at least in the sense there is a redirect from port 8443 on the WAN to port 8443 on the LAN in the VSERVER chain, is because the GUI *only* listens on the LAN network interface. Once the redirect takes place, then the CNAT rule for port 8443 in the INPUT chain finally allows the access, but on the LAN side.

I presume it's done this way for security reasons. There's no chance of accidentally exposing the GUI without taking explicit steps to redirect that access from the WAN to the LAN of the router.

When it comes to the plex server, I have no idea which network interface(s) it's listening on. Obviously if it's available on the LAN, minimally that includes 192.168.50.1. But for the WAN or any other network interfaces, you'll have to check the plex config file. Many times these things default to ALL. If that's the case, then you can just open port 32400 of the WAN in the INPUT chain of the filter table. If NOT, then you either change the config file to ALL, or do like the GUI above.


Again, I just never got the opportunity to say/post it.
 
We're getting into semantics here.
Yes I agree it's just a matter of semantics. Is traffic redirected from one interface to another considered "forwarded" even if it doesn't traverse the FORWARD chain </rhetorical>? As far as the Asus GUI is concerned everything in the VSERVER chain (including remote web access) is listed under "System Log - Port Forwarding".
 
Is traffic redirected from one interface to another considered "forwarded" even if it doesn't traverse the FORWARD chain </rhetorical>?

I'll respond anyway :)

NOT in my book, and more importantly, not the GUI. That's why it didn't work. Port forwarding means processed through the FORWARD chain.

Now that's NOT to say the router couldn't support the OP's requirements by doing what DD-WRT does. It detects a reference to the router's IP and uses the INPUT chain. So many ppl make the mistake of assuming you can port forward to the router, they decided to have the GUI's port forwarding make the adjustment. Just less hassle for users. And maybe @RMerlin should consider the same.

If the GUI did work that way, I'd far more inclined to accept calling all of it "port forwarding", since the change in implementation would effectively redefine the term.
 
Last edited:
+1 for that mimicking what DD-wrt does, I would much rather have this handled within the UI than user scripts
 
OK Playing devil's advocate here... For successful port forwarding from the internet to a client requires two things, 1) the WAN traffic to be redirected to the client, and 2) the firewall on that client to accept the traffic. When thinking about it from a "normal" LAN client perspective the "port forwarding" part only refers to the redirect phase. The second, firewall phase is independent of the port forwarding.

So if we now compare that to what's happening when you setup forwarding to router itself. Is it not fair to say that the port forwarding has worked because the traffic has successfully arrived on the router's LAN interface. But now you need to allow the traffic thorough the router's firewall just the same as you would do for a Windows/Mac/Linux server on the LAN.
 
OK Playing devil's advocate here... For successful port forwarding from the internet to a client requires two things, 1) the WAN traffic to be redirected to the client, and 2) the firewall on that client to accept the traffic. When thinking about it from a "normal" LAN client perspective the "port forwarding" part only refers to the redirect phase. The second, firewall phase is independent of the port forwarding.

So if we now compare that to what's happening when you setup forwarding to router itself. Is it not fair to say that the port forwarding has worked because the traffic has successfully arrived on the router's LAN interface. But now you need to allow the traffic thorough the router's firewall just the same as you would do for a Windows/Mac/Linux server on the LAN.

Again, we're getting into semantics here (e.g., the LAN client's perspective vs. the router's).

The problem here is a misunderstanding of what a port forward actually is, at least based on the most common implementation, which assumes the target is a *different* IP from the router.

Clearly based on the implementation, a redirect to the router is NOT considered a port forward. But as I suggested, if the implementation was changed to detect the reference to the router's IP and use the INPUT chain, THEN I'd be willing to call it port forwarding, since the change in implementation would effectively redefine the term, at least for this particular firmware. But I suspect this would be the exception, not the norm, for most other firmware.

I think we're losing sight of the more important issue here. Should the firmware be changed to do like DD-WRT and process any reference to the router's IP through the INPUT chain?
 
P.S. If you want to claim it should have used the INPUT chain, IOW, it's a *bug*, THEN I'd be willing to agree it's port forwarding. But given the current implementation is so common, and has been since I can remember, I doubt the developer would see it that way, but more likely as an enhancement.
 
Out of curiosity, I took a look at FT (FreshTomato), and they do NOT allow port forwarding to the router either.

NAT Table
Code:
Chain PREROUTING (policy ACCEPT 15 packets, 3511 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        1    60 WANPREROUTING  all  --  *      *       0.0.0.0/0            192.168.63.104      

Chain WANPREROUTING (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 DNAT       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            to:192.168.1.1
2        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:32400 to:192.168.1.1:32400

Filter Table
Code:
Chain INPUT (policy DROP 422 packets, 86088 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        1    60 ACCEPT     all  --  vlan2  *       192.168.61.0/24      0.0.0.0/0            state NEW
2        0     0 DROP       all  --  br0    *       0.0.0.0/0            192.168.63.104      
3        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
4      243 18461 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
5        0     0 wwwlimit   tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 state NEW
6        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
7        0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
8        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 state NEW,RELATED,ESTABLISHED
9        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 30 state NEW,RELATED,ESTABLISHED
10       0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:33434:33534
11       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
12       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 DROP       all  --  *      vlan2   0.0.0.0/0            10.0.0.0/8           state NEW
2        0     0 DROP       all  --  *      vlan2   0.0.0.0/0            172.16.0.0/12        state NEW
3        0     0 DROP       all  --  *      vlan2   0.0.0.0/0            192.168.0.0/16       state NEW
4        0     0 ACCEPT     all  --  vlan2  *       192.168.61.0/24      0.0.0.0/0            state NEW
5        0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0           
6        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
7        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
8        0     0 wanin      all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0           
9        0     0 wanout     all  --  *      vlan2   0.0.0.0/0            0.0.0.0/0           
10       0     0 wanin      all  --  vlan3  *       0.0.0.0/0            0.0.0.0/0           
11       0     0 wanout     all  --  *      vlan3   0.0.0.0/0            0.0.0.0/0           
12       0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0         

Chain wanin (2 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.1          tcp dpt:32400

While the redirect in the WANPREROUTING chain of the nat table is as expected, further access is allowed via an FT-specific chain called wanin. But the wanin chain is only referenced in the FORWARD chain, NOT the INPUT.

That's why I say, this is NOT common. DD-WRT added the capability quite some years ago, making it an exception.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top