miniUPnPd not working since 23.09 (worked in 23.05.1)

johnpoz

@stephenw10 so I not a fan or a user of upnp.. But I just enabled it to have it create the .conf file and yup it put in 2189 which doesn't make any sense

[23.09-RELEASE][admin@sg4860.local.lan]/var/etc: cat miniupnpd.conf 
ext_ifname=igb1
port=2189
listening_ip=igb4
secure_mode=yes
presentation_url=https://192.168.200.1:8443/
uuid=da5797c4-0daa-f185-0994-a6afe6c2ecb
serial=DA5797C4
model_number=23.09-RELEASE
enable_upnp=yes
enable_natpmp=yes
[23.09-RELEASE][admin@sg4860.local.lan]/var/etc:

But it is listening on 1900 as well

[23.09-RELEASE][admin@sg4860.local.lan]/var/etc: sockstat | grep 1900
root     miniupnpd  77102 7   udp4   *:1900                *:*
[23.09-RELEASE][admin@sg4860.local.lan]/var/etc: sockstat | grep 2189
root     miniupnpd  77102 4   tcp6   *:2189                *:*
root     miniupnpd  77102 6   tcp4   *:2189                *:*
[23.09-RELEASE][admin@sg4860.local.lan]/var/etc:

stephenw10

Because that's the port minipnpd listens on the http:
curl http://192.168.200.1:2189/rootDesc.xml

As far as I know that can be omitted entirely and miniupnpd will use a random port.

Setting it to 1900 is probably a bad idea since it should already be listening there. Though for udp.

johnpoz

@stephenw10 were they come up with that port, I don't show it registered as that.. Pretty sure radware has that registered for something they do radware-rpm-s

And I concur - setting that port in the config to 1900 prob not a good idea, and I would think really had nothing to do with his issue.. UPnP is UDP.

stephenw10

Yeah, unclear. Looks like they removed that over on the other side after deciding it was pointless setting it.

PiAxel

@stephenw10
I disable port in the conf file and now miniupnpd use a random port.
It's still working
How can I know if the port 2189 is already use by another service ?

johnpoz

@PiAxel said in miniUPnPd not working since 23.09 (worked in 23.05.1):

How can I know if the port 2189 is already use by another service ?

do the command I did with sockstat

PiAxel

@johnpoz
ok thank you
but it is not used...

johnpoz

@PiAxel well if its running and you want to know what port it is using do

sockstat | grep miniupnpd

PiAxel

@johnpoz

/root: sockstat | grep miniupnpd
root     miniupnpd  36049 4   tcp6   *:51760               *:*
root     miniupnpd  36049 5   dgram  -> /var/run/log
root     miniupnpd  36049 6   tcp4   *:51760               *:*
root     miniupnpd  36049 7   udp4   *:1900                *:*
root     miniupnpd  36049 8   stream /var/run/php-fpm.socket
root     miniupnpd  36049 9   udp6   *:1900                *:*
root     miniupnpd  36049 10  udp4   192.168.1.1:55617     *:*
root     miniupnpd  36049 11  udp6   *:64174               *:*
root     miniupnpd  36049 12  stream /var/run/php-fpm.socket
root     miniupnpd  36049 14  udp4   192.168.1.1:5351      *:*
root     miniupnpd  36049 15  udp6   *:5351                *:*

stephenw10

That seems fine. I have no explanation as to why changing the port value to 1900 seemed to allow it work though. That really shouldn't have changed anything significant.

PiAxel

thank you very much for your help !

PiAxel

@PiAxel
The problem is back since update 23.09.1
everything seems to be working fine but neither my NAS nor any other network device can open a port via upnp. the games on my pc say that I am in strict NAT.
In pfsense stat upnp is empty.

I try with port=0 instead of 2189 but it didn't change anything

Tell me what you want to know about my pfsense.

Please help me!

PiAxel

I have disabled STUN and there is no more message with "port forwarding is now disabled" but that still doesn't work.

stephenw10

@PiAxel said in miniUPnPd not working since 23.09 (worked in 23.05.1):

STUN: ext interface ix0 has now public IP address external ipv4 but firewall filters incoming connections set by miniunnpd

That implies you have something set that is preventing miniupnpd opening inbound ports somehow.

Do you have a custom block all rule on WAN or as Floating?

PiAxel

@stephenw10
No, I don't have any rule on WAN or as floating to block all

stephenw10

Could be something upstream blocking it then. Try to send some traffic to your WAN from some external address and see if it arrives in a packet capture.

reeves0724

you have to add a rule in wan to allow...

## External Network

ext_ifname=igc0
ext_perform_stun=yes
ext_stun_host=198.100.144.121
ext_stun_port=3478

## Internal Network

listening_ip=bridge0
ipv6_disable=yes
allow 1024-65535 192.168.1.0/24 1024-65535
deny 0-65535 0.0.0.0/0 0-65535
bitrate_down=512000
bitrate_up=1024000


## UPnP Settings

anchor=miniupnpd
enable_natpmp=yes
enable_upnp=yes
secure_mode=yes
min_lifetime=120
max_lifetime=86400
system_uptime=yes
notify_interval=60
clean_ruleset_interval=600
packet_log=yes
uuid=fb241e30-9c00-11ee-xxxxxxxxxxx
serial=CA0A9DD5