Bug #10398
closed
RFC1918 external address in miniupnp does not work after upgrade to 2.4.5
0%
Description
After upgrading pfSense to 2.4.5, MiniUPnP refuses to assign port mappings when the WAN interface is RFC1918 -
ISP provided outside router is on 192.168.10.254 forwarding all ports to 192.168.10.1.
pfSense -
External WAN interface is 192.168.10.2 (192.168.10.1 CARP)
Internal LAN interface is 192.168.20.2 (192.168.20.1 CARP)
Test host is on 192.168.20.100
On 2.4.4p3 -
# upnpc -a 192.168.20.100 63000 64000 tcp upnpc : miniupnpc library test client, version 2.1. (c) 2005-2018 Thomas Bernard. Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/ for more information. List of UPNP devices found on the network : desc: http://192.168.20.2:2189/rootDesc.xml st: urn:schemas-upnp-org:device:InternetGatewayDevice:1 Found a (not connected?) IGD : http://192.168.20.2:2189/ctl/IPConn Trying to continue anyway Local LAN ip address : 192.168.20.100 ExternalIPAddress = 192.168.10.2 InternalIP:Port = 192.168.20.100:63000 external 192.168.10.2:64000 TCP is redirected to internal 192.168.20.100:63000 (duration=0)
On 2.4.5 -
# upnpc -a 192.168.20.100 63000 64000 tcp upnpc : miniupnpc library test client, version 2.1. (c) 2005-2018 Thomas Bernard. Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/ for more information. List of UPNP devices found on the network : desc: http://192.168.20.2:2189/rootDesc.xml st: urn:schemas-upnp-org:device:InternetGatewayDevice:1 Found a (not connected?) IGD : http://192.168.20.2:2189/ctl/IPConn Trying to continue anyway Local LAN ip address : 192.168.20.100 GetExternalIPAddress failed. AddPortMapping(64000, 63000, 192.168.20.100) failed with code 501 (Action Failed)
It seems that the latest version of miniupnp includes a commit that forbids external addresses as per -
https://github.com/miniupnp/miniupnp/commit/8e10a1aeab9b8cd4d3b2e964b02e9ad409cf3aaa
https://github.com/miniupnp/miniupnp/issues/298
https://github.com/miniupnp/miniupnp/issues/333
One of the solutions recommended is to statically set the ext address in miniupnpd. This is not possible through the pfSence GUI. It's also problematic as the real ext address is assigned by PPPoE (on the outside router) in my setup.
Another thing I attempted is setting the WAN address in the UPnP page specifically to 192.168.10.x, but then the miniupnp daemon dies immediately.
It seems that other projects using miniupnp is also running into the same issue -
Updated by Jim Pingle over 4 years ago
- Category set to UPnP IGD & PCP
- Status changed from New to Needs Patch
We've seen this internally as well. This must be solved by miniupnpd.
One of the solutions recommended is to statically set the ext address in miniupnpd. This is not possible through the pfSence GUI.
That's what the "Override WAN address" option does.
Updated by Andy Kwong over 4 years ago
That's what the "Override WAN address" option does.
Thanks. So that's passed through as the ext_ip. I did some additional testing here and it seems -
- With a RFC1918 (or other reserved) address here, the daemon dies immediately
- With a random public address (1.1.1.1), the daemon starts, mappings are created according to the web interface, but no traffic passes
After a bit of digging, this is because of -
#pfctl -a miniupnpd -sr pass in log quick on igb0.10 inet proto tcp from any to 192.168.20.100 port = 63000 flags S/SA keep state label "libminiupnpc" rtable 0 #pfctl -a miniupnpd -sn rdr log quick on igb0.10 inet proto tcp from any to 1.1.1.1 port = 64000 keep state label "libminiupnpc" rtable 0 -> 192.168.20.100 port 63000
Which restricts all incoming traffic for the UPnP mapping on the WAN interface to the ext_ip. So even with the ext address configured properly, a double NAT setup will never work as the packets will never arrive on the WAN interface with the public address (because that gets NATed on outside router to the inside router WAN interface).
Even with ext_perform_stun (the other solution recommended), it will still break a double NAT setup.
As an aside, this behaviour of locking down the dst in the pf nat rule was not always the case. It is specifically due to -
https://github.com/miniupnp/miniupnp/issues/231
https://github.com/miniupnp/miniupnp/commit/53e81857252eb6504e878295c04e607a7c4c061e
CARP setups will also break unless the CARP address is public and configured as the "Override WAN Address"/ext_ip.
It seems that asuswrt-merlin made a good call to revert the change preventing private IPs from being external addresses in miniupnp, because this commit effectively breaks a lot of advanced NAT topologies.
Updated by Jim Pingle over 4 years ago
I agree, the changes in miniupnpd are unnecessary and harmful to some use cases. They should at least provide an option to override the behavior rather than preventing it entirely.
But that is a change that needs to be made in miniupnpd -- Advocate for it there.
If we start reverting bits and pieces in the port that puts a lot of technical debt on us to maintain that indefinitely.
Updated by Andy Kwong over 4 years ago
Ok, I opened an issue on the miniupnp tracker for this -
Updated by Steve Wheeler over 4 years ago
There us a patch available to remove that behavior in miniupnpd that needs testing:
https://github.com/miniupnp/miniupnp/commit/3f04f7992c4e8f11c2a2f66e678d9e63c8103dea
Updated by Shane Addinall over 4 years ago
Steve Wheeler wrote:
There us a patch available to remove that behavior in miniupnpd that needs testing:
https://github.com/miniupnp/miniupnp/commit/3f04f7992c4e8f11c2a2f66e678d9e63c8103dea
I tried Compiling this but didn't manage,
I'm willing to try it out for people, however I'm doing something wrong so its not working.
Keep getting the following error when I try, and I have tried cloning the repo's a few times.
I know I am doing something wrong, Just don't know what, so If someone perhaps wants to enlighten me I would be delighted to learn :D
make: "/tmp/thisistest/miniupnpd/Makefile" line 39: Could not find bsdmake.inc
make: "/tmp/thisistest/miniupnpd/Makefile" line 88: Malformed conditional ($(FWNAME) == "pf")
make: "/tmp/thisistest/miniupnpd/Makefile" line 160: warning: "which bash || which ksh" returned non-zero status
make: Fatal errors encountered -- cannot continue
make: stopped in /tmp/thisistest/miniupnpd
Thanks.