miniupnpd outdated, doesn't work when WAN is a private address.

[iMoc]

Because the patch was rejected by the miniupnpd author.

[Face with Tears of Joy]Ah my bad, didn't notice it's a closed PR not a closed issue.

 

[iMoc]

What's the use of GetExternalIPAddress anyway, can't think one, DDNS?

 

[RMerlin]

Ah sounds unnecessarily added complexity, what is this author thinking[Face Holding Back Tears emoji]

In his defense, he's trying to follow the UPNP/IGD official specs as closely as possible. The IGD functionality requires the public WAN IP to be used - that is something separate from the UPNP functions of forwarding ports, which does not require it.

 

[Yota]

That patch is from 2020. Asuswrt-Merlin's miniupnpd isn't outdated, it was updated to 2.3.0 back this spring.

It's a complicated story. When the miniupnpd author decided a few years ago to disable miniupnpd whenever using a private WAN IP and adding a stun client inside miniupnpd to retrieve the public IP instead, I disagreed with the whole idea (we had a discussion about it on the miniupnpd github repo). Adding a stun client only for that specific purpose was feature bloat IMHO, and adding another moving part that could break at any time if any built-in stun server went offline, or an ISP decided to block access to that particular server. So at the time, my solution was to revert the whole change, and fully allow private WAN IPs once again.

A few years later, these patches became a major PITA for me to maintain, because every time I needed to upgrade to a new miniupnd version, I had to manually reapply these patches. So I eventually gave up, reverted them, and went with the next best thing: rely on Asuswrt's own built in stun lookup that it had then. This is what's normally stored in the wan0_realip nvram.

The actual problem in your case doesn't seem to be miniupnpd, but your router not properly setting that nvram. Switching to miniupnpd's built in stun client won't help you if your router is failing to do the same stun lookup.


I spent a lot of time back in the day working on miniupnpd. IPv6 ended up being left disabled because enabling it required upgrading miniupnpd to a newer IGD protocol version, and that version flooded Windows's event log with tons of error messages due to a bug in Microsoft's implementation. Again, it was discussed on the miniupnpd GIthub back then, and ultimately the problem was deemed to be within Windows, not miniupnpd, so nobody could do anything about it.

I know that story.



I had a similar problem a month ago (https://www.snbforums.com/threads/upnp-doesnt-work-on-cgnat-double-nat.80132/ ), but unlike the OP my nvram variables were getting populated correctly, but the upnp config (ext_ip=) was not getting populated on boot, I think it has something to do with my settings, I didn't investigate the cause further.

Temporary mitigation same as OP, populate the ext_ip with random public IP address manually.

I guess it has something to do with firewall configuration settings.

 

[RMerlin]

I had a similar problem a month ago (https://www.snbforums.com/threads/upnp-doesnt-work-on-cgnat-double-nat.80132/ ), but unlike the OP my nvram variables were getting populated correctly, but the upnp config (ext_ip=) was not getting populated on boot, I think it has something to do with my settings, I didn't investigate the cause further.

It gets filled here on my development RT-AC66U_B1 that sits behind my main router. Timing issue between WAN being up and running and miniupnpd config being generated perhaps? Try just restart miniupnpd to see if then it fills it properly.

service restart_upnp

 

[Yota]

It gets filled here on my development RT-AC66U_B1 that sits behind my main router. Timing issue between WAN being up and running and miniupnpd config being generated perhaps? Try just restart miniupnpd to see if then it fills it properly.

service restart_upnp

thank you for your reply

Yes, manually restarting the service populates it correctly, you're probably right, it's probably time related, not firewall.

There are some configurations that are special to me, unlike most of the people on the SNB forums, I think these options are the result of not populating at boot, I haven't been able to verify it, I will change the configuration when no one is using the router to confirm the cause of the problem.

The special configuration is that I have DoT enabled, and I have enabled "Wan: Use local caching DNS server as system resolver (default: No)", in the NTP server, I use a fixed IP address instead of a domain name to avoid problems, Because I have completely stopped using my ISP's DNS servers.

But I've noticed that such an option causes some services to time out or be very slow on wan startup, such as NTP sync taking a long time, and I had to write a script that constantly restarts the NTP service on startup to make it available as soon as possible.

So when you mentioned boot time, I first thought of these special configurations of mine.

I'll test it asap and report back with the results here.

Thank you.

 

[RMerlin]

I have enabled "Wan: Use local caching DNS server as system resolver (default: No)",

Try disabling that. One possible issue is that local DNS resolving is taking longer to be working, causing get realip to fail resolving the stun server, which in turns will cause miniupnpd to be missing the IP returned by getrealip. Directly connecting with the ISP DNS servers might be more reliable there.

 

[Yota]

Try disabling that. One possible issue is that local DNS resolving is taking longer to be working, causing get realip to fail resolving the stun server, which in turns will cause miniupnpd to be missing the IP returned by getrealip. Directly connecting with the ISP DNS servers might be more reliable there.

Thank you, I tried it and it didn't work.

I had DoT enabled, but had the router itself use DNS from the ISP, and disabled my little script that restarts the NTP service after the WAN comes online.

It turns out that at 1 minute and 48 seconds into boot, I can get the correct IP address back from getting the wan0_realip_ip variable via SSH, but at this point the syslog shows that the time has not been synced.

The time was synced at 2 minutes and 25 seconds, after that I checked the upnp config file and the IP address was not populated correctly.

If I go back to the previous configuration (continuously restarting the NTP service after the wan goes online), the time will be synced 1 minute 05 seconds after the router starts. So the default behavior is rather slow.

I am using PPPoE, PPPoE will establish the connection at 52 seconds. My restart NTP service script will run after 10 seconds (so the router log shows at about 1 minute 05 seconds that the time has been synced).

I'm guessing the inability to populate correctly and the slow startup time could be caused by other configurations, but I can't really figure out what that could be.