pfSense

I've ran into the same issue. I have several Xbox One's in my network and they are no longer opening ports. I also enabled UPNP on my security cameras to test and they also didn't open ports. These devices were able to open ports on 2.2.6.

Still no ports opened by Xbox One or Windows 10. I verified the binary was updated.

Would it be possible to log what release of miniupnpd is in use when it fires up? I seem to remember seeing a version number in the past but this isn't showing up now. It would be helpful to users trying to hunt down XBox problems if we knew what version we were running. :)

(Is it somehow documented what version you pull when you build an official pfSense release? I'm not a dev, I was poking around github and couldn't find any way to see what version was included in a given release.)

Braden McGrath wrote:

(Is it somehow documented what version you pull when you build an official pfSense release? I'm not a dev, I was poking around github and couldn't find any way to see what version was included in a given release.)

It's listed in the pkg database on each firewall, you can find the version from the shell or Diagnostics > Command:

: pkg info -x miniupnpd
miniupnpd-1.9.20151212,1

Or for more detail, omit the '-x'.

Unfortunately I'm experiencing the same issue still. I should probably bring this up with the miniupnpd dev and/or MS.

Billy Jones wrote:

Unfortunately I'm experiencing the same issue still. I should probably bring this up with the miniupnpd dev and/or MS.

Yeah that has to be something different than what was discussed in that thread in that case. Given it's a significant regression in miniupnpd, I'd suggest taking it up on their board and reporting back here after.

Here's the output of pkg info miniupnpd

miniupnpd-1.9.20160113,1
Name : miniupnpd
Version : 1.9.20160113,1
Installed on : Thu Jan 14 20:19:15 2016 PST
Origin : net/miniupnpd
Architecture : freebsd:10:x86:64
Prefix : /usr/local
Categories : net
Licenses : BSD3CLAUSE
Maintainer : squat@squat.no
WWW : http://miniupnp.free.fr/
Comment : UPnP IGD implementation which uses pf/ipf
Options :
CHECK_PORTINUSE: on
IPV6 : on
LEASEFILE : off
PF_ENABLE_FILTER_RULES: on
UPNP_IGDV2 : on
UPNP_STRICT : off
Annotations :
cpe : cpe:2.3:a:miniupnp_project:miniupnpd:1.9.20160113:::::freebsd10:x64
repo_type : binary
repository : pfSense
Flat size : 147KiB
Description :
Mini UPnPd is a lightweight implementation of a UPnP IGD daemon. This is
supposed to be run on your gateway machine to allow client systems to redirect
ports and punch holes in the firewall.

WWW: http://miniupnp.free.fr/

The line UPNP_IGDV2 : on might point to the problem I'm experiencing. According to the thread I mentioned before, "Unfortunately it seems that a lot of developer are not following the UPnP recommendation on how to manage version to ensure backward compatibility. So I'm afraid many control point are not compatible with IGD v2."

There was a user in the thread that had success with the current Xbox One OS and miniupnpd version 1.9.20160113, but I don't believe they specified the exact options used when compiling. Any chance we can try compiling miniupnpd without using the IGD2 option? I'm not sure if this would introduce any additional security risks on top of just running upnp in general.

Can someone post the results of pkg info miniupnpd from a pfsense 2.2.6 install?

There isn't 'pkg info' in 2.2.x, but it is built without UPNP_IGDV2. That change was made as part of #4321. I believe it's a requirement for IPv6. Now I'm wondering if that's the reason we ended up not enabling IPv6 in miniupnpd. JimP and I seemed to recall some kind of problem that introduced but neither of us could recall anything specific.

IPv6 in miniupnpd seems to be enabled in the current build (What even uses IPv6 and upnp anyway?). I inquired at the miniupnp forums what options the user who got everything working with IGD2 used, but if everything is working, I wouldn't expect them to still be checking bug reports. Does disabling IPv6 in miniupnpd require it to be rebuilt or is this something I can test on my own? Using IGD1 would be less than ideal since I believe it has been deprecated, but I'm still not sure what this means from a practicality/security standpoint.

Practically everything uses IGD1 spec. IGD2 is supposed to be backwards compatible, but in practice, it isn't (see XBox One and Win10 problem as evidenced here).

Whether this is because miniupnp is implementing the spec incorrectly or because the devices are buggy remains to be determined. However, the miniupnp developer is apparently a member of the UPnP forum and has access to the official spec... which he says he's implementing, which makes one think maybe the spec doc / examples are wrong?

I reverted the IGD2 and IPv6 change that seems to have been the start of this problem so we can confirm or deny whether that was actually the case.

Just got the update and the issue appears to be resolved. FYI, even though IPv6 was disabled in options, pkg info miniupnpd and the routing logs seem to indicate that IPv6 support is enabled for miniupnpd. Not a big deal, just not sure why that would be the case.

Thanks for the feedback, Billy.

I re-enabled IPv6, leaving just IGD2 disabled, which seems like it should retain working functionality here and keep IPv6 support for #4321.

IGD2 looks to break things in this circumstance, ref:
http://miniupnp.tuxfamily.org/forum/viewtopic.php?p=4017
and a number of other similar threads.

Please upgrade again once the updated miniupnpd is available (sometime tomorrow at latest, likely within a handful of hours after the time of this comment), and report back.

Just updated a few minutes ago (built on Tue Jan 26 17:33:47 CST 2016). The miniupnpd binary did not get reinstalled and is unchanged from when I updated on Saturday. All devices are still opening ports as needed, so that's still good. Thanks for your attention to this issue!