Okay so I read up on the issue since I was feeling a little out of the conversion.
I used this video to concisely and simply explain
-full cone nat
-restricted cone
-port restricted cone
All three of these cone nats are the SAME principle just the latter two have a way tighter grip in reguards to security behavior for new incoming connections that are originating from different servers or even different source ports from the same server. That different behavior is more dropped connection (NAT3 console speak).
My interpretation of a full cone nat is that it behaves EXACTLY like I would expect a static port forward to behave. Aka, all unsolicited incoming incoming to that port will be accepted/forwarded to the defined device only AFTER that any connection is initiated on that port (so NAT3 that turns to NAT2 after any connection). This happen behavior WITHOUT port forwards being explicitly open but only after the console first establishes a connection on that port.
My interpretation of "restricted port cone" is of (NAT3 on console) behavior. Aka only incoming connections are allowed from the established server ip/port combinations that were initiated by you and are in the NAT connection tracker. All others are blocked. This means that any unsolicited incoming connections on that port, that are already not established by you initiating will get dropped. This is terrible for gaming or anything service wise.
Full cone vs restricted does NOT matter with correct port forwards. Those are correct behavior FULL TIME.
Running the java NAT detector, it said my upnp
ports are of "port restricted cone" type. Now this cannot be true when looking at the actual behavior of UPNP port forwards.
**What it actually meant is that all NON port forwarded ports have "port restricted cone" behavior.**
--- This is what needs clarification
There is a BIG difference between the java test upnp port mapping behavior and the upnp forwards present from my PS4 and torrent client requests.
The PS4 and torrent unpn port forwards showed up listed permanently under the port forwarding section under system log tab in the UI.
The upnp ports from the java test did not! This means the java test did NOT create port forwards. It just queried the ability too. All non forwarded ports will exhibited the default nat behavior that the router uses.
So understand
there are two different types of port mappings.
There are temporary mapping, these do not use UPnP to perform port forward. The the java test performs this mapping. These temporary NAT mappings will exhibit NAT3 like behavior on our routers since we what a port restricted NAT.
AND
There are permanent mapping, these use UPnP to perform a port forward and show up in the webUI. These will exhibit NAT2 like behavior. These have behavior exactly what you would expect from any regular manually defined port forward. These defiantly can be using for server hosting without limiting any connections.
To confirm this behavior, I port scanned my WAN IP on a port and that was forwarded by a torrent upnp request. That port was OPEN and ACCESSIBLE to a random device (my phone) that scanned the port no prior established connection.
Do not getting fixated on the semantics of NAT1, NAT2, or NAT3, just confirm actual behavior, is what you would expect.
TLDR:
Nat3 = restricted cone NAT behavior. (This is present on our routers without port forwarding)
Nat2 = full come NAT behavior, if NAT is "restricted cone" type then a port forward needs to be created to acheive NAT2 behavior. (This is present on our routers after a port forward is created, either UPnP or manually. Active port forwards will be listed in the webUI).
Nat1 = No nat behavior or pseudo nat behavior. Console did not need upnp port forward since traffic was already open.
Either way, my experiments confirms that NAT2 is exhibited for ports when UPNP forwards the ports correctly. NAT2 status is the most ideal for hosting and completely equivalent to NAT1.
Since we have port forwarding being performed, NAT types (full, restricted, symmetric) do NOT matter.
Only time NAT1, and by lesser extension "full cone nat" provides superior results is when/IF UPnP glitches and does not open ports in use and needed to be opened.
The non-opening port behavior is incorrect behavior console side. You shouldn't want to introduce NAT1 or a "full cone nat" due to a console bug. Find a fix for the bug or manually define port forwards.