Yota
Very Senior Member
On one of my networks running RT-AC86U it has CGNAT. But my ISP allows hole punching in firewalls using protocols like UPnP and PCP.
When I enable UPnP and try hole punching with PlayStation or qBittorrent, I get this error in the log:
I know that miniupnpd's upstream has always been unfriendly to non-external IPs, but RMerlin and Themiron have done a lot of work to address upstream stubbornness.
I don't often enable UPnP because I see it as a security risk. But I remember when I enabled UPnP a year ago, it worked fine. to rule out my ISP problem, I found an old Asus DSL router in the closet, it was running 380 firmware, after I set it up briefly, I ran the UPnP test again, this time UPnP worked fine, which proved my UPnP is available even if CGNAT is present. I can't tell which version of miniupnpd this firmware is using, because miniupnpd doesn't support commands like
But currently on the 386.7_2 firmware, when any client tries to establish a UPnP connection, I just get that error that hits the door.
I don't know when UPnP didn't work on Merlin firmware since it's been more than a year since UPnP was last enabled, but I've seen the following changes in the changelog, maybe it's instructive:
Is there any solution?
Edit:
When I try to edit
Edit2:
I marked the issue as SOLVED because I just changed
I noticed that there is no
Edit3:
After testing, the ext_ip= option accepts any available external IP address, even if it is fake, the fake external IP address will not affect the real UPnP function, so I wrote a small script to temporarily alleviate the problem:
When I enable UPnP and try hole punching with PlayStation or qBittorrent, I get this error in the log:
Code:
miniupnpd: private/reserved address 100.x.x.x is not suitable for external IP
I know that miniupnpd's upstream has always been unfriendly to non-external IPs, but RMerlin and Themiron have done a lot of work to address upstream stubbornness.
I don't often enable UPnP because I see it as a security risk. But I remember when I enabled UPnP a year ago, it worked fine. to rule out my ISP problem, I found an old Asus DSL router in the closet, it was running 380 firmware, after I set it up briefly, I ran the UPnP test again, this time UPnP worked fine, which proved my UPnP is available even if CGNAT is present. I can't tell which version of miniupnpd this firmware is using, because miniupnpd doesn't support commands like
-V
to check the version.But currently on the 386.7_2 firmware, when any client tries to establish a UPnP connection, I just get that error that hits the door.
I don't know when UPnP didn't work on Merlin firmware since it's been more than a year since UPnP was last enabled, but I've seen the following changes in the changelog, maybe it's instructive:
Code:
386.5 (2-March-2022)
- UPDATED: miniupnpd to 2.3.0.
386.4 (1-Jan-2022)
- UPDATED: miniupnpd to 2.2.3-git 20211017.
- CHANGED: miniupnpd will now be supplied the public WAN
IP to improve compatibility with dual NAT
setups.
386.1 (30-Jan-2021)
- UPDATED: miniupnpd to 2.2 (git snapshot from 20201129)
384.13_8 (26-Apr-2020)
- FIXED: miniupnpd would reject private WAN IPs - changed that
upstream behaviour to allow these.
Is there any solution?
Edit:
When I try to edit
/etc/upnp/config
and add the ext_ip=
option to it to force CGNAT's IP address, I get the following error in terminal:
Code:
# killall miniupnpd && miniupnpd -f /etc/upnp/config
Error: option ext_ip contains reserved / private address 100.x.x.x, not public routable
Edit2:
I marked the issue as SOLVED because I just changed
ext_ip=
to the external public IP and UPnP was working fine.I noticed that there is no
ext_ip=
line in the /etc/upnp/config
file, but the 386.4 changelog seems to indicate that it is auto-populated, I think, maybe some changes I made to the router firewall and hosts
file caused the ext_ip=
line to not populate correctly (I did block many unknown requests from the router itself to the outside).Edit3:
After testing, the ext_ip= option accepts any available external IP address, even if it is fake, the fake external IP address will not affect the real UPnP function, so I wrote a small script to temporarily alleviate the problem:
/jffs/scripts/upnp.postconf
Code:
#!/bin/sh
CONFIG=$1
echo "ext_ip=1.1.1.1" >> $CONFIG
Last edited: