If I have a fresh install of OpenWrt 22.03.3 and use my router as a typical internet gateway router for a home network, what kind of NAT does OpenWrt use by default? On the WAN side is a broadband modem for connecting to the internet, and on the LAN side are laptops and smartphones. Is it full-cone NAT, restricted-cone NAT, or symmetric NAT? Is there a way to configure which type of NAT my router uses?
Pretty much symmetric NAT for IPv4 and for IPv6 typically no NAT at all (but still rule based access).
I found the following quite elucidating:
https://learningnetwork.cisco.com/s/question/0D56e0000CWxJ9sCQF/lets-explain-in-details-full-cone-nat-restricted-cone-nat-and-symmetric-nat-terminologies-vs-cisco-nat-terminologies
also this:
For full-cone NAT you need one external IP address for each internal host that is to be visible on the internet, so this is not the situation where most end-users find themselves in... (however a symmetric NAT with only a single host attached (e.g. the router itself) should behave similar to full cone NAT, IIRC Linux tries to not change port numbers unless that port is already in use).
But I note that OpenWrt allows you to manually (or automatically if you trust UPnP) create port forwarding rules that allow external hosts to reach internal hosts...
Now, the nomenclature from RFC 3489 (that you use above) turned out to be less helpful than thought and RFC 5389 the successor to 3489 stopped using that nomenclature at all.
3 Likes
But iptables and nftables are doing masquerade which is pretty random AFAIK?
By default, nftables doesn't do random mapping, even though it is supported with the flags "random" and "fully-random". But these flags are not set on OpenWrt.
The actual behaviour is what RFC 3489 calls "Port Restricted Cone". One way to test this is using stun-nat-behaviour (you'll need to find a STUN server that supports this test, as the default one doesn't work). Here is the result, using the classification from RFC 4787:
NAT mapping behavior: endpoint independent
NAT filtering behavior: address and port dependent
5 Likes
Thanks for the clarification and detailed explanation, especially for linking.
Hello,
NOTE :This thread is top google response for “openwrt support forum full cone restricted cone symmetric NAT ?“
NOTE TO MODERATORS : AI content has been removed
This thread left me with these questions.
I would like to know, is it possible to observe which type of NAT and change this type from the luci web interface ?
And follow up question would be
Which tools can be installed/used on the openwrt router to
determine/test, the STUN functionality between our host and another host using a specific STUN server ? (general STUN analysis/diagnosis tools that can be run on openwrt ?)
What is the preferred STUN server to run on openwrt ?
How is UPNP, enabled/disable/configured/tested/diagnosed on openwrt ?
And lastly what about TURN and ICE functionality as well as other NAT hole punching considerations such as TCP hole punching and multiple hole punching ?
Thanks
“ is it possible to observe which type of NAT in luci” ?
there’s no direct setting in LuCI to view or toggle “NAT type.”
OpenWrt uses what would be classified (in RFC 3489 terms) as Port-Restricted Cone NAT
(source is actually, this thread, no mention in openwrt documentation that I could find)
is it possible to change NAT type in luci ?
NO it cannot be changed in luci nor with the console
It would require compiling and installing a
Full Cone NAT kernel module (xt_FULLCONENAT)
for your specific device
In general, altering NAT behavior is non-trivial and not exposed in the web interface.
There is a request to add this capability on this OpenWrt-Devel thread from 2020
This has not been implemented as far as I can tell
Which tools can be installed/used on the openwrt router to determine/test, the STUN/TURN functionality ?
The package coturn, includes basic nat discovery tools
These testing tools are not available in luci, some testing cannot be performed from the server itself
/usr/bin/turnutils_natdiscovery
root@router:~# /usr/bin/turnutils_natdiscovery --help
/usr/bin/turnutils_natdiscovery: unrecognized option: -
Usage: natdiscovery [options] address
Options:
-m NAT mapping behavior discovery
-f NAT filtering behavior discovery
-t NAT mapping lifetime behavior discovery
Requires a timer (-T)
-c NAT collision behavior discovery
Requires an alternative IP address (-A)
-H NAT hairpinning behavior discovery
-P Add 1500 byte Padding to the behavior discovery
Applicable with all except NAT mapping Lifetime discovery
-p STUN server port (Default: 3478)
-L Local address to use (optional)
-l Local port to use (use with -L)
-A Local alrernative address to use
Used by collision behavior discovery
-T Mapping lifetime timer (sec)
Used by mapping lifetime behavior discovery
root@router:~# /usr/bin/turnutils_stunclient
Usage: stunclient [options] address
Options:
-p STUN server port (Default: 3478)
-L Local address to use (optional)
-f Force RFC 5780 processingroot@router:~#
root@router:~# /usr/bin/turnutils_peer -h
/usr/bin/turnutils_peer: unrecognized option: h
Usage: server [options]
Options:
-p Listening UDP port (Default: 3480)
-d Listening interface device (optional)
-L Listening address
-v verboseroot@router:~#
What is the preferred STUN server to run on openwrt ?
restund used to be default, it is no longer available
The only real choice is coturn (requires approximately 580kB of space)
There exist stun mods for some application but they don’t appear to be standalone
Another option might be stuntman
However, no package exists for that one even though it is half the size of coturn
How is UPNP, enabled/disable/configured/tested/diagnosed on openwrt ?
I could not find any clear answers regarding TCP hole punching with regards to openwrt …
Can you please remove the code block around your post. It is kinda hard to read your post.
Please put only code in the code block.
1 Like
Then where did the content of this 2 year last post come from?
Are you still seeking answers to your questions?
Hello,
I was doing research about stun/turn/ice/webrtc and all that stuff.
Trying to understand how I could send and video UDP stream using ffmpeg via NAT hole punching, from a single host on one network to the multicast of another network where both networks have openwrt routers.
So I had all these extra questions about the full cone, restricted cone, restricted port, port restricted cone and symmetric NAT.
The above is my best try at finding some answers.
I couldn’t find it in the documentation, it appears this thread is the top discussion on the topic. I would suggest explaining the status of this core technology on the openwrt wiki might help for people doing .. em… unusual network things.
(Here is all questions that remain unanswered)
If I understand correctly, openwrt is using symmetric NAT but tries to keep the port numbers the same when new connections are open ? But from what I read, a symmetric NAT would only match a connection if the remote host mapping matches, so host IP and port wouldn’t open on the same port unless the mediator connection would be closed ?
So, I think that means it would work, but only one connection per host per IP ? So if one host tried to have multiple NAT hole punching then, only the first or only the last NAT hole punch would work ? I’m really not sure if that’s correct‽
Also I’m very unclear with regards to TCP NAT hole punching, if that would work with STUN or only with TURN or actually work on both, but only if the timing a right ? Only for one connection per host ?
Also what methods to diagnose and monitor such connection from the openwrt router, I have no idea ? Maybe just tcpdump ? I thought there was a place to look at the NAT mappings in real time in luci, but I could not find where if it exists ? I could not find which test and monitor exists for this beside the one included in coturn.
As for ICE (Interactive Connectivity Establishment) — RFC 8445 . I found no information about supporting this technology but maybe it works ?
I think “stuntman” might be a better option than coturn, as it is half the size ? But I could not find a way to compile this for my arm platform.
I tried also setting upnp. but I failed trying it up due to running out of space on my archer c7. I’m not sure if upnp is actually useful with controlling NAT hole punching, or if it just an alternative of dynamically openning port forwards instead of NAT hole punching.
I don’t know how hard it would be to be able to view the current NAT mode from the overview page /luci/admin/status/overview. Could the NAT mode be changed by the user or does that require cross compiling the kernel? Can the kernel be recompiled ? I have a dell s6010-on switch and compiling new kernel modules is not possible, I’m not sure if this is the same situation with the archer c7 ? I’m also not sure if it’s a kernel module that needs to be recompiled or the kernel itself with xt_FULLCONENAT ?
Also this is only tangentially related but while on the subject of kernel/module configuration, is the CONFIG_MROUTE kernel option normally enabled, can I check if my particular install openwrt version has CONFIG_MROUTE enabled ? I believe I will need this later for use with the mangle rule.
Lastly, I did not appreciate having my entire comment nuking for citing having done some of my research with AI and providing the transcript of what it said. I will never mention again whether or not I have used AI, it will be a mystery from now on.
So that’s all the questions I had about this topic, STUN/TURN seems to mostly work without having to do anything at all, I imagine that’s why there is relatively little practical documentation or discussion on this topic. I see most application come with helper app for example the moonlight-stream Internet-Hosting-Tool and the kamailio mod for asterisk.
It’s only an issue if you try doing something no one has done before and trying to make generic version of these tools work together.
So in any case, there might be matter for a wiki article regarding NAT hole punching ! Maybe there’s one and I just missed it !
I think this is not going to work as you plan, unless you build a tunnel between the two networks first, as you can as far as I understand not reliably send multicast over the internet, so you either need a tunnel that hides that multicast form the internet, or you need a local application that replicates unicast inputs into local multicast…
Well, that did not go all too smoothly, but I am not sure you extracted the best take-home message here. AI is great IFF one can evaluate the validity of its responses either by a) being a domain-expert or by b) taking the responses as springboards into deeper research. Without having done a) or b) AI unfortunately only delivers dubious information typically packaged in smoothly readable text.
But regarding your issue, have you looked at switching to IPv6? At which point the whole things boils down to creating a few traffic rules in the firewall to allow access to the required port ranges on the desired IPv6 machine and probable the unicast to multicast conversion I mentioned above?
1 Like
My understanding is that RFC3489 is largely deprecated because the “cone” descriptions were confusing and also didn’t really match many NAT implementations found in the wild.
Kernel functions of OpenWrt are taken directly from the mainstream Linux kernel whenever possible– and I think this is also the case with the NAT built into nftables. So the question doesn’t have to be asked specifically about OpenWrt, any other Linux of the same version should be the same.
It’s really obvious when someone has used AI.
2 Likes
Just ask your bot how masquerade is done by iptables and nftables, ok.
And ask it how to implement the other nat types with iptables and nftables.
And if you are not a historian, better spend your time learning about ipv6.
2 Likes
That is the other point, that no one at the top is working to make the existing kludges to IPv4 better since IPv6 exists.
Your post containing AI generated technical content was removed because it violated the community guidelines around AI usage. The reason that we have this rule is because of the sometimes severe hallucinations that are common with AI models -- not only do they frequently provide advice that is incorrect and misleading, but users following that advice can end up having severe issues with their router/network. Further, whenever AI content is posted on a forum that is considered reputable, it creates a feedback loop with AI believing that, because of the site on which it is found, the AI generated content is accurate, thus making AI hallucinations even worse.
Please do not do that. Just simply don't post any technical content created by AI. We are pretty good at spotting AI written posts, and they will be removed for all the reasons I just described.
4 Likes
This link might be helpful, this is the underlying software that runs fw4. I don't think the Linux firewall was designed exactly as you describe.
For context, this discussion reminds me of a user who wanted to "disable the firewall, but continue to use NAT". When it was explained that NAT, or "masquerade" was a "firewall settings", as are various Source NAT configs, they adamantly disagreed. They proceeded to ask how to install the NAT-only packages or portion of code (not possible with the current code or software as-written).
I understand in some part of the world ipv6 is usable, this is not the case here so NAT hole punching is going to remain the way to do many things, not to mention legacy software that will never be updated to ipv6.
As for asking AI how iptables/nftables work, first, in the query I have done it was ambiguous what NAT mode openwrt does operate in.
In fact, since the RFC3489 terminology itself isn’t reflective of how real NAT actually works … does anyone really know how openwrt’s NAT really work and what the limitation of connection matching are in place ?
Here are the definition I could find
Full cone – One public IP:port maps to a private IP:port, and any external host can send to that port once it’s created.
Restricted cone – Public IP:port maps to a private IP:port, but only external hosts you’ve sent to before (any port) can send back.
Port-restricted cone – Like restricted cone, but only the exact external IP and port you’ve sent to can send back.
Symmetric – NAT creates a unique public port mapping for every different external IP:port you send to, blocking unsolicited packets entirely.
Imagine this UDP connection
[Internal] 192.168.0.5:50000 → [External] 1.1.1.1:57000 → [Dest] 3.3.3.3:10
With openwrt as currently configured, what host can now send to 192.168.0.5 ?
Can host 4.4.4.4 send to 1.1.1.1:57000 and 192.168.0.5 will receive it ?
That would be what full cone NAT allows
Are we for sure certain that openwrt does Symmetric NAT, and therefore most “STUN” server cannot get through and have to fallback on “TURN” (that is relaying instead of actual hole punching) ?
I don’t think there exist any iptables nftable or ufw command that can alter the NAT settings for this, as far as I can tell it is a kernel parameter ? I think it’s all inside the MASQUERADE target like .. paramater xt_FULLCONENAT ?
Which I’m really not sure where that is even configured, where or what the name of the other options are ?
But if the NAT mode can be changed with a single command, then I think it would be an idea to add this option to the luci web interface ?
Maybe it is possible to change these modes but the interface does not call them by those names ?
Here is what I’m seeing in the interface with regard to NAT
in Firewall - Zone Settings - General Settings
in Firewall - Zone Settings - Advanced Settings
in Firewall - Zone Settings - Conntrack Settings
So my question would become, how do you set openwrt NAT policy to be equivalent to the other modes (Full cone/Restricted cone/Port-restricted cone/Symmetric), show what is the current NAT policy and maybe also creating new words to describe the actual policies if those words aren’t accurate descriptions of how it works.
THIS IS OFFTOPIC TO THE CURRENT NAT DISCUSSION
I understand the concern about “hallucinations” but there were no hallucinations. Because there was no AI content in my comment, there were only links to the discussion on the topic I did in my research prior to making that comment.
This leads me to believe, the actual policy is, like in many other anti-AI places on the internet, just a blank “shoot on sight” policy for all things AI. Which the response to that is to not disclose and sorry but if you think you can spot it then it will just be a game of “catch me if you can”.
This is what happens when you punish disclosure.
As for poisonning the AI models with wrong AI answers (leading to model collapse), first, isn’t the forum unscrapable anyway to AI with Anubis already ? And so, I question if this is sincere concern rather than just another argument on the pile to justify the policy.
THIS IS OFFTOPIC TO THE CURRENT NAT DISCUSSION
I searched the netfilter website, but could not find much about the STUN/TURN/ICE stuff.
I checked my router and it does not have nftables installed at all, yet NAT currently works so it might not be applicable to this model ?
On the website here are the relevant part with NAT
It only discusses NAT in general, no mentions of “cones” or STUN/TURN/ICE
There was also a document from 2004 about it
This section is the only part that discusses NAT “cones”
- Netfilter relevant work in IETF
4.1. STUN: Simple Traversal of UDP through NAT (RFC3489)
And it seems to say netfilter is Symmetric only, STUN still not work no matter what ?
Is that the correct answer ?
? ? STUN is incompatible with openwrt, it is relay only (TURN) or upnp (not enabled by default and requires supplemental software). ? ?
Again. It's call masquerade and it's in the Kernel since roughly 20 years by now.
PS for even more history see https://www.oreilly.com/library/view/linux-network-administrators/1565924002/ch11s02.html
2 Likes
Those two links are from year 2000, predate even the publication of RFC 3489 by 3 years and contain no information regarding if the 2000 version of the linux MASQUERADE target uses (Full cone/Restricted cone/Port-restricted cone/Symmetric NAT) as this terminology did not even exist back then.
Can you confirm that the NAT network code in use in 2025 for openwrt is unchanged since year 2000 ?