Request for port forwarding support / uPNP/NAT-PMP support

[bontebok]

Is your feature request related to a problem? Please describe.

This request is to modernize the network stack to provide better peer to peer connectivity by enabling the ability for Neos to work under a forwarded port. Additionally this request is to add uPNP/NAT-PMP support into Neos so that hosted sessions or headless-clients can request a dynamic port forward rule be created on the router via uPNP/NAT-PMP to the host's world port.

This will enhance Neos to allow interoperability with more users who are behind Strict / Type-3 NAT routers. This also makes UDP hole punching a breeze as Neos has control over which specific ports are forwarded to allow other clients to connect.

xBox & PlayStation include uPNP/NAT-PMP support as well as many PC games and software applications in order to provide more robust support for Strict / Type-3 NAT routers when peer to peer connectivity is needed.

This should lead to a reduction in users who need to use the LNL Relay which could produce some bandwidth cost for Neos savings and improve client performance and provide better support for Enterprise/Commercial/Education customers that use enterprise grade equipment which does not permit an Open or Moderate Type-2 NAT or would require specific ports to be forwarded for use.

Relevant issues

Issues with the LNL Relay is what indirectly drove this request. During peak times (7-10 pm Eastern), chunks of packets from the LNL Relay are lost causing desync and freezes in worlds. By moving from a Strict / Type-3 NAT to a Moderate / Type-2 NAT, I've been mostly able to avoid using the LNL Relay which has resulted in perfect performance in Neos with no freezes or desync during peak use times. However, many high end/SOHO/prosumer routers (like the Ubiquiti EdgeRouter family) do not support changing the NAT type and must instead rely on port forwarding or uPNP/NAT-PMP functionality which does not appear to exist in Neos today.

Describe the solution you'd like

1. Enable the ability for the current networks stack to work over a forwarded port for the world incoming port. This would allow users and headless-clients behind Strict / Type-3 NATs the ability to manually create a port forward rule to enable direct connectivity without the need for an LNL Relay.
2. Incorporate a uPNP/NAT-PMP framework into Neos as to allow the client to manage incoming port forwarding rules when a user is joining worlds or user/headless user is hosting worlds. This would allow Neos to dynamically create port forward rules allowing for better support for modern routers.

Describe alternatives you've considered

Unfortunately, I could not find any alternatives that allow a Neos Client or headless-client to operate behind a Strict / Type-3 NAT without the need to utilize the LNL Relay. The uPNP/NAT-PMP framework exists to allow applications to "hole punch" through Strict NATs and this feature appears on most modern and prosumer/SOHO routers that enforce Strict / Type-3 NAT by default.

Additional context

No response

[Frooxius]

Unfortunately this isn't directly supported by LiteNetLib library that we're using, so we'd have to integrate another solution for this. However from some research this method isn't quite reliable either, so we'll still run into issues where it won't work.

There seem to be a few choices, but I haven't looked into them in detail. E.g. one question is on how many platforms do these work:

https://github.com/lontivero/Open.NAT
https://github.com/alanmcgovern/Mono.Nat

There seems to be some discussion here:
RevenantX/LiteNetLib#11

[bontebok]

Thanks for the response. The Open.Nat library looks promising and would provide the uPNP/NAT-PMP support. This would certainly not resolve all connection challenges, but it would support a wider range of networks that users may be on.

Do you have any thoughts on using the existing framework to attempt a direct connection to the host world's port (simple port forwarding) on the public IP address of the host? In my captures, I never saw the client attempt to make a direct connection even though one existed via a port forward, instead it seems to rely on trying to connect to the source port to attempt a UDP hole punch or use local interfaces if on a LAN.

[bontebok]

Here's a short video clip showing the failure to connect to a world followed by the connection succeeding using the Open World node with the lnl URI of the worlds IP and port. Adding LNL Direct IP support to the initial world connection would resolve the Port Forwarding support request in this GH issue.

2021-12-12.20-28-41.mp4