Made some progress today, and it looks like there is problem with the OpenWRT implementation of miniupnpd, related to how it handles the firewall during the Stun test.
Suspecting this, I ran a quick test, and I think I proved the DMZ stuff upstream is working and the core issue is how the upnpstun function is testing for access. They open 4 ports to receive inbound replies from the stun server, I just don’t think the rules are quite right on the OpenWRT build.
First, I opened up the inbound udp in the firewall, any inbound udp connection can reach the device (dangerous)
Re-pushed my customized miniupnpd.conf file back in to /var/etc/miniupnpd.conf
Kill existing instance and re-launch with the debug flag, and voila:
root@OpenWrt:~# /usr/sbin/miniupnpd -d -f /var/etc/miniupnpd.conf
miniupnpd[4668]: system uptime is 27647 seconds
miniupnpd[4668]: Reloading rules from lease file
miniupnpd[4668]: could not open lease file: /var/run/miniupnpd.leases
miniupnpd[4668]: version 2.1 starting NAT-PMP/PCP UPnP-IGD ext if eth0.2 BOOTID=1533931318
miniupnpd[4668]: STUN: Performing with host=stun.onesuite.com and port=0 ...
miniupnpd[4668]: STUN: ext interface eth0.2 with IP address 192.168.254.13 is now behind unrestricted NAT 1:1 with public IP address 40.134.86.218: Port forwarding is now enabled
miniupnpd[4668]: HTTP listening on port 5000
miniupnpd[4668]: HTTP IPv6 address given to control points : [redacted]
miniupnpd[4668]: Listening for NAT-PMP/PCP traffic on port 5351
And the test tool reports all good, I can now add new port maps, and even my Back To My Mac reports all good.
So it's in how they craft and / or apply the temporary firewall rules for these tests that is likely the problem.
Should I open a bug on the OpenWRT flyspray or back on the miniupnpd project?