OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: xpendable on May 24, 2018, 06:27:39 pm
-
Hello,
It seems like the UPnP Plugin does not work correctly, I have tried changing various options to no avail. Basically I can get UPnP to work with the gaming consoles by following the information provided in this post: https://forum.opnsense.org/index.php?topic=1368.msg5218#msg5218
However when it comes to UPnP within Windows, the results are less then positive. Once the client computer boots (Win10 1804) up UPnP is broken and does not work, the UPnP service is not discoverable by using the miniupnpc client or by using another utility called UPnP PortMapper (https://github.com/kaklakariada/portmapper). UPnP PortMapper will report the following in debug mode:
DEBUG Start searching using upnp service
DEBUG Found service of wrong type urn:schemas-upnp-org:device:Basic:1, expected urn:schemas-upnp-org:device:InternetGatewayDevice:1.
DEBUG Did not find a service after 5 seconds
WARN Could not connect to router: Did not find a router
Where as miniupnpc will simply not see anything. Now if I click on network within the windows explorer tree to view UPnP devices on my network... after a few seconds the FreeBSD Router (in this case OPNsense) will be visible. Again this is after the client machine has been started for the first time. Then by rechecking the status with either of the utilities mentioned above I get a correct UPnP response and the FreeBSD router is discoverable.
This however is short lived, after 5mins the FreeBSD router disappears from the windows explorer network view and is no longer discoverable with either utility. The only way that I have found to get UPnP functioning again after this point is to go in to the OPNsense web management and stop then start the UPnP service. Once I have done that I have another 5mins before it disappears again. This is problematic when you wish to play a multiplayer game that uses UPnP, In my case Grim Dawn. As long as I start the game within the 5min window, no problems.. otherwise no chance.
I don't know what the possible solution might be. I notice that the OPNsense UPnP package is running an older version of miniupnpd 1.9, where the newest version is 2.1, or if it's because the MiniSSDPd package has not been installed to aid in M-SEARCH requests.
Can anyone else verify this behavior?
UPDATE:
I guess I should also mention OPNsense is running on a XenServer host. I created 2 new VM's on the same host to test UPnP and the funny thing was that they both worked fine with no problems. One was a Ubuntu Desktop 18.04 LTS and one was a Win10 x64 1804 release.
I then though that it might have been the bonded NICs within XenServer that maybe causing the issue. So I removed the bond and assigned a dedicated NIC to OPNsense for the LAN interface, however the result was the same. I also tried an old Win7 laptop with the same results, it almost seems like any physical device outside of gaming consoles are affected by this 5min connection issue. I haven't tried a physical linux system yet though, maybe I'll get around to testing that tomorrow. For now as long as I stop/start the UPnP Service in OPNsense I have a 5min window of opportunity.
The other strange thing is that I have another UPnP device on the network and that one always shows up without fail either within a VM desktop or a physical machine, at this point I have no idea whats going on.
Just so that this might help others... turns out the issue was IGMP Snooping was enabled on my managed switched. This interferes with UPnP multicast traffic, simply disable IGMP Snooping and UPnP works perfectly now.