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

[iMoc]

My WAN is behind the modem which set this router as a DMZ.
A new upstream patch is available.

options: ext_ip_reserved_ignore support by ptpt52 · Pull Request #511 · miniupnp/miniupnp

add an option to ignore even if ext_ip is reserved this make the port forwarding force to work when the router is behind NAT

github.com

Source:

miniupnpd: Port forwarding not work when the router is behind NAT · Issue #13773 · openwrt/packages

Maintainer: @neheb Environment: NETGEAR WNDR4300 / Atheros AR9344 rev 2 / OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.287.57033-3d52019 Description: Miniupnpd of OpenWrt 19...

github.com

Not compiled with IPv6 support too. Well, I guess it's not that needed, entware version can do it.


PS. It work yesterday for whatever reason.

 

[ColinTaylor]

RMerlin was aware of this issue back in 2020 and patched his version of miniupnpd. Are you saying you still have this problem?

 

[iMoc]

Yes, 386.7_2 latest.
It works yesterday for whatever reason, today 501 fail.

 

[ColinTaylor]

Yes, 386.7_2 latest.
It works yesterday for whatever reason, today 501 fail.

What works? What fails?

I've been running my router behind another router using DMZ and UPnP for the past couple of months and everything works fine.

Show us exactly what you are doing and where you're seeing this error.

 

[iMoc]

eth0 IP 192.168.1.100

Config:
ext_ifname=eth0 listening_ip=br0 port=0 enable_upnp=yes enable_natpmp=yes secure_mode=yes upnp_nat_postrouting_chain=PUPNP upnp_forward_chain=FUPNP upnp_nat_chain=VUPNP notify_interval=60 system_uptime=yes friendly_name=RT-AC86U-9308 model_name=RT-AC86U model_description=ASUS Wireless Router model_number=386.7 serial=a8:5e:43:67:93:08 uuid=3dddc1d3-2380-45f5-b069-a85e66666668 lease_file=/tmp/upnp.leases clean_ruleset_interval=600 clean_ruleset_threshold=20 presentation_url=https://172.16.1.1/ allow 1-65535 172.16.1.1/255.255.255.0 1024-65535 min_lifetime=120 max_lifetime=86400 deny 0-65535 0.0.0.0/0 0-65535

Xbox UPnP failed.
Only after adding ext_ip="a random public IP"
Then It works.

 

[iMoc]

version: miniupnpd 2.3.0 master-021766bdf9 Jul 24 2022

miniupnpd shows 501 error. Pretty common.

 

[ColinTaylor]

Only after adding ext_ip="a random public IP"
Then It works.

I don't know why you're missing that line. On my router (running 386.5_2) it's already there. So miniupnpd works fine if the config file is correct.

I think this problem is probably part of the dual-WAN problem that you were having. I'm guessing the config file was never fully created.

https://github.com/RMerl/asuswrt-merlin.ng/blob/2db25fa3abb9404c222cddfef03a26266b74f1e4/release/src/router/rc/services.c#L6626

nvram show | grep ^wan.*_realip | sort

 

[iMoc]

No, different place, different router, this is a single WAN setup.

 

[iMoc]

wan0_realip_ip=
wan0_realip_state=1
wan1_realip_ip=
wan1_realip_state=0

How is this done, what domain I might blocked?

 

[ColinTaylor]

No, different place, different router, this is a single WAN setup.

Then I don't know why you're missing that line in your config file. Maybe it's a bug in 386.7_2 because it works fine on my router.

wan0_realip_ip=
wan0_realip_state=1
wan1_realip_ip=
wan1_realip_state=0

How is this done, what domain I might blocked?

Try running this:

/usr/sbin/getrealip.sh

It uses stun.l.google.com and stun.stunprotocol.org

ministun -t 1000 -c 1 -i eth0 stun.l.google.com:19302
ministun -t 1000 -c 1 -i eth0 stun.stunprotocol.org

 

[iMoc]

It can get and set ip in nvram. But only reliability so after all services especially VPN client is fully up. So maybe auto run this getrealip.sh in custom config and restart miniupnpd. Or idk feels buggy to me. This config doesn't do anything except lift the restriction, why is there in the first place.

 

[Tech9]

Are you talking about this thing?

Release - Asuswrt-Merlin 386.7 is now available for all models

Hello, first of all this is what i think of humans that make things like these firmwares (not only scripst). As cooking is an act of love I can see this very similar so THANK YOU VERY MUCH! (as you can see i was already reading about scmerlin because i really need wireguard) I come from...

www.snbforums.com

I never tested it again in 386.7_2 because of other issues encountered. 386.5_2 is the better firmware from what I can tell.

 

[iMoc]

Ding ding ding

 

[Tech9]

If that answer means yes, I never asked again because I don't really use my Asus routers. I was just reporting what I see abnormal.

 

[iMoc]

@RMerlin

 

[iMoc]

MiniUPnPd problem (solved & helper script)

I've got a problem in 386.5_2 with miniupnpd refuses to map ports. Instead I got this: Apr 23 01:50:25 RT-AC86U miniupnpd[2782]: Failed to add NAT-PMP 42613 tcp->192.168.16.16:22000 'NAT-PMP 42613 tcp' Apr 23 01:50:26 RT-AC86U miniupnpd[2782]: Failed to add NAT-PMP 42613...

www.snbforums.com

 

[RMerlin]

A new upstream patch is available.

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.

Not compiled with IPv6 support too.

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.

 

[iMoc]

Ah sounds unnecessarily added complexity, what is this author thinking[Face Holding Back Tears emoji]
I'll just add ext_ip="a random public IP" to postconf, doesn't seem to break anything, iptables rules don't contain this IP anyway.

 

[iMoc]

Wait it's up to date why is that patch not available then? Option ignore ext IP.

 

[ColinTaylor]

Wait it's up to date why is that patch not available then? Option ignore ext IP.

Because the patch was rejected by the miniupnpd author.