Messages

1

24.1 Legacy Series / Re: Duplicate and growing number of entries in Universal Plug and Play: Status

« on: February 23, 2024, 09:48:14 am »

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.

2

24.1 Legacy Series / Re: Duplicate and growing number of entries in Universal Plug and Play: Status

« on: February 22, 2024, 08:24:13 pm »

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

3

24.1 Legacy Series / Re: Duplicate and growing number of entries in Universal Plug and Play: Status

« on: February 21, 2024, 05:34:44 pm »

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

4

24.1 Legacy Series / Duplicate and growing number of entries in Universal Plug and Play: Status

« on: February 09, 2024, 10:14:14 pm »

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]

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]

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]

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.