It would be useful if people could test it and add their Tested-by or Reviewed-by as appropriate.
Thank you
3 Likes
So the answer is “No” ?
I guess i need to learn how to create a custom version of openwrt.
You can download some....
Suggest you explore adding timed map elements, similar to upnp but fired up by outgoing connection.
Hello @Bobosaurus
I am very interested in this question ! I always like questions that challenge the Information Technology IETFBCD Orthodoxy as it has become old, stuffy, set in its ways and bent to the interest of cloud provides. (This is also why multi-cast is largely a forbidden topic and many other things not approved by IT )
First, every discussion of Fullcone NAT starts with "Fullcone NAT isn't a real define term therefore it doesn't exist.
So here is that definition
Fullcone NAT is a NAT type where all incoming packets from any external host are allowed through the NAT as long as they match the internal IP and port that were previously used in an outbound connection.
What this is, is a DYNAMICALLY DEFINED port forward, and this is why IT hates it, IT abhors things that just work without it's "help", things that the user can control without asking permission. Full cone NAT is like allowing users to create port forwards. The IT concession to this problem is to use uPNP, which of course is too complicated for 99% users to use unless it were to "just work" and you will find an infinite amount of internet comments outraged at the very existence of uPNP and how it is an affront to their high security military bunkers but I digress...
Now, when you ask "can we add Fullcone NAT to the firmware", you might think of it like a global setting that you turn on and then every masqueraded conntracked connection becomes Fullcone NAT, so any host any post will match, but I think we still would like to allow only certain DHCP tagged hosts and only certain ports to have that feature and probably have some rules on when, what type of NAT is used.
But since the concept of "Fullcone NAT" and the other variants .. like
Full Cone NAT
Restricted Cone NAT
Port-Restricted Cone NAT
Symmetric NAT
Have been largely thrown in the trash of RFC 5389, the discussion never made it to the point of considering how we would actually apply the NAT policies and in what circumstances.
This is because the IT orthodoxy has decided that for its purpose STUN/TURN can be jerry rigged to cover all cases so that we all become either cloud dependant, or we roll out our own entire clouds.
Also there are other concerns that make changing the orthodox position.
First the code of NAT, ( which was at the time considered an abomination against the End-to-End principle, see this video https://www.youtube.com/watch?v=GLrfqtf4txw ) is so old that the people who wrote it are probably dead by now.
I have searched the internet and another discouraging pressure that it often comes down to is that "NAT only exists because IPv4 is still around, when glorious IPv6 comes around the promised land of the End-to-End principle will be restored to us and we will be able to relegate the NAT abomination to the dust bin of history"
So you can imagine that there is not much incentive to update the NAT code to empower the users ( or to make multi-cast work)
So, in short, whatever you are trying to do, the IT orthodoxy is telling you
Either you use STUN/TURN
Or use Zerotier/tailscale
Or use a full fat VPN
Or use SSH tunnels
Or file an application to your local administrator for the enablement of Port Forwarding to your static IP addresses
Or, and this is really the favored position, What you are doing is wrong, XY problem in fact you should either do something else or want to do something else
An incoming packet can not match a NATed internal address... as it needs to use (one of) the external address(es) of the NAT device other wise the packet will not get delivered, so all you have left is port and protocol.
Then how is it defined dynamically, and how is it offering anything beyond UPnP? Especially puzzle me this: two external hosts want to use port 22 to talk to two different NATed hosts?
UPnP at least forces you to solve issues like the one mentioned above... otherwise you either have a single "exposed host" or first come first serve port mapping.
IMHO full cone NAT might work if you have either a single machine (in which case you might as well forego the router and hook it up directly so you need no NAT at all, or you have multiple public IP addresses then you might want to use one/more for exposed hosts and the rest for NAT. But in the typical case single public address multiple hosts what should the default policy be for full cone NAT to be actually useful?
My gut feeling is at the time RFC3489 was written, some one might have addressed the problem set-theoretically and came up with a complete dichotomy and maybe forgot to check which of these actually make sense in the real world... IIRC the only reason why this comes up routinely is that some game consoles throw the term around in a way that makes it appear desirable until you think about the details.
2 Likes
Example setup
host1.lan - Internal client behind router.lan
router.lan - NAT gateway for host1.lan
myhome.example.com - Public hostname (external interface of router.lan)
cloud.example.com - Public server (only serves to keep the connection open)
remotehost.lan - Internal client behind remoterouter.lan
remoterouter.lan - NAT gateway for remotehost.lan
stranger.example.com - Public hostname (external interface of remoterouter.lan)
host1 opens the port
host1.lan => (router.lan conntrack myhome.example.com:54365 )
=> cloud.example.com
remotehost now sends packet to host1 ( via myhome.example.com:54365 )
remotehost.lan => ( remoterouter.lan conntrack stranger.example.com:60001)
=> myhome.example.com:54365
host1 replies to that packet
host1.lan => (router.lan conntrack myhome.example.com:60001 )
=> stranger.example.com:60001
(how remotehost knows about myhome.example.com:54365, is left as an exercise to the reader )
host1 can continue sending keepalive to cloud.example.com to keep their inbound connection open, or stop, which will stale the inbound port
With symmetric nat this is impossible
With Restricted Cone NAT this generally doesn't work
With Port-Restricted Cone NAT this might work
With Full Cone NAT this probably works
And ideally, we would want to eliminate cloud.example.com from the equation entirely, maybe with some kind of loopback trick like
host1 opens the port
host1.lan => (router.lan conntrack myhome.example.com:54365 )
=> myhome.example.com:loopback_port
(more backstory that I left out for brevity and to reduce comment derailment attack surface https://pastebin.com/zRgAubz4 )
Until some other internal host wants to use port 54365... at which point you are IMHO much better off with a proper traffic/forwarding rule for that port so you act as tie breaker, and if you really want the admin out of the picture, use UPnP or better PCP to allow your clients to poke these holes though the firewall with more dynamics (and let clients deal with the more than one what to open port 54365 concurrently mess themselves).
I understand your desire, but I do not think that fullcone NAT is a robust and reliable solution... for a network with more than one internal host. But then I moonlight as admin on my family network and opening ports allowing forwards is something I can do easily (so easily in fact I disabled UPnP/PCP as I do not trust arbitrary machines in my network enough to handle that responsibly).
But conntrack/NAT isn't going to assign outbound ports that are in use
Thank you about PCP, I didn't know about that one
What I was looking was, somehow have a single script file, running on two LANs, that could talk and route packets without the routers knowing anything about it and without relying on STUN/TURN cloud infrastructure, that is still a long way off but full cone NAT looked like the nearest solution. Still needs at least one side of the connection to have full cone nat "capability", or that "loopback" thing I proposed.
------moonlight tangent------
BTW, I also use moonlight and I also have the admin interface exposed
I am looking into upgrading port knocking to allow remote hosts access to moonlight (my friends) without letting the whole internet in.
You might be interested in my very flexible auto-reconnect script with systray control (I want to add client side port knocking to it)
here is my script, (very beta but I've been using it about a mount and it's been more reliable than just the plain client, which will hang on a disconnection so a regular start script can't detect it died, this monitors application UDP endpoints are alive)
I want to use port knocking for access control, plus do a key exchange, plus allow remote hosts to choose by name their destination sunshine server
------moonlight tangent end------
I also have never enabled uPNP ever and just use port forwards but that's not useful when I need someone else to open their port to me and they don't know what a router is (oh you mean the wifi box !)
sorry I just meant that I act as our family's router admin, typically in the evening night, after work... 
However, thanks for sharing.