What's new

Asus RT-AC68U -> uPnP Issues?

  • 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!

shiggypoo

New Around Here
Hello All,

Proud new owner here of an Asus RT-AC68U wireless router and so far am loving the performance of this thing! I do however wonder if anybody has had any woes on stock firmware with the uPnP features? I'm running into two separate issues here...

1) I run Edovia's Screens Connect software for remotely logging into my iMac via iOS devices, and it keeps telling me that the router is mapping the public port to 5900 and that it could cause errors. Thankfully I'm still able to remote-in just fine both on the LAN and while away from my LAN. However, I never received this error before on my old D-Link DIR-827. Edovia's tech support have also alluded to the fact that it sounds like the router is not properly utilizing uPnP as port 5900 should be used as a last resort method by the router.

2) I have a QNAP TurboNAS TS-121 which features a cloud-based DDNS service called MyQNAPCloud. When I configure the DDNS service on the NAS and request for it to 'request' to open all required ports on my router, it gives me groups of ports that are not properly able to be forwarded via uPnP on the router. Those ports are TCP 20, 21, 22 and UDP ports 873 & 8899. All other ports get the green light from the NAS. When I check in my RT-AC68U settings, it does in fact appear that all other ports were correctly forwarded and that the router has not opened up those ports for unknown reasons. Lastly, my old DIR-827 had no issues again in opening all of these ports via uPnP with no forwarding required.

I am just after returning a Netgear R7000 for the above issues, but that router caused my NAS to completely lock up when trying to handshake the uPnP settings and gave me a slew of other grief (Screens Connect didn't work at all and none of the NAS ports would open after rebooting from locking up)

The Asus is almost on the home stretch, if I could only wrap my head around what is going on here...
 
Are by any chance you using a VPN? If you are they sometimes assign a random port to be forwarded.
 
Nope, no VPN at all. The only ports that the RT-AC68U is showing as being open in the System Log are the ones my NAS was successful in opening, port 5900 from my iMac, and ports 9304/9308 for my PS4 Remote Play/PSN functionality. All of those were successfully opened via UPnP.
 
Regarding the QNAP: Ports 20, 21, 22 are a special case. Because the router can run it's own servers on those ports (FTP and SSH) you have to tell the router that you want them to be forwarded to your LAN instead. There's some comments to that effect in the GUI.

The Screens Connect FAQ says it tries to use ports 22, 80, 443 all of which are potentially used as described above. See the section "Tomato Firmware" at http://edovia.com/faq/supported-router-devices-for-screens-connect

You can't have 3 different servers all trying to use the same ports!
 
Last edited:
Hmm, I wondered if the Asus servers might be what is causing me grief but they are completely disabled by the looks of things. To be certain, I tried forwarding ports 20, 21, 22, 873 and 8899 to the NAS but it's still reporting that they've failed in the NAS settings. Albeit, this is for the UPnP config in the GUI so it may just be telling me that those ports are failing the UPnP handshake... Unfortunately I can't still remote in to the NAS via the MyQNAPCloud service though so something, somewhere, is still causing conflict...

As well, the strangest thing just happened -- Once I reset my port forwarding settings on the Asus, I checked again in Screens Connect on my Mac and it's now working totally fine. The Asus has let my Mac's local ports 22 and 5900 be mapped to completely random ports on my WAN instead of the same public and local ports. Go figure!
 
Ports below 1024 cannot be forwarded through uPnP by default. You have to allow it, on the WAN page.
 
Hi Merlin, would you be able to confirm if this can be achieved using the stock firmware (I should have mentioned I am on stock firmware, latest revision) or is that an option only found on your AsusWRT-Merlin firmware? I've searched high and low in the WAN configuration section and cannot find the option.
 
I don't know about stock, but on Merlin it's at WAN > Internet Connection > Basic Config > UPNP: Allowed internal port range
 
Ah that explains it - The stock Asus firmware does not appear to have this option. I've been thinking about trying Merlin's firmware and it sounds like I might be able to overcome these obstacles, so I'll put that on my weekend to-do list and let you know how I make out. Thanks to all so far for the input!
 
With stock firmware you have to manually set the nvram variables. Run the following over SSH:

Code:
nvram set upnp_min_port_int=1
nvram set upnp_min_port_ext=1
nvram commit
reboot
 
Mission accomplished thanks to your firmware, Merlin. Rather than use Telnet to make the adjustments, I decided instead to make the switch to your firmware to do it as well as for all of the other added benefits. By allowing all ports to be opened with uPnP my NAS is successful in opening all ports (even the FTP ports) and remote administration seems to be working OK again. As well, there no longer seems to be any confusion with Edovia's Screens application as it's giving me the green light with port forwarding as well.

Thanks again!
 
Mission accomplished thanks to your firmware, Merlin. Rather than use Telnet to make the adjustments, I decided instead to make the switch to your firmware to do it as well as for all of the other added benefits. By allowing all ports to be opened with uPnP my NAS is successful in opening all ports (even the FTP ports) and remote administration seems to be working OK again. As well, there no longer seems to be any confusion with Edovia's Screens application as it's giving me the green light with port forwarding as well.

Thanks again!
With stock firmware you have to manually set the nvram variables. Run the following over SSH:

Code:
nvram set upnp_min_port_int=1
nvram set upnp_min_port_ext=1
nvram commit
reboot


Sorry to re-hash an old post from March this year...I have the same model device RTAC68U and I've gone from latest Asus OFW to the latest stable version of merlin's. I have relevant ports ALL forwarded as per the myQNAPcloud suggestions for my NAS (as it appears my problem is identical to that of OP here).

UPNP and NAT are enabled; i've also changed to allow internal and external port range down to 1 and saved the new settings and rebooted...but I still cannot access my DDNS public service "abcd.myqnapcloud.com" and there is no logical explanation as to why there is still a refusal to allow external access...

Anyone help?
 

Similar threads

Sign Up For SNBForums Daily Digest

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