Currently the STUN CGNAT filtering test on pfSense cannot work without adding a special firewall rule. Since I could upgrade miniupnpd on FreeBSD ports to 2.3.9, the new STUN option allow-filtered bypasses the current positive filtered CGNAT test result. I would suggest to now set this in pfSense unconditionally (even without custom option) to not disable the service for IPv4 if this test fails.

Only this would have to be set: $config_text .= "ext_perform_stun=allow-filtered\n";

Only this would have to be set: $config_text .= "ext_perform_stun=allow-filtered\n";

As I understand, this shouldn't be needed provided that the STUN server works as intended. Either way, let's keep this PR for text-only changes since behavior changes are unlikely to make it in 2.8.0.

As I understand, this shouldn't be needed provided that the STUN server works as intended. Either way, let's keep this PR for text-only changes since behavior changes are unlikely to make it in 2.8.0.

No, it's about the default rules in pfSense. For the CGNAT filtering test, miniupnpd opens four random ports and checks for an inbound connection using STUN, which fails by default. This is a temporary fix until we open all (?) UDP ports on the router, I don't think this is not a good idea. Regarding the daemon, I'm considering implementing a straightforward solution that would restrict the range of ports checked to a smaller range. However, the final solution I'm thinking of would require the daemon to open and close these ports for the test itself, without range restriction.

Am I right in thinking that the 2.3.9 daemon update will be in 2.8.0, main branch?
https://github.com/pfsense/FreeBSD-ports/tree/main/net/miniupnpd

Am I right in thinking that the 2.3.9 daemon update will be in 2.8.0, main branch?

Unfortunately that happened after 2.8.0 was already branched. As of now both devel and 2.8.0 are on 2.3.7 hence most likely 2.8.0 will be released with its current version. It's possible for the package to be updated post-release though that's normally reserved for critical issues. I'd expect it to be in the release after instead, e.g. 2.8.1.

However, the final solution I'm thinking of would require the daemon to open and close these ports for the test itself, without range restriction.

Yes, the tests should automatically open those ports in pf like it would normally for port mappings.

But adding Allow Third-Party Mapping?

Indeed it should be its own PR with its own redmine that can be considered post 2.8.0, e.g. 2.8.1. Thanks for the link, the reasoning given there makes sense:

My reasoning for this is to allow upnp port forwarding of kubernetes services where the client requesting the port forward will not have the same IP as that in the request.

Thanks for the explanations.

What if I create a separate commit for the text changes that are to be adopted now? You could then cherry-pick this commit while keeping the second and the PR open. This would enable Allow Third-Party Mapping be added later. This name is also used in the branch name of the PR. Would that be possible?

Sounds fine to me.

As I understand, this shouldn't be needed provided that the STUN server works as intended. Either way, let's keep this PR for text-only changes since behavior changes are unlikely to make it in 2.8.0.

Just to make sure we have understood each other correctly:
Just adding the UI option Allow Third-Party Mapping does not change the behaviour. It only changes the behaviour when the option is selected. (It was referring to the allow filtered option).

Yep. Preferably feature implementations should have their own commit and be separated from unrelated changes, hence the separate redmine and PR from simple text changes (which can potentially be merged without an associated redmine).

There are still comments which have not been addressed - I've also added some new comments as well.

There are still comments which have not been addressed - I've also added some new comments as well.

Which changes would you like to see removed?

I would like redmine feature request created specifically for the feature commit and a PR dedicated for that. It can remain on this PR and the rest of the changes moved to a different one, or vice versa. For the text changes, I'm referring to the currently unresolved conversations on this PR.

I appreciate the work, thank you!

• Remove the changes mentioned in this PR along with the new changes in the service-fixes branch (the IPv4 and <default_value>3478</default_value> diffs).
• Create a redmine issue for each PR here https://redmine.pfsense.org/projects/pfsense then reference the ID in the commit title; e.g. for this PR make it "UPnP IGD & PCP: Add Allow Third-Party Mapping UI option. Implement #00000". Make sure each PR has commits squashed.
• Updates to the public documentation are handled on redmine here https://redmine.pfsense.org/projects/pfsense-docs

Remove <default_value>3478</default_value>

However, the STUN port has not been necessary since last year's PR (bf31326). So why is it still required? It is also automatically deleted from the UI after the first save.

Create a redmine issue for each PR here https://redmine.pfsense.org/projects/pfsense then reference the ID in the commit title; e.g. for this PR make it "UPnP IGD & PCP: Add Allow Third-Party Mapping UI option. Implement #00000". Make sure each PR has commits squashed.

Since I don't have a redmine account, could you please create the issues? (commits squashed)

I just created the second PR and added this:
Arrange Advanced Settings options and add IGD Settings

... and updated the docs.netgate.com updates branch:
https://github.com/Self-Hosting-Group/pfsense/tree/doc-updates

the STUN port has not been necessary since last year's PR

I forgot about that; it's fine then. Just make sure to include a note about this in the commit message.

Here's the redmine for this feature request; make sure to update the commit message with the redmine issue ID:
https://redmine.pfsense.org/issues/16273

Done