What's new

miniupnpd configuration: internal/external ports reversed?

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

reerden

Regular Contributor
I've noticed something strange about the generated miniupnpd config. By default the router allows ports in the range 1024-65535 internally and 1-65535 externally. However, using these values it generates the following allow rule:

Code:
allow 1024-65535 192.168.1.1/255.255.255.0 1-65535

This contradicts miniupnp's documentation, which states the syntax is:

Code:
# UPnP permission rules
# (allow|deny) (external port range) IP/mask (internal port range)

Is this a mistake on Asus part, or am I missing something?

EDIT: added more descriptive title.
 
Last edited:
might explain the weird nat issues i have with gta v, mw 3 specops on pc, and my steam links odd port issue.
The port number ranges are in reverse lol.
 
UPNP doesn't work for me for quite a while, but I got VDSL2 changed for FTTH and I'm unsure if firmware is broken or something changed on my connection. For example, if I enable UPNP in eMule, it fails to use it every single time like it can't set it up even though it's correctly enabled on router. So I have to manually set port forwarding on router which is super annoying and clumsy.
 
I'm hoping someone can shed some light on this. I'm not even sure how you would test UPnp in the first place.
 
UPNP doesn't work for me for quite a while, but I got VDSL2 changed for FTTH and I'm unsure if firmware is broken or something changed on my connection. For example, if I enable UPNP in eMule, it fails to use it every single time like it can't set it up even though it's correctly enabled on router. So I have to manually set port forwarding on router which is super annoying and clumsy.

This issue might be unrelated. Try disabling NAT acceleration, as that doesn't work properly with UPnP on certain models.
 
wh
UPNP doesn't work for me for quite a while, but I got VDSL2 changed for FTTH and I'm unsure if firmware is broken or something changed on my connection. For example, if I enable UPNP in eMule, it fails to use it every single time like it can't set it up even though it's correctly enabled on router. So I have to manually set port forwarding on router which is super annoying and clumsy.
which firmware, and router model 380.66 should have better upnp.
 
I'm hoping someone can shed some light on this. I'm not even sure how you would test UPnp in the first place.
depnds, on what your asking for theres a whole thread about upnp and xbox one, from what i can see the out put shows the allow range is reverses, basically external start port is 1024 internal is 1, hmmm, maybe if merlin might know more.
 
w
I've noticed something strange about the generated miniupnpd config. By default the router allows ports in the range 1024-65535 internally and 1-65535 externally. However, using these values it generates the following allow rule:

Code:
allow 1024-65535 192.168.1.1/255.255.255.0 1-65535

This contradicts miniupnp's documentation, which states the syntax is:

Code:
# UPnP permission rules
# (allow|deny) (external port range) IP/mask (internal port range)

Is this a mistake on Asus part, or am I missing something?
which model router and firmware
 
depnds, on what your asking for theres a whole thread about upnp and xbox one, from what i can see the out put shows the allow range is reverses, basically external start port is 1024 internal is 1, hmmm, maybe if merlin might know more.

The whole reason the first 1024 ports are disallowed internally is to prevent known services from being mapped. Having this reversed removes that extra bit of security.

which model router and firmware

AC66U, 380.66_6
 
b
The whole reason the first 1024 ports are disallowed internally is to prevent known services from being mapped. Having this reversed removes that extra bit of security.



AC66U, 380.66_6
ut id the syntax is wrong then we lose the security and internal is open but external is closed, im hoping its fixed so the ranges are corrected to the syntax. The out put in your first post indicates that it has been reversed and needs to be corected so it correlates with the spec, therefore preventing issues.
 
b

ut id the syntax is wrong then we lose the security and internal is open but external is closed, im hoping its fixed so the ranges are corrected to the syntax. The out put in your first post indicates that it has been reversed and needs to be corected so it correlates with the spec, therefore preventing issues.

It adds only minor security as the client still has to request the port to be opened in the first place (and no sane system would do that). But it's an extra layer nonetheless. For now I've just set both ranges to 1024. This used to be the default anyway (and the recommended setting by the miniupnp dev). Not sure why Asus changed that, as most applications request the same port internally as well as externally.
 
It adds only minor security as the client still has to request the port to be opened in the first place (and no sane system would do that). But it's an extra layer nonetheless. For now I've just set both ranges to 1024. This used to be the default anyway (and the recommended setting by the miniupnp dev). Not sure why Asus changed that, as most applications request the same port internally as well as externally.

Still it would be nice to have it fixed i do see a potential for issues if its not fixed.
Although i dont understand why the port is set to 1 if 1024, is the propper setting for starting port, though i did read that external ports were fine being set to 1 on starting port but only on external.

Upnp has been weird for me in genral, though i have games using a port number but they show up as moderate nat though upnp has the port forwarded or the port number doesnt even show up and i get mod nat its flakey to say the least.
At the moment its causing my steam link to have network test issues.

I think that the port being set to one is for things like xbox live but the xboxes i have never used the lower end ports, im not that worried about security since my 88u has ai protection and i have all of it enabled.

But i still dont understand why its not following the correct syntax that has me worried still that it there would be a possible issue with the firewall.
I do hope merlin can correct this issue.
 
Last edited:
It seems Asus contradicts itself here:

https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/shared/defaults.c#L2131
Code:
    {"upnp_min_port_int", "1024" },
    {"upnp_max_port_int", "65535" },
    {"upnp_min_port_ext", "1" },
    {"upnp_max_port_ext", "65535" },
    {"mfp_ip_monopoly", "" },


https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/rc/services.c#L3422
Code:
                int ports[4];
                if ((ports[0] = nvram_get_int("upnp_min_port_int")) > 0 &&
                    (ports[1] = nvram_get_int("upnp_max_port_int")) > 0 &&
                    (ports[2] = nvram_get_int("upnp_min_port_ext")) > 0 &&
                    (ports[3] = nvram_get_int("upnp_max_port_ext")) > 0) {
                    fprintf(f,
                        "allow %d-%d %s/%s %d-%d\n",
                        ports[0], ports[1],
                        lanip, lanmask,
                        ports[2], ports[3]
                    );
                }
                else {
                    // by default allow only redirection of ports above 1024
                    fprintf(f, "allow 1024-65535 %s/%s 1024-65535\n", lanip, lanmask);
                }

I'm pretty sure someone accidentally switched the values around. Not very hard to make that mistake if you put everything inside the same array.
 
As you can see, it's an easy fix.

It looks like it's been that way 'forever', at least back to my fork 374 level. Somebody probably assumed it followed normal convention, where port definitions follow the ip address, not before like the miniupnpd syntax.
 
It looks like it's been that way 'forever'

"forever" is an accurate term, since Tomato itself also has the same argument order (and Asuswrt was forked from Tomato back in 2010)...

I'll double check the miniupnpd sources before making any change, in case the documentation was wrong.
 
The source code does confirm what the documentation states indeed. Proper argument order is external, IP, internal.
 

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