net/upnp: Complete service improvements 1/2 by Self-Hosting-Group · Pull Request #5126 · opnsense/plugins

Self-Hosting-Group · 2026-01-09T06:10:37Z

No description provided.

Self-Hosting-Group · 2026-01-16T15:52:31Z

See 26.1 coming soon. Can we continue here?

Self-Hosting-Group · 2026-01-19T13:24:02Z

If I just copy the syslog filter template, it will not be applied; a /etc/rc.d/syslogd restart is necessary.

fichtner · 2026-01-20T11:38:28Z

syslog is always restarted post-install for plugins:

https://github.com/opnsense/core/blob/5da971f2c678fa6d01fb2db4b8a190fd41b8c70a/src/etc/rc.configure_plugins#L46-L49

See 26.1 coming soon. Can we continue here?

Sure, the PR is still in draft mode... you need to signal when you're ready first.

fichtner · 2026-01-20T11:42:43Z


+1.8
+
+...


yes please, I did forget these

what about these? and can you bring it out of draft mode please?

Self-Hosting-Group · 2026-01-27T08:11:02Z

Sorry for the delay. I've just pushed the changes. Since the OPNsense 26.1 release is tomorrow and this PR is ready, it would be great if you could give me a quick comment on the following points. I'll then prepare the missing changelog and remove the draft flag from the PR to be merged.

Sure, the PR is still in draft mode... you need to signal when you're ready first.

I did this so that the PR wouldn't be merged unexpectedly too early. Thank you for the review.

syslog is always restarted post-install for plugins:

https://github.com/opnsense/core/blob/5da971f2c678fa6d01fb2db4b8a190fd41b8c70a/src/etc/rc.configure_plugins#L46-L49

OK. My question was incomplete. I noticed that copying the snippet and restarting the syslogd logs daemon errors, but not after restarting the router. Does this work with a normal plugin installation? I didn't compile the package this time.
Daemon errors are now logged, but messages with higher syslog severity (e.g. info with miniupnpd -v) seem to be filtered out, even if enabled in the UI. Is there anything that can be done?

fichtner · 2026-01-27T08:39:24Z

OK. My question was incomplete. I noticed that copying the snippet and restarting the syslogd logs daemon errors, but not after restarting the router. Does this work with a normal plugin installation? I didn't compile the package this time.

Yep should be good as is.

Daemon errors are now logged, but messages with higher syslog severity (e.g. info with miniupnpd -v) seem to be filtered out, even if enabled in the UI. Is there anything that can be done?

Where are you logging to? System log? It may be better to add a separate log file and page for miniupnpd alone. The system log is capped to notice (so won't see info or debug) for historic reasons.

Self-Hosting-Group · 2026-01-29T05:13:53Z

It may be better to add a separate log file and page for miniupnpd alone.

Separate log file implemented. Please review.

Self-Hosting-Group · 2026-01-29T21:25:59Z

@fichtner @fraenki Critical issue detected in OPNsense 26.1 and registerAnchor function used in plugin.

pfctl_get_rules_info: Invalid argument is logged. registerAnchor function used in miniupnpd.inc does not seem to be working.

/sbin/pfctl -P -a miniupnpd -s nat
pfctl: DIOCGETRULES: Invalid argument

See: https://forum.opnsense.org/index.php?msg=258237

fichtner · 2026-01-30T22:22:05Z

Thanks for the hint. I found it https://forum.opnsense.org/index.php?topic=50520.msg258554#msg258554

Self-Hosting-Group · 2026-01-30T22:31:49Z

A 26.1_5 release?

fichtner · 2026-01-30T22:35:19Z

This should have been in today’s hotfix, but there likely won’t be another. We’re targeting a 26.1.1 next week for a lot of other reasons. Not sure how early or late in the week that will be.

Self-Hosting-Group · 2026-02-12T08:40:09Z

I would like to better understand the pf daemon backend. Since I know that the daemon does not create binat rules, I first removed this registration, then others, and then realised that only one registration is sufficient to create the anchor, and that IPv4/IPv6 port mapping works. Therefore, why does the rule type (rdr/nat...) need to be registered at all?

plugins/net/upnp/src/etc/inc/plugins.inc.d/miniupnpd.inc

Lines 42 to 45 in 85f1bb9

    
           $fw->registerAnchor('miniupnpd', 'rdr'); 
        
           $fw->registerAnchor('miniupnpd', 'fw'); 
        
           $fw->registerAnchor('miniupnpd', 'nat', 0, 'head'); 
        
           $fw->registerAnchor('miniupnpd', 'binat');

And what do you think of this wording addition in the UI help?
Allow adding port maps for non-requesting IP addresses; normally disabled for security

Self-Hosting-Group · 2026-02-16T12:07:25Z

Below are three comments on OPNsense 26.1 that are unrelated to this PR:

When 26.1 is newly installed and the setup wizard is not launched, IPv6 works on the LAN as in previous versions, but when I complete the wizard, the Dnsmasq IPv6 range is deleted. Is this intentional? How about if only the IPv4 range is deleted by the wizard? PS: I have seen that there are plans to extend the wizard for IPv6 in 26.7, which is of course the optimal solution. See: https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/models/OPNsense/Core/InitialSetup.php#L383-L385
Clicking on the logo bypasses the wizard, but this is not permanent
The ACL name of Dnsmasq was probably written with a slash because XML entities were not decoded at the time, but could now be adapted to the menu name. See: https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/models/OPNsense/Dnsmasq/ACL/ACL.xml

fichtner · 2026-02-25T07:52:22Z

+    global $config;
+    $upnp_config = $config['installedpackages']['miniupnpd']['config'][0];
+    if (($upnp_config['log_level'] ?? '') == 'info') {
+        $exec_cmd='/usr/local/sbin/miniupnpd -f %s -P %s -v';
+    } elseif (($upnp_config['log_level'] ?? '') == 'debug') {
+        $exec_cmd='/usr/local/sbin/miniupnpd -f %s -P %s -vv';
+    } else {
+        $exec_cmd='/usr/local/sbin/miniupnpd -f %s -P %s';
+    }
+    mwexecfb($exec_cmd, ['/var/etc/miniupnpd.conf', '/var/run/miniupnpd.pid']);


this part needs modification post merge

fichtner · 2026-02-25T08:34:03Z

feel free to open a new pr

Self-Hosting-Group · 2026-02-25T08:42:42Z

I would prefer to collaborate more so that I don't have to make new PRs again.

fichtner · 2026-02-25T08:45:52Z

7658677 works for me

I would prefer to collaborate more so that I don't have to make new PRs again.

This costs too much time for me so I need to batch the time to look at this. We don't discuss code in an open PR. An open PR should include all the code you want to be published.

From my point of view the scope of this PR is mostly complete. The changelogs are still missing, but it's up to you.

Self-Hosting-Group · 2026-02-25T08:57:52Z

7658677 works for me

I would prefer to collaborate more so that I don't have to make new PRs again.

This costs too much time for me so I need to batch the time to look at this. We don't discuss code in an open PR. An open PR should include all the code you want to be published.

From my point of view the scope of this PR is mostly complete. The changelogs are still missing, but it's up to you.

Yes mostly, but e.g. the improved (more secure) allow_third_party_mapping option, help text, unified ACL tags are missing, and an comment to #5126 (comment) helped me a lot. I'll put now next PRs in draft until we have reviewed it complete and remove the flag when we are both satisfied.

fichtner · 2026-02-25T09:23:51Z

I would like to better understand the pf daemon backend. Since I know that the daemon does not create binat rules, I first removed this registration, then others, and then realised that only one registration is sufficient to create the anchor, and that IPv4/IPv6 port mapping works. Therefore, why does the rule type (rdr/nat...) need to be registered at all?

plugins/net/upnp/src/etc/inc/plugins.inc.d/miniupnpd.inc

Lines 42 to 45 in 85f1bb9

$fw->registerAnchor('miniupnpd', 'rdr');

$fw->registerAnchor('miniupnpd', 'fw');

$fw->registerAnchor('miniupnpd', 'nat', 0, 'head');

$fw->registerAnchor('miniupnpd', 'binat');

In the core removal from 2017 it only had rdr/fw opnsense/core@44e4ae85c04e7dd which is probably the original state of it.

The other two were added in 2022: #3165

And what do you think of this wording addition in the UI help? Allow adding port maps for non-requesting IP addresses; normally disabled for security

Normally we either hide these things under an advanced toggle (not possible in legacy code) or we use a simple note "Use with care." if it's security relevant. The best way is to not offer the option if it's not good. ;)

Cheers,
Franco

Self-Hosting-Group · 2026-02-25T09:36:22Z

In the core removal from 2017 it only had rdr/fw opnsense/core@44e4ae85c04e7dd which is probably the original state of it.

The other two were added in 2022: #3165

It's still not clear why it's needed. I removed all but kept one registration in the PR.

Normally we either hide these things under an advanced toggle (not possible in legacy code) or we use a simple note "Use with care." if it's security relevant. The best way is to not offer the option if it's not good. ;)

Yes ;-) But then this user case, for which it was implemented, is not supported: https://redirect.github.com/opnsense/plugins/issues/4608.

fichtner · 2026-02-25T09:39:23Z

I don't know. Looking over the fence I see this in pfSense and I'm inclined to leave it as is for lack of a reason to pull support for something that doesn't matter in practice.

src/etc/inc/filter.inc:         $natrules .= "binat-anchor \"miniupnpd\"\n";
src/etc/inc/filter.inc:         $natrules .= "nat-anchor \"miniupnpd\"\n";
src/etc/inc/filter.inc:         $natrules .= "rdr-anchor \"miniupnpd\"\n";
src/etc/inc/filter.inc:         $rules_temp[] = 'anchor "miniupnpd"';

Self-Hosting-Group · 2026-02-25T10:02:56Z

I just want to tidy things up and know for sure, and remove old code that was not carefully considered when it was added. I'll try to remove it from pfSense as well (since it was taken from there). But if miniupnpd doesn't have a binat in the entire source code, it can't create one either, right?
https://github.com/search?q=repo%3Aminiupnp%2Fminiupnp%20binat&type=code

fichtner · 2026-02-25T10:22:43Z

Adding this is easier than removing in any case. It would be nice to make a feature release on 1.9 without potentially breaking changes first then make a single code change effort around the registration which then can also be testing without interference by the community.

fichtner · 2026-02-25T18:11:58Z

I’m considering dropping my community time for this plugin on grounds of difficult communication with you. I’ve fixed a number of things in your PR and previous submissions and I know that burdening you with review is not as effective as with other plugin contributors because it drags these PRs on for weeks. I’m happy to change my approach out of lack of alternatives within my immediate reach.

Cheers,
Franco

- More specific allow third-party mapping UI option - Remove unnecessary `binat` anchor registration - Fix debug logging not treating `-v -v` (follow-up to 7658677) - Update missed changelog Follow-up to opnsense#5126

PR: opnsense/plugins#5126 (cherry picked from commit 23d3be4)

Self-Hosting-Group force-pushed the complete-improvements branch from 4c98364 to a42ac1d Compare January 9, 2026 06:20

fichtner self-assigned this Jan 20, 2026

fichtner reviewed Jan 20, 2026

View reviewed changes

Comment thread net/upnp/src/etc/inc/plugins.inc.d/miniupnpd.inc Outdated

fichtner reviewed Jan 20, 2026

View reviewed changes

Comment thread net/upnp/Makefile Outdated

fichtner reviewed Jan 20, 2026

View reviewed changes

Self-Hosting-Group force-pushed the complete-improvements branch 5 times, most recently from a42ac1d to 74fc831 Compare January 27, 2026 07:50

net/upnp: complete service improvements

65199d4

Self-Hosting-Group force-pushed the complete-improvements branch 5 times, most recently from 74fc831 to 65199d4 Compare January 29, 2026 05:00

Self-Hosting-Group marked this pull request as ready for review January 29, 2026 08:26