"
Hi,
I wanted to share my experience because I regularly use this plugin, and it worked perfectly before.
The plugin currently appears to be broken, at least on my OPNsense 26.7.2_2 installation with os-upnp 1.9 and miniupnpd 2.3.9_2.
A PlayStation, Xbox, or another device reporting NAT Type 2, Moderate NAT, or Open NAT does not prove that UPnP is working correctly. The reported NAT type can result from normal outbound NAT, static-port outbound NAT, STUN, or relay services.
Adding a separate static-port outbound NAT rule may affect the console's reported NAT type, but it does not fix the broken UPnP redirect. MiniUPnPd is supposed to create the necessary dynamic NAT and redirect rules itself.
You can inspect the rules created by MiniUPnPd with:
In my case, the relevant NAT entries are:
The external interface is configured correctly and has a public IPv4 address:
The important part is `-> ?`. The outbound NAT rule should contain a valid translation address, while the redirect rule should point to the internal client—in this case, `192.168.60.100`.
This shows that:
- The UPnP request is accepted: ✓
- UDP port 9308 is registered as a mapping: ✓
- PF/NAT entries are created: ✓
- Valid translation targets are installed: ✗
- A valid, functioning port forward is created: ✗
This is therefore not an UPnP discovery problem. The client reaches MiniUPnPd and requests the mapping successfully, but the resulting PF rules do not contain valid translation targets.
The console's reported NAT type should not be used to confirm that the plugin is working. It appears that we will have to wait for a fix to the MiniUPnPd/PF integration.
I wanted to share my experience because I regularly use this plugin, and it worked perfectly before.
The plugin currently appears to be broken, at least on my OPNsense 26.7.2_2 installation with os-upnp 1.9 and miniupnpd 2.3.9_2.
A PlayStation, Xbox, or another device reporting NAT Type 2, Moderate NAT, or Open NAT does not prove that UPnP is working correctly. The reported NAT type can result from normal outbound NAT, static-port outbound NAT, STUN, or relay services.
Adding a separate static-port outbound NAT rule may affect the console's reported NAT type, but it does not fix the broken UPnP redirect. MiniUPnPd is supposed to create the necessary dynamic NAT and redirect rules itself.
You can inspect the rules created by MiniUPnPd with:
Code Select
pfctl -P -a miniupnpd -s nat
pfctl -P -a miniupnpd -s rules
In my case, the relevant NAT entries are:
Code Select
nat log quick on igc0 inet proto udp from 192.168.60.100 port = 9308 to any keep state label "192.168.60.100:9308 to 9308 (UDP)" rtable 0 -> ? port 9308
rdr pass log quick on igc0 inet proto udp from any to any port = 9308 keep state label "192.168.60.100:9308 to 9308 (UDP)" rtable 0 -> ? port 9308
The external interface is configured correctly and has a public IPv4 address:
Code Select
ext_ifname=igc0
listening_ip=vlan060
The important part is `-> ?`. The outbound NAT rule should contain a valid translation address, while the redirect rule should point to the internal client—in this case, `192.168.60.100`.
This shows that:
- The UPnP request is accepted: ✓
- UDP port 9308 is registered as a mapping: ✓
- PF/NAT entries are created: ✓
- Valid translation targets are installed: ✗
- A valid, functioning port forward is created: ✗
This is therefore not an UPnP discovery problem. The client reaches MiniUPnPd and requests the mapping successfully, but the resulting PF rules do not contain valid translation targets.
The console's reported NAT type should not be used to confirm that the plugin is working. It appears that we will have to wait for a fix to the MiniUPnPd/PF integration.
