pfSense

the game in question is "For Honor", but im pretty sure it affects any game that uses peer to peer matchmaking. There is also an issue with being the host, but that may be a hard limitation that cannot be overcome, unsure.

Hi All,

I have experienced the same issue as reported in the bug descrip.

I have also discovered when searching the net for a solution that many other folks have too, all without solutions. I have followed the guides available which covers the configurations listed by the original bug descrip and gives me open NAT as reported on all the xbox consoles (3 in total).

However, when playing multiplayer from with LAN network using the same game, the second and subsequent xboxes to be connected always fails to connect to the game lobby.

With only one xbox there is no issue connecting and playing.

When playing different game titles at the same time there are no issues connecting and playing

Access to the lobby fails only for the second connected xbox console when playing the same title concurrently.

As a test, I replaced the pfsense firewall with an off the shelf generic router with uPnP enabled and immediately all xboxes are able to connect. No other settings were changed on the network.

I have a basic knowledge, but I am more than happy to help do my part to help resolve this issue. I'd rather not replace pfsense for all the other benefit it brings on account of the occasional xbox game with my son.

Seen this on Call of Duty WW2, Titanfall 2 and now Apex Legends. I have no doubt that it affects other titles too.

As a workaround I am going to try putting the second console in a DMZ.

Thanks,
CV8R

Jim Pingle wrote:

AFAIK This is because last I looked, miniupnpd doesn't support its "masquerade" options on FreeBSD/pf like it does on Linux/netfilter. When it is set to masquerade, it sets up an outbound (snat/source nat) mapping to maintain a static source port for the same port requested by the client. Without that, you only get inbound NAT, and if you setup static port on outbound NAT you're only likely to get a single console working as expected.

I doubt there is anything we can do here unless someone adds support for that to miniupnpd

I see it may have been updated in miniupnpd for FreeBSD. How soon can this me imported into pfsense?:

https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/Changelog.txt
$Id: Changelog.txt,v 1.458 2020/03/29 09:07:37 nanard Exp $

2020/03/29:
Fix FreeBSD build

That isn't relevant to this feature. It's a different FreeBSD issue. I don't see anything about masquerade being added to pf.

Jim Pingle wrote:

That isn't relevant to this feature. It's a different FreeBSD issue. I don't see anything about masquerade being added to pf.

Looks like there is some progress on this:
"netfilter: addmasqueraderule() even if internal/external ports are the same"
https://github.com/miniupnp/miniupnp/commit/e49d44f700355552c45a95c1e067e4a815479557

I hope this gets patched in as a hotfix or something soon - many people have been waiting on this for a long time!

If it ends up working for you, would you provide it in a way that I could apply it using the System Patches package? Would be good to update this thread as well https://github.com/miniupnp/miniupnp/issues/413

Marc05 M wrote:

Looks like there is some progress on this:
"netfilter: addmasqueraderule() even if internal/external ports are the same"
https://github.com/miniupnp/miniupnp/commit/e49d44f700355552c45a95c1e067e4a815479557

I hope this gets patched in as a hotfix or something soon - many people have been waiting on this for a long time!

That still isn't adding masquerade support for PF. It's not related.

Joel Samson wrote:

Kind of ridiculous this has has been open for nearly 3 years and nothing, I am in the process of setting up my build server to compile this above and manually install it over the pfsense base version using the instructions found here: https://docs.netgate.com/pfsense/en/latest/packages/installing-freebsd-packages.html?highlight=pkg as I no longer have time to wait, either a solution is applied or I move back to Untangle.

You need to advocate to miniupnpd for them to add support for masquerade to their PF code. It's a missing feature in miniupnpd, not much we can do about that.

Jim Pingle wrote:

Marc05 M wrote:

Looks like there is some progress on this:
"netfilter: addmasqueraderule() even if internal/external ports are the same"
https://github.com/miniupnp/miniupnp/commit/e49d44f700355552c45a95c1e067e4a815479557

I hope this gets patched in as a hotfix or something soon - many people have been waiting on this for a long time!

That still isn't adding masquerade support for PF. It's not related.

Joel Samson wrote:

Kind of ridiculous this has has been open for nearly 3 years and nothing, I am in the process of setting up my build server to compile this above and manually install it over the pfsense base version using the instructions found here: https://docs.netgate.com/pfsense/en/latest/packages/installing-freebsd-packages.html?highlight=pkg as I no longer have time to wait, either a solution is applied or I move back to Untangle.

You need to advocate to miniupnpd for them to add support for masquerade to their PF code. It's a missing feature in miniupnpd, not much we can do about that.

To be fair, that is already done as found here: https://github.com/miniupnp/miniupnp/issues/413 and the change discribed above does seem to be related.
Otherwise, if you have another feature missing not identified in that Github change for miniupnpd, then YOU should request the change to them, as clearly it's an open request here for as long as 3 years and you have still not reached out to the vendor?

Sounds like some slacking on some side. Defiantly not the client side of your software lmao.

Nothing on that bug report mentions pf, all of the example commands are for Linux. It may be about masquerade mode issues in general but it doesn't appear to be specifically doing anything for pf.

Hi Jim. Given you likely understand the issue much better than I, would you help me in making the request necessary to resolve this? What exactly should be requested - would it just be creating a feature request in the miniupnp repo asking for "add support for masquerade to their PF code" and nothing else?

Marc05 M wrote:

Hi Jim. Given you likely understand the issue much better than I, would you help me in making the request necessary to resolve this? What exactly should be requested - would it just be creating a feature request in the miniupnp repo asking for "add support for masquerade to their PF code" and nothing else?

I would agree with this. I am willing to submit the request on Github for pfsense specific issues.
But we need to better understand what to request, what support needs to be added specifically for PFsense?

While those changes are specific to Linux, PFsense is FreeBSD based (Unix-based) and you would expect the feature to be added/migrated fairly easily if we can get a clear picture of what needs to be added/ported to the pfsense (unix-based) version.

Thanks,

Marc05 M wrote:

Hi Jim. Given you likely understand the issue much better than I, would you help me in making the request necessary to resolve this? What exactly should be requested - would it just be creating a feature request in the miniupnp repo asking for "add support for masquerade to their PF code" and nothing else?

I'm not sure what detail they would need beyond "Add masquerade feature to pf support" or something along those lines. Currently the masquerade references are all inside their netfilter code which is only on Linux.

The request is not specific to pfSense, but pf in general (So, primarily FreeBSD and OpenBSD).

I don't see anything like that in the linked reference. Only confirmation that the issue/commit only apply to netfilter.

And no, an update for miniupnpd wouldn't be in the package manager. It's a base system package and would only be updated with a new release.

Joel S wrote:

He specifically comments that "I'm stupid, e49d44f is only for netfilter :( it will change nothing for pf :( I don't know how I forgot this issue was about netfilter in the 1st place."

Obviously, he will ask for a new bug report outside of the netfilter one, or simply make the commit change from that existing bug now that he realizes his mistake that the changes are only for linux and not Pfsense.

I saw that, but nothing in that implies any action for pf. Only that the issue is about netfilter. There is no masquerade code at all for pf, they'd have to completely port over the feature. You're reading an awful lot between the lines there that isn't even implied. Kudos to you for being optimistic, but I'm not holding my breath on it happening any time soon.

I hope you generally understand that once this is done, this issue then falls directly on you to update the package on the base system if it's not available as an update.
Not sure why it sounds like you keep trying to redirect this, it's coming your way either way within a few days at most (Likely Thursday it will be resolved). At which point this thread will become the highlight, not: https://github.com/miniupnp/miniupnp/issues/413

When they have it in their code base and we know it works on FreeBSD+pf, it will find its way into a pfSense release. We redirect the issue to miniupnpd because they're the ones that need to add the feature first. It's entirely up to them, until they include it in a release.

A bit off-topic:

It's funny that throughout all of the years, many people have encountered and posted about the issue in one way or another, and only in the last few days has there been any semblance of progress.

Thank you Joel for all of the follow-up, and please keep it up. It's appreciated, even if you are just copying and pasting.

Thank you Jim for telling us what to do :D No doubt there are plenty of other things in need of attention. I hope this issue finally gets its spotlight after being background noise for so long.

Hi, I'm also interested in this issue and really glad to see there's an active effort to get it resolved. Thanks Joel, Marc, and Jim!

I'm posting because I think it may help myself and others to clearly understand the issue.
Based on comments in the linked Github issue, past forum posts, and how long this issue has been around, I think users have been at least a little confused about what exactly the problem is.

• To easily allow multiple devices to play the same online games, pfsense needs to be able to create an inbound and outbound NAT rule for every UPnP port forward.
• The version of the uPnP library used by pfsense only allows creating inbound NAT rules.

Jim did sort of say as much in the beginning, I'm just not sure if my reading is correct.

Jim Pingle wrote:

When it is set to masquerade, it sets up an outbound (snat/source nat) mapping to maintain a static source port for the same port requested by the client. Without that, you only get inbound NAT, and if you setup static port on outbound NAT you're only likely to get a single console working as expected.

"Masquerade" has been thrown around a lot in this thread, and it's pretty confusing, especially if the issue is more about having a two-way mapping.
nefilter's iptables MASQUERADE option just allows making an outbound NAT (SNAT) rule without specifying the public external IP address.
I can see why this is necessary since many users might have dynamic IP addresses, but it does look like pf can do the same thing—pulling an address from an interface (eth0 in this example).

IPTABLES
iptables -t nat -a POSTROUTING -s 1.2.3.4 -o eth0 -j MASQUERADE

PF
nat on eth0 from 1.2.3.4 to any -> (eth0)

So is the pf-based miniupnpd just missing some internal or API feature that's in the netfilter-based version or does pf itself actually not have a way to do what iptables does?
There's a big difference if this some functional gap between netfilter and pf or something of an oversight/backlogged feature in miniupnpd.

I bought the SG-3100 because I wanted to have the BiS router for epic gaming moments

Turns out one of the "features" of the wonderful pfsense software is that two PCs can't play Call of Duty at the same time together

What was supposed to be an epic moment is actually an epic fail

I spent my Trump bucks on this crap

Cameron O wrote:

So is the pf-based miniupnpd just missing some internal or API feature that's in the netfilter-based version

pf is capable of doing this kind of NAT, it's the same kind of NAT rules people set manually to make single consoles work (static port).

The problem is that miniupnpd doesn't have any pf code to set that up (no masquerade code for pf in miniupnpd)

Jim Pingle wrote:

pf is capable of doing this kind of NAT, it's the same kind of NAT rules people set manually to make single consoles work (static port).

The problem is that miniupnpd doesn't have any pf code to set that up (no masquerade code for pf in miniupnpd)

Marc05 M wrote:

A bit off-topic:

It's funny that throughout all of the years, many people have encountered and posted about the issue in one way or another, and only in the last few days has there been any semblance of progress.

Thank you Joel for all of the follow-up, and please keep it up. It's appreciated, even if you are just copying and pasting.

Thank you Jim for telling us what to do :D No doubt there are plenty of other things in need of attention. I hope this issue finally gets its spotlight after being background noise for so long.

Opened a new issue for this pf masquerade feature implementation at the dev's request, it can be found here: https://github.com/miniupnp/miniupnp/issues/448
The other issue linked was cleaned up to keep it related to Netfilter, as expected though this is still moving, I was not surprised he asked for a new issue report as I mentioned above.
Maybe Jim can review the new issue created, and provide feedback on anything or any details missing which I can add :)

Thanks again all!
Happy to see this moving in the right direction finallllllyyyy!!!

Jim Pingle wrote:

pf is capable of doing this kind of NAT, it's the same kind of NAT rules people set manually to make single consoles work (static port).

The problem is that miniupnpd doesn't have any pf code to set that up (no masquerade code for pf in miniupnpd)

miniupnpd dev would like the following information from our setup:

the AddPortMapping() requests done
the subsequent pf rules created by miniupnpd
the ones that would be expected so the traffic flows properly and the game works on all xbox's

Which commands can I use to get the first 2 results? I can at least provide that to him to start.
As for the rules/flows to be expected, we may need to wait to see what is actually happening...

Thanks again guys.
Joel S.

Jim Pingle wrote:

pf is capable of doing this kind of NAT, it's the same kind of NAT rules people set manually to make single consoles work (static port).

The problem is that miniupnpd doesn't have any pf code to set that up (no masquerade code for pf in miniupnpd)

He also mentioned how it looks like pf used in pfSense is an old version as rdr-anchor are not used since OpenBSD 4.7 (2010)

Hello, I'm miniupnp main author.

The user Joel S came from here to open an issue on https://github.com/miniupnp/miniupnp/issues/448

From the start he showed no understanding of the problem, just asking for "high priority" fixing of a bug he was unable to expose clearly.

He then became very disrespectful, requiring me to work on his problem and opening several duplicate issues.
In 15 years, I have not seen such disrespect behavior from a "bug reporter".

The pfSense community has given a lot to miniupnp over the years, that's a shame that today such a spoiled boy wastes our time.

To come back to the issue itself:
I have seen no detailed description of the problem (AddPortMapping requests from the consoles, the pf rules that are produced, etc.) but I guess it has something to do with the inability of miniupnp/pf to make "bidirectional port mappings" it is possible to do with netfilter : ie when there is a port mapping added for external port 1111 to internal port 2222. Outbound UDP packets from port 2222 are not forced to be translated to source port 1111.
If it is confirmed that is it the real issue here, and if someone is able to produce the pf rules needed, I will be able to implement it in miniupnp pf backend.
But I'm afraid it is a feature currently not available in pf.

The static-port option to nat in pf just works for mapping with same external and internal port, so that source port 2222 is kept and not mapped to a random port.

Regards,

Thomas Bernard

Thomas BERNARD wrote:

Hello, I'm miniupnp main author.

The user Joel S came from here to open an issue on https://github.com/miniupnp/miniupnp/issues/448

From the start he showed no understanding of the problem, just asking for "high priority" fixing of a bug he was unable to expose clearly.

No, I fully understand the problem. In-fact, you show zero understanding of the problem.
I don't understand the solution, there's a difference, which is why we came to you and Jim. Sadly after 3 years this is where we are, still no where with a solution.

He then became very disrespectful, requiring me to work on his problem and opening several duplicate issues.
In 15 years, I have not seen such disrespect behavior from a "bug reporter".

The pfSense community has given a lot to miniupnp over the years, that's a shame that today such a spoiled boy wastes our time.

To come back to the issue itself:
I have seen no detailed description of the problem (AddPortMapping requests from the consoles, the pf rules that are produced, etc.) but I guess it has something to do with the inability of miniupnp/pf to make "bidirectional port mappings" it is possible to do with netfilter : ie when there is a port mapping added for external port 1111 to internal port 2222. Outbound UDP packets from port 2222 are not forced to be translated to source port 1111.
If it is confirmed that is it the real issue here, and if someone is able to produce the pf rules needed, I will be able to implement it in miniupnp pf backend.
But I'm afraid it is a feature currently not available in pf.

The static-port option to nat in pf just works for mapping with same external and internal port, so that source port 2222 is kept and not mapped to a random port.

Regards,

Thomas Bernard

I would agree, I have never found someone so disrespectful to someone simply asking a question and/or for assistance. I love the name calling though, keep it up ;)
Doesn't bother me none, maybe that's all how your french coders are, all with their heads up their ass. Let me help you understand the issue. "pfsense = toi et Jim corrigez le probleme"

I would love for you, no I would dare for you, to show me in the thread where I become disrespectful, at least until you told me to stop "wasting your time".
You and Jim has been wasting everyone's time from the start, if you could of simply talked to each-other as we requested, this wouldn't be an issue, but somehow the last time was in 2010, and since then you guys have been scared of each
other.

We simply want you two to stop ignoring it for over 3 years and start looking into it. Not a hard request.

Finally someone comes out from the darkness and crosses worlds, just had to piss him off a bit but that's fine. I don't care if what Jim is asking for isn't possible or if I don't understand. "THATS WHY YOUR HERE" :D
Now if you and Jim come to the conclusion this isn't a bug and everyone's configuration is wrong, at least it will become public knowledge. But I am pretty sure that is not the case ;) And you will need to prove it with all the users with the issue.

Get off your high horse bud, start being respectful to people asking you questions if you don't want to be shown disrespect, and don't kill the messenger, as you said all I do is copy and paste.
If it doesn't make sense, don't blame me. Blame the people asking me to bring it to you and telling us what to say (Jim).

But you don't deserve any respect for closing an issue early and shitting on the messenger. I am not impressed rolf. I'll be impressed when you do your job correctly and drop the god complex.

I swear you don't even read, you just slam the ban button, which sadly will not work.
Maybe if you and Jim and discussed this conversation 3 years ago, I wouldn't need to be a dick to get you to do stuff ;) But I don't mind it. It's moving ;)

Thanks,
Joel S.

Joel,

Please stop. That kind of unhelpful dialog is unproductive and not welcome here, and is getting in the way of any meaningful discussion about solving the problem.

Thomas BERNARD wrote:

I have seen no detailed description of the problem (AddPortMapping requests from the consoles, the pf rules that are produced, etc.) but I guess it has something to do with the inability of miniupnp/pf to make "bidirectional port mappings" it is possible to do with netfilter : ie when there is a port mapping added for external port 1111 to internal port 2222. Outbound UDP packets from port 2222 are not forced to be translated to source port 1111.
If it is confirmed that is it the real issue here, and if someone is able to produce the pf rules needed, I will be able to implement it in miniupnp pf backend.
But I'm afraid it is a feature currently not available in pf.

OK, it's possible I'm misunderstanding what that does. I thought it setup an outbound rule which did the opposite of that, which translated outbound packets from the target to use the same port requested for UPnP. So for example:

S:12345->E:1111->C:2222
C:X->E:1111->S:Y (for new connections not replies on the state created for 1111->2222 since those would always reply from 2222->1111)

The pf rule for that would look something like this (client 10.6.0.11, ext addr 198.51.100.6, server 1.2.3.4):

nat on $WAN inet proto tcp from 10.6.0.11/32 to 1.2.3.4/32 -> 198.51.100.6/32 port 1111

Though I could see that failing in some cases if an overlapping state already exists for an inbound connection. It would only work for a single concurrent outbound connection to the same remote server, additional connections would fail since the external state portions would conflict.

From your last comment it sounds like what the netfilter rules do is to allow the replies to have a different source port on the way out, sort of like:

S:12345->E:1111->C:2222
C:2222->E:<some random port>->S:12345

I don't see a way to that in pf but I'm not sure I'm reading your statement properly. That doesn't seem to make sense, since the server would typically reject replies from a source port it wasn't actively communicating with.

Do you have an example set of netfilter rules/chains which shows the type of rules you are describing? That might help make it more clear since I'm fairly certain the problem is my (lack of) understanding.

We have not enough precise details on the issue :
What AddPortMapping requests the XBoxes are doing and what traffic they are expecting.

It is important to note that everything applies only to UDP, not TCP.
My guess is that somehow they are expecting their outbound UDP traffic to be translated to a precise port.
When opening a port mapping with external port 1111 and internal port 2222.
If that is the Remote that sends the 1st packet to <public ip>:1111 everything works fine.
subsequent packets sent by the XBox to the remote will be translated with a source port of 1111 (existing "UdP connection")

But if that is XBox that sends the 1st packet to a remote host, the source port would either be kept as 2222 (static-port set) or a random one (non pre-existing "UDP connection")

With netfilter/iptables, we are using SNAT to force translation to the wanted source port.

Joel S wrote:

Jim Pingle wrote:

Joel,

Please stop. That kind of unhelpful dialog is unproductive and not welcome here, and is getting in the way of any meaningful discussion about solving the problem.

I will gladly stop now that progress is being made... Observing only for now. The fact is I had to do this, or we would be waiting another 2 years as you said, "You need to advocate to miniupnpd for them to add support for masquerade to their PF code" and we were tired waiting for nothing.
It was helpful in that regard :)

Thanks!
Joel S.

I hope you will someday stop believing we are at your service. As far as I know, Jim is not your employee. He surely has more urgent issues than you and your friends not being able to play your favorite video games.

The fact that you believe that progress is being made just shows how deeply you don't understand the issue.
And the fact that you believe it is thanks to your aggressive behavior proves that you are not going to improve it anytime.

Such disrespect ruins the motivation of people involved in OSFS projects.

I removed the irrelevant comments made after the warning and locked their account. Further comments unrelated to the technical nature of the issue alone will also be removed. Such comments only further erode the available time developers have to work on actual problems.

I've been watching this bug for the past 2 years and am excited that there is some traction on it. Though I'm very disappointed that it took such a sour turn. I would love to be of assistance on trying to figure out what exactly is going on. To note first I currently do not have an active PfSense box to test but I can likley get one up and running to help with any testing.

At this point, what is needed to try and further troubleshoot this issue? I will be more than happy to assist the best I can.

I do know that this issue is not isolated to Xbox if that matters. It applies to PC aswell, really any game service that uses matchmaking services over UDP. If it would help, I can setup 2 devices behind a pfsense router and attempt to have them connect to the same matchmaking service, I can do a full packet capture on all devices. Would there be any other details needed to try and troubleshoot?

Dakota Marshall wrote:

At this point, what is needed to try and further troubleshoot this issue? I will be more than happy to assist the best I can.

I do know that this issue is not isolated to Xbox if that matters. It applies to PC aswell, really any game service that uses matchmaking services over UDP. If it would help, I can setup 2 devices behind a pfsense router and attempt to have them connect to the same matchmaking service, I can do a full packet capture on all devices. Would there be any other details needed to try and troubleshoot?

• We first need the AddPortMapping requests sent by the 2 (or more) devices. (you can capture traffic on the miniupnpd HTTP port).
  if you run miniupnpd in debug mode, it will also send theses info to syslog.

• then you can check which pf rules are created.
  depending on pf version, they are visible with
  pfctl -a miniupnpd -s rules
  and/or
  pfctl -a miniupnpd -s nat
  (if the miniupnpd version compiled for pfSense does use the "miniupnpd" anchor)

• then you can capture all traffic on your lan on the redirected port so we would know if game send packets to a remote host before it receives any from the same host.

After that we'll have confirmation of the diagnostics. But still no solution to make outgoing UDP packets translated with the right source port.

I can test this right now. I currently have two PCs unable to play Call of Duty together behind a pfSense 2.4.4-RELEASE-p3 box via upnp.

I have configured:

System -> Advanced -> Firewall & NAT -> Network Address Translation -> NAT Reflection mode for port forwards = "Pure NAT"
System -> Advanced -> Firewall & NAT -> Network Address Translation -> Enable automatic outbound NAT for Reflection = "True"
Firewall -> Aliases -> IP -> Firewall Aliases IP = [{"UPnPGames": ["192.168.1.48", "192.168.1.49", "192.168.1.50"]}]
Firewall -> NAT -> Outbound -> Outbound NAT Mode -> Mode = "Hybrid Outbound NAT rule generation"
Firewall -> NAT -> Outbound -> Mappings = [{"Enabled": True, "Interface": "WAN", "Source": "UPnPGames", "Source Port": "*", "Destination": "*", "Destination Port": "*", "NAT Address": > "WAN address", "NAT Port": "*", "Static Port": True, "Description": ""}]
Services -> UPnP & NAT-PMP -> UPnP & NAT-PMP Settings -> Enable = "True"
Services -> UPnP & NAT-PMP -> UPnP & NAT-PMP Settings -> UPnP Port Mapping = "True"
Services -> UPnP & NAT-PMP -> UPnP & NAT-PMP Settings -> Log Packets = "True"
Services -> UPnP & NAT-PMP -> UPnP & NAT-PMP Settings -> Default Deny = "True"
Services -> UPnP & NAT-PMP -> UPnP Access Control Lists -> ACL Entries = ["allow 0-65535 192.168.1.48/32 0-65535", "allow 0-65535 192.168.1.49/32 0-65535"]

My PC (.48) was able to connect with "Open" NAT. My brother's PC (.49) was unable; the game launches, then complains that it was unable to connect to the server. His only option from there is to quit to desktop.

Here is the response to `pfctl -a miniupnpd -s rules`:

pass in log quick on re0 inet proto udp from any to 192.168.1.48 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0
pass in log quick on re0 inet proto udp from any to 192.168.1.49 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0
pass in log quick on re0 inet proto udp from any to 192.168.1.49 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0
pass in log quick on re0 inet proto udp from any to 192.168.1.49 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0
pass in log quick on re0 inet proto udp from any to 192.168.1.49 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0

Here is the response to `pfctl -a miniupnpd -s nat`:

rdr log quick on re0 inet proto udp from any to any port = 3074 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.48 port 3074
rdr log quick on re0 inet proto udp from any to any port = 3148 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074
rdr log quick on re0 inet proto udp from any to any port = 3194 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074
rdr log quick on re0 inet proto udp from any to any port = 3155 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074
rdr log quick on re0 inet proto udp from any to any port = 3162 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074

Here is a pastebin dump of the packet capture, listening on 2189:

https://pastebin.com/24hkmCcJ

Let me know if you want the .cap file, and how you would prefer I deliver it.

Since it seems the redirected port jumps around while the game client (re)tries to get a upnp session, I'm not sure how to listen to traffic on that port without capturing all traffic from my brother's pc on the interface, which is what I have done. I'd be willing to share this directly, but not publicly.

Also, it seems that checking "Log Packets" does not put them in the syslog. After a cursory glance, I don't see that they're being logged at all. If I'm not looking in the right place, let me know.

If you need me to check anything else, I may not be able to until tomorrow. Hopefully this helps.

Connor Ness wrote:

If you need me to check anything else, I may not be able to until tomorrow. Hopefully this helps.

unfortunately it shows that everything is OK when the external port is mapped to the same internal port (3074 => 192.168.1.48:3074)
but it doesn't work for (3148 => 192.168.1.49:3074)

I don't know how to force pf to translate outgoing UDP packets from 192.168.1.49:3074 to src <public ip>:3148

my email address is available here : https://miniupnp.tuxfamily.org/

thank you.

Thank you very much, Thomas. I emailed the captures to you.

For what it's worth, I did have both PC's showing "Open" NAT types, and both were able to join each other's lobby, without upnp. I manually created port forwards and outbound mappings.

For outbound, I had:

192.168.1.48:3074 => WAN:13074
192.168.1.49:3074 => WAN:23074

For port forwards:

ANY:13074 => 192.168.1.48:3074
ANY:23074 => 192.168.1.49:3074

This worked, but my understanding is that this is what upnp should be able to achieve automatically. I'm imagining the process looks something like this:

1. PC1 requests upnp create outbound mapping and port forward for PC1:3074
2. upnp checks that a session is not currently alive for WAN:3074
3. there is no session, so create outbound mapping and port forward for WAN:3074 <=> PC1:3074, and we are done
4. PC2 requests upnp create outbound mapping and port forward for PC2:3074
5. upnp checks that a session is not currently alive for WAN:3074
6. there is a session, deny the request to PC2
7. PC2 requests upnp create outbound mapping and port forward for PC2:3076 (picked from a hat)
8. upnp checks that a session is not currently alive for WAN:3076
9. there is no session, so create outbound mapping and port forward for WAN:3076 <=> PC2:3076, and we are done

From what we're seeing, upnp is indeed creating these sessions, but the client is still unable to connect, so it retries until it decides no connection can be made. But with my manual port forwards and outbound mappings, it works as expected. Would it be worth setting those back up and comparing the entries?

Thomas BERNARD wrote:

unfortunately it shows that everything is OK when the external port is mapped to the same internal port (3074 => 192.168.1.48:3074)
but it doesn't work for (3148 => 192.168.1.49:3074)

I don't know how to force pf to translate outgoing UDP packets from 192.168.1.49:3074 to src <public ip>:3148

That's just a matter of using the right nat on rule.

Taking this specific inbound example:

rdr log quick on re0 inet proto udp from any to any port = 3148 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074

This is the equivalent outbound NAT example:

nat on re0 inet proto udp from 192.168.1.49 port 3074 to any -> (re0) port 3148

The (re0) is a pf macro which expands to the IP address on that interface. You can also explicitly specify the external IP address to use there.

EDIT: I removed some comments after this which were not relevant to the technical part of this discussion. If you want to discuss tangents/related topics, please move that discussion to a forum thread.

thanks, so

nat on re0 inet proto udp from 192.168.1.49 port 3074 to any -> (re0) port 3148

Thomas BERNARD wrote:

thanks, so
[...]
is the additional pf rule that need to be created for outbound traffic when a port mapping (3148 => 192.168.1.49:3074 UDP) is created.

Yes, that's the equivalent "outbound NAT" rule which would mirror the rdr rule. The only possible issue might be that it would be added to a "nat-anchor" instead of the "rdr-anchor". We have a couple NAT anchors (like "natearly") and I'm not sure if we can repeat a name in those to have "miniupnpd" exist in both nat-anchor and rdr-anchor tabs. I'd have to test that out. pf doesn't complain when I load it, but I didn't run a practical test. If the specific anchor names were config options that would be simple to work around either way.

@jim
you can already have a look at what I've done :
https://github.com/miniupnp/miniupnp/pull/455

Thomas BERNARD wrote:

@jim
you can already have a look at what I've done :
https://github.com/miniupnp/miniupnp/pull/455

I'm not terribly familiar with pf code in C but if the result is what you show in your comments that's very promising. Though it shouldn't explicitly need the external IP address on the rule if you use the literal string '(re0)' for interface re0 pf will do the expected thing automatically and internally substitute the address.

Will this be an option behavior or only a compile-time choice? Seems like a good candidate for a command line parameter or config file knob.

I don't know the equivalent of using '(re0)' with the ioctl() API. any pointer will be appreciated.

could you please test https://github.com/miniupnp/miniupnp/pull/455 ?
(my branch pf-nat-rules)

I'm not able to test myself, so I need testers or else I'll never validate theses changes.

I don't know how that might be expressed in the ioctl/API, unfortunately. I've posed the question to some of our other developers and if I turn up anything, I'll pass it along.

I'll see about getting a version compiled with those changes for testing internally, thanks!

According to one of our other developers, the (name) syntax is resolved by pfctl so it isn't in the API. It uses ifa_load() which in turn calls getifaddrs() which appears to be similar to what you're doing already so there probably isn't anything different you need to do.

I disabled IPv6 from the WAN interface as I don't use it anyways.

Now I get this in the logs:

Seems possibly related to: https://redmine.pfsense.org/issues/10398 ?
I added the ext_ip to the "Override WAN address" without any luck here either.

@Jun 2 06:33:11 miniupnpd 26938 no HTTP IPv6 address, disabling IPv6
Jun 2 06:33:11 miniupnpd 26938 Listening for NAT-PMP/PCP traffic on port 5351
Jun 2 06:33:11 miniupnpd 26938 PCPSendUnsolicitedAnnounce() IPv6 sendto(): Bad file descriptor
Jun 2 06:40:05 miniupnpd 26938 ioctl(s, SIOCGIFADDR, ...): Can't assign requested address
Jun 2 06:40:05 miniupnpd 26938 ioctl(s, SIOCGIFADDR, ...): Can't assign requested address
Jun 2 06:40:05 miniupnpd 26938 Failed to get IP for interface pppoe0
Jun 2 06:40:05 miniupnpd 26938 SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jun 2 06:40:05 miniupnpd 26938 PCPSendUnsolicitedAnnounce() sendto(): No route to host
Jun 2 06:40:05 miniupnpd 26938 PCPSendUnsolicitedAnnounce() IPv6 sendto(): Bad file descriptor
Jun 2 06:40:11 miniupnpd 26938 SendNATPMPPublicAddressChangeNotification: sendto(s_udp=10, port=5351): No route to host
Jun 2 06:40:11 miniupnpd 26938 PCPSendUnsolicitedAnnounce() sendto(): No route to host
Jun 2 06:40:11 miniupnpd 26938 PCPSendUnsolicitedAnnounce() IPv6 sendto(): Bad file descriptor@

Thanks!

I started a forum thread for people to share experiences testing this: https://forum.netgate.com/topic/154153/test-request-upnp-fix-for-multiple-consoles-playing-the-same-game-static-port-outbound-nat

Let's keep the discussion there and only put information on this issue which is strictly relevant to the new changes.

please test with miniupnpd-2.2.0-RC1.tar.gz
released on https://miniupnp.tuxfamily.org/files/

Thomas BERNARD wrote:

please test with miniupnpd-2.2.0-RC1.tar.gz
released on https://miniupnp.tuxfamily.org/files/

I take it I have to wait for Jim to make a patched version for us to use in pfSense 2.5.

We have added the 2.2.0-RC1 version of miniupnpd to the repository for pfSense 2.5.0 and so it should be included in snapshots shortly for additional (and easier) testing.

The latest 2.5.0 snapshot now contains miniupnpd-2.2.0.r1,1 for testing

I believe pf is only capable of symmetric NAT. I know pfSense pf is different from FreeBSD pf but I'm curious about this FreeBSD pf patch from 2017 that was intended to implement full cone NAT into pf. The patch was never implemented so I'm wondering without the patch it's potentially not allowing miniupnpd to completely do it's job and instead is having to deal with symmetric NAT only.

https://reviews.freebsd.org/D11137

Interesting read on the different kinds of NAT's dealing with gaming:

http://badmodems.com/Forum/viewtopic.php?t=21

Based on Feedback from testers on the forums, they are stating this is not fixed currently.

https://forum.netgate.com/topic/154153/test-request-upnp-fix-for-multiple-consoles-playing-the-same-game-static-port-outbound-nat/67?_=1610234284323&lang=en-US

I can confirm that this is still a problem in 2.5.0.a.20210129.1122.
I upgraded a school system today from 2.3.x to 2.4.5-p1. Multiple game consoles were able to play prior to the upgrade.
After the upgrade, uPnP only provided one game console with a reservation, and the rest were strict NAT.
Based on this page, I upgraded to the latest snapshot 2.5.0.a.20210129.1122 and it still doesn't work.
I reinstalled 2.3.5.p2 and restored the configuration and multiple game consoles worked again.
I hope this is helpful.

I just updated net/miniupnpd to 2.2.1 so it would be nice to get it tested again after that

I think other than adding the static NAT port entry (which is only for the single port requested by the console for external access with static NAT), it may also be useful to have an option that also automatically adds full static-port mapping entry added to pf via miniupnpd which ensures that any other dynamic ports used by the console will be also be statically mapped instead of being randomised by NAT. This is especially the case with Nintendo switch, which without static-port map will result in NAT Type D and can be resolved by doing static port map which changes it into NAT Type B [https://www.reddit.com/r/splatoon/comments/6rtgmg/nat_types_and_connection_problems_explained/] and also topic [https://forum.netgate.com/topic/112631/nintendo-switch-needs-static-port-on-its-outbound-nat/35].

The corresponding pf rule should be something like...

nat on (wan-if) inet from (lan-ip) to any -> (wan-ip) static-port

The second "problem" I noticed is that uPnP mapped ports have its source address rewritten by NAT, while manual port-forwarded ports is a pure redirect. Is it possible to have miniuPnP add the port-forwarding entry without NAT? It is possible that some consoles require the WAN source address and doesn't work well with the NATed internal gateway IP address (which I presume is automatically added by 'Automatic outbound NAT rule generation' NAT mode configuration)?

YP Lo wrote:

Is it possible to have miniuPnP add the port-forwarding entry without NAT?

Can you explain in more detail what source -> destination you're seeing now, and what you believe would work better?

YP Lo wrote:

I think other than adding the static NAT port entry (which is only for the single port requested by the console for external access with static NAT), it may also be useful to have an option that also automatically adds full static-port mapping entry added to pf via miniupnpd which ensures that any other dynamic ports used by the console will be also be statically mapped instead of being randomised by NAT. This is especially the case with Nintendo switch, which without static-port map will result in NAT Type D and can be resolved by doing static port map which changes it into NAT Type B [https://www.reddit.com/r/splatoon/comments/6rtgmg/nat_types_and_connection_problems_explained/] and also topic [https://forum.netgate.com/topic/112631/nintendo-switch-needs-static-port-on-its-outbound-nat/35].

That isn't possible. First, because the Switch doesn't request UPnP so there is nothing to trigger the setup, and second, adding static port for more than one internal host is going to break for the second console, so it's best to do that manually.

The second "problem" I noticed is that uPnP mapped ports have its source address rewritten by NAT, while manual port-forwarded ports is a pure redirect. Is it possible to have miniuPnP add the port-forwarding entry without NAT? It is possible that some consoles require the WAN source address and doesn't work well with the NATed internal gateway IP address (which I presume is automatically added by 'Automatic outbound NAT rule generation' NAT mode configuration)?

That isn't correct. UPnP rules only affect connections on WAN, so the net result is exactly the desired output. It wouldn't NAT anything to an "internal" gateway unless your configuration is very broken. UPnP sets up a port forward on WAN and (now) an additional outbound NAT rule for new connections leaving WAN using the same port requested by UPnP.

Sounds like you may have a misconfiguration, post on the forum to discuss and figure it out.

I can confirm that this is still a problem in 2.5.0.a.20210129.1122.
I upgraded a school system today from 2.3.x to 2.4.5-p1. Multiple game consoles were able to play prior to the upgrade.
After the upgrade, uPnP only provided one game console with a reservation, and the rest were strict NAT.
Based on this page, I upgraded to the latest snapshot 2.5.0.a.20210129.1122 and it still doesn't work.
I reinstalled 2.3.5.p2 and restored the configuration and multiple game consoles worked again.
I hope this is helpful.

Last night we repeated this experiment with the latest snapshot 2.5.0.a.20210204.2250

Again:
1. Made a backup of the current system running 2.3.5.p2 after confirming that multiple game consoles were operating in "open" firewall status
2. Upgraded to 2.5.0.a.20210204.2250 making no other changes to the configuration, and only one game console was able to operate in "open" status
3. Reinstalled 2.3.5.p2 and restored configuration, again multiple game consoles worked in "open" status
4. Just for kicks I inserted a Netgear Nighthawk R8000 and it also allowed the game consoles to all work in "open" status.

The configuration is a simple layer 2 Ethernet network with a pfSense machine (Intel i5 with an SSD and 8 gigs RAM) connected to a Comcast modem with a single WAN IP address.

We aren't making any configuration changes, and I confirmed that the UPnP configuration is the same on 2.5.0.a.20210204.2250. Are there any changes that we need to make?
We can keep trying this every week until it works. If there is anything I can do or provide that will help diagnose and fix this problem, please let me know. Thank you

Will this work on 2.5.1, as still having the same issue.

would love to test on 2.5.1 as i have 3 pcs all with COD that want to use port 3074 and upnp just wont do it for more than one client.

Likely not as miniupnp hasn't changed afaik.

If you have time, find a copy of 2.4.0 and test it. It may help narrow down where the issue is.

Marc 05 wrote:

Likely not as miniupnp hasn't changed afaik.

FYI here is a link to where they are discussing this problem in miniupnp.
https://miniupnp.tuxfamily.org/forum/viewtopic.php?t=393&highlight=xbox
Until they figure out how to get it working in miniupnp, it won't work in pfSense.
Right now it seems as though they have decided it's a problem with Xbox and no further work is being done.
I know this isn't true because a cheap Netgear wifi router works fine with a dozen Xbox game consoles behind it.

Polar Nerd wrote:

Marc 05 wrote:

Likely not as miniupnp hasn't changed afaik.

FYI here is a link to where they are discussing this problem in miniupnp.
https://miniupnp.tuxfamily.org/forum/viewtopic.php?t=393&highlight=xbox
Until they figure out how to get it working in miniupnp, it won't work in pfSense.
Right now it seems as though they have decided it's a problem with Xbox and no further work is being done.
I know this isn't true because a cheap Netgear wifi router works fine with a dozen Xbox game consoles behind it.

I gave up 2 years ago and moved to Untangle Firewall. Worked instantly for all the xboxes in our house. All my research pointed to miniupnd on any BSD based OS.

I gave up 2 years ago and moved to Untangle Firewall. Worked instantly for all the xboxes in our house. All my research pointed to miniupnd on any BSD based OS.

My biggest clients are about to jump because they need this feature to work, and they're too afraid of security holes if they roll back to an older version of pfSense when UPnP was working. That's the disadvantage with open-source software, though-- everything about pfSense is excellent except what they are forced to inherit from BSD.

I've managed to get two XBoX's and a gaming PC on my network and one Xbox and the PC to connect to and play the same game at the same time (War Thunder). I found UPnP didn't work, but I followed [[https://forums.lawrencesystems.com/t/pfsense-and-multiple-xbox-ones-open-nat-guide/2409]] to manually connect and show open NAT. Both XBox's have access to live at the same time as well.

Charles Jackson wrote:

I've managed to get two XBoX's and a gaming PC on my network and one Xbox and the PC to connect to and play the same game at the same time (War Thunder). I found UPnP didn't work, but I followed [[https://forums.lawrencesystems.com/t/pfsense-and-multiple-xbox-ones-open-nat-guide/2409]] to manually connect and show open NAT. Both XBox's have access to live at the same time as well.

Thank you for the workaround. I'm going to play with this some more.

I have two clients (schools) who have game development labs with many game consoles behind the firewall, and if they are behind a cheap Netgear router, it simply works, with no special configuration. So I have isolated both labs behind Netgears until I can come up with a working Pfsense solution so the clients can have more visibility and control over the lab's Internet use. I've been hopeful that Pfsense can be the solution, but Pfsense depends on the developers of miniupnp to fix this problem so I'm not sure if will be fixed any time soon.

Charles Jackson wrote:

I've managed to get two XBoX's and a gaming PC on my network and one Xbox and the PC to connect to and play the same game at the same time (War Thunder). I found UPnP didn't work, but I followed [[https://forums.lawrencesystems.com/t/pfsense-and-multiple-xbox-ones-open-nat-guide/2409]] to manually connect and show open NAT. Both XBox's have access to live at the same time as well.

As soon as i read "Make sure “Static Port” is ticked" then i stop reading because this is no feasible workaround. This will definitly limit you to 1 Device at a time on many Multiplayer Games like CS, BF, PUBG etc at the same Server. This may work for Game Console to see open NAT/moderate NAT but not much more.

Here's something mentioning IGDv2 being the problem in miniupnp, and solving it by reverting to IGDv1:
https://www.reddit.com/r/xboxone/comments/6j3cwv/may_have_solved_the_xbox_one_issues_with_some/

And an Xbox engineer mentions what I infer as IGDv2 not being implemented properly to be backward compatible:
https://www.reddit.com/r/xboxone/comments/6j3cwv/may_have_solved_the_xbox_one_issues_with_some/djbhzk2

OpenWRT has this option for whatever their implementation is, which resolved it for a ps4 player:
https://forum.openwrt.org/t/solved-miniupnpd-not-opening-ports-for-ps4/24591/3

In Call of Duty, I have this problem with a PS5 being, at best, "moderate" with pfsense or with DD-WRT. On pfsense, if the PS5 connects first as moderate, the Windows 10 computer will be reduced to moderate. If the Windows device connects first, Windows (I have some static ports forwarded) will be open and PS5 will be moderate.

So, maybe one of you savvy people can revert pfsense's miniupnp package to exclusively use IGDv1 or maybe it's just a matter of advertising as IGDv1 like with OpenWRT, or fix whatever miniupnp people aren't able to fix with regard to IGDv2 backward compatibility?

IGDv2 is not currently used:

[21.05-RELEASE][root@local]/root: pkg info miniupnpd
miniupnpd-2.2.1_1,1
Name           : miniupnpd
Version        : 2.2.1_1,1
Installed on   : Sun Jul 25 13:59:52 2021 CDT
Origin         : net/miniupnpd
Architecture   : FreeBSD:12:amd64
Prefix         : /usr/local
Categories     : net
Licenses       : BSD3CLAUSE
Maintainer     : squat@squat.no
WWW            : http://miniupnp.free.fr/
Comment        : UPnP IGD implementation which uses pf/ipf
Options        :
        CHECK_PORTINUSE: on
        IPV6           : on
        LEASEFILE      : off
        PF_FILTER_RULES: on
        UPNP_IGDV2     : off
        UPNP_STRICT    : off
Annotations    :
        FreeBSD_version: 1202505
        cpe            : cpe:2.3:a:miniupnp_project:miniupnpd:2.2.1:::::freebsd12:x64:1
        repo_type      : binary
        repository     : pfSense
Flat size      : 160KiB
Description    :
Mini UPnPd is a lightweight implementation of a UPnP IGD daemon. This is
supposed to be run on your gateway machine to allow client systems to redirect
ports and punch holes in the firewall.

WWW: http://miniupnp.free.fr/

Have you guys tried manually adding
force_igd_desc_v1=yes

to the config located at
/var/etc/miniupnpd.conf

Just looking briefly it looks like this may be what the OpenWRT check box does.

(I can't test this because my xbox ones already seem to match up fine as long as UPnp and Nat reflection are configured properly.)

That would not make a difference in this case unfortunately - the IGDv2 issue was fixed long ago and has its own redmine entry.

Fixed for me. Thank you!

Would like to test this but I'm not a developer, I've copied the diff text into the Patch Contents, left everything else blank/default, but when I hit the test button it comes back as :-

Patch can be applied cleanly (detail)
/usr/bin/patch --directory=/ -t -p2 -i /var/patches/62066e0c1d7d9.patch --check --forward --ignore-whitespace

Hmm... Looks like a unified diff to me...
The text leading up to this was:
-------------------------- |diff --git a/src/etc/inc/filter.inc b/src/etc/inc/filter.inc |index d36d6df2e2f982fbb3c456b5cde380de02eea6c0..5a7c21bc2ae94dad9da9a00d4231ff1645ac200b 100644 |--- a/src/etc/inc/filter.inc |+++ b/src/etc/inc/filter.inc
--------------------------
Patching file etc/inc/filter.inc using Plan A...
Hunk #1 succeeded at 2020 (offset -71 lines).
done

and
Patch can NOT be reverted cleanly (detail)
/usr/bin/patch --directory=/ -f -p2 -i /var/patches/62066e0c1d7d9.patch --check --reverse --ignore-whitespace

Hmm... Looks like a unified diff to me...
The text leading up to this was:
-------------------------- |diff --git a/src/etc/inc/filter.inc b/src/etc/inc/filter.inc |index d36d6df2e2f982fbb3c456b5cde380de02eea6c0..5a7c21bc2ae94dad9da9a00d4231ff1645ac200b 100644 |--- a/src/etc/inc/filter.inc |+++ b/src/etc/inc/filter.inc
--------------------------
Patching file etc/inc/filter.inc using Plan A...
Hunk #1 failed at 2091.
1 out of 1 hunks failed while patching etc/inc/filter.inc
done

Is it ok to proceed? I don't want to mess my pfsense up but I'm so keen to try this, my son and I cannot play warzone on ps5 and pc at the same time unless I plugin the ISP router.

That is normal. It's telling you that it can apply the patch but it can't revert it. This means that the patch has not yet been applied. Once you apply the patch it would then tell you it could revert it. You only need to apply it once.

Perfect thank you and sorry for the noob question, I'm just really keen to see this resolved. Will report back later today.

Pleased to say this has resolved the issue for me also! I can finally play warzone with my son, so happy thank you so much.
As I say I'm not a developer and don't even dabble with Beta's or RC's, only final versions, therefore when 2.6 drops should I keep this in place, or remove during the update then re-apply once 2.6 is installed? I see this is being targeted for 2.7 which is a shame but I understand further testing is required.

If you need me to test anything or provide logs etc, just let me know.

It is too late to include the fix in Plus 22.01 or CE 2.6.0, so you will need to re-apply the fix after upgrading.

Just to make sure, you need "static port" outbound nat rules, for this to work? I applied the patch but i get "strict NAT" mode, when using the standard nat outbound rules, which have no "static port" mapping.

T S wrote in #note-82:

Just to make sure, you need "static port" outbound nat rules, for this to work? I applied the patch but i get "strict NAT" mode, when using the standard nat outbound rules, which have no "static port" mapping.

I do have Firewall>NAT>Outbound set to "Hybrid".
But, I disabled everything I had in port forwarding, NAT, and WAN rules for the problematic game in question, for both devices, and the patch worked to show "open NAT".
I'm paraphrasing what Jim explained in the other thread:
Either apply the patch and then reboot PFSense, or apply it and then go to Status>filter reload>reload filter and then Diagnostics>states>reset states>checkmark>reset

This patch worked on our configuration here as well.
UPnP seems to be fully functioning now. Thank you!!

No fix here.

playing COLD WAR or VANGURD. Both PC players. Applied the patch and restarted pfsense box. Shows open for one and the other pc gets connecting to finally, unable to connect. I collected tcpdump collected will review

Tried on my Sons pc as well and same issue.

Trace shows conversation over port 3074 so it "seems" like it worked but doesn't always show under "status > upnp" or under states (see rst pckt so expect state to be clear).

Settings:
running: 2.6.0

System > Advanced > Firewall & NAT >
"NAT Reflection mode for port forwards" : Pure NAT
Enable automatic outbound NAT for Reflection : checked
Enable NAT Reflection for 1:1 NAT : unchecked

Nothing in "port Forwarding" for these pcs just my "calibre and minecraft server"

Firewall > NAT > Outbound
Hybrid : set
Mappings: alias name for my PC's set to static port <-- is this what is killing me?

Snip:
https://drive.google.com/drive/folders/1rPumILNl6trWzYoMOh_d-Id1dJ8_O2pC?usp=sharing

plug my netgear router and no issues.

update:
Error for Cold War: Negative 345 Blazing Gator | Which leads to port forwarding and all that

Interesting I use to see COD try and open other ports, but I no longer see that behaviour. A

update 2: Disabled and rebooted :
Firewall > NAT > Outbound > Mappings: alias name for my PC's set to static port

get strict now

For those who still have issues, please start a new forum thread in the gaming category of the forum and provide more detail about the situation there. From all of the positive responses here and on the forum it is likely to be working about as well as expected and the only exception I'm aware of is for those behind double NAT which is a much different problem that isn't relevant to this issue.

Also there is a new forum thread for general feedback on this issue:

https://forum.netgate.com/topic/169837/upnp-fix-for-multiple-clients-consoles-playing-the-same-game