Messages

Since the author ignores reports that originate from OPNsense just because he can don't expect this to be fixed any time soon. I've talked through all the FreeBSD ranks and nobody can/wants to do anything about it.

Thanks!

Maybe it's possible to use miniupnpd 2.3.3_1 instead of 2.3.3_2 somehow?

The pkg you suggested on GitHub from 23.7 version didn't work due to openssl dependency change.

Found a related bug report: https://github.com/opnsense/plugins/issues/3831.

[Allow PCP/NAT-PMP Port Mapping]

Disabling Allow PCP/NAT-PMP Port Mapping setting doesn't help. I can still see duplicate entries and the client reads them incorrectly.

miniupnpd is working fine, but I noticed the increasing number of duplicate entries in the status (Services: Universal Plug and Play: Status).

Example:

Code Select Expand

Port Protocol Internal IP Int. Port Description
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)
9308 udp 10.0.0.149 9308 10.0.0.149:9308 to 9308 (UDP)


They stick there forever, never expire, and the list grows over time.

For example, 10.0.0.149 is my PS5. 10.0.0.87 is Synology NAS, and there is already a port forward rule for 6690 (Cloud Station).

Is it expected? If not, why it happens and should I do something about it? I know that explicit port forwards are recommended, but in case I want to keep using miniupnpd, should I be worried about these duplicates and possible resource leaks, or maybe it's just a visual representation bug?

EDIT:

I found some more details which may explain why it happens.
Using command line miniupnpc 2.2.6 and other upnp clients (like https://github.com/kaklakariada/portmapper), listing the existing mappings shows corrupted results:

Code Select Expand

i protocol exPort->inAddr:inPort description remoteHost leaseTime
0 UDP     0->10.0.0.87:0     '' '34.26.0.0' 0
1 UDP     0->10.0.0.87:0     '' '34.26.0.0' 0
2 UDP     0->10.0.0.87:0     '' '34.26.0.0' 0




Instead of these:

Code Select Expand

62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690
62852 tcp 10.0.0.87 6690 upnpclient:6690


It could be that PS5 and other clients get the same corrupted results, don't see the mapping they already created and try to add a new one which produces duplicates (and probably also cannot delete a mapping).

The question is why miniupnpd 2.3.3_2,1 server on opnsense returns these corrupted mappings.