Community discussions

MikroTik App
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

FEATURE REQUEST: full cone NAT

Mon Aug 17, 2020 9:29 am

Please support full cone NAT

Gaming with full cone NAT router, we can running multi PC/PS4 Games in same LAN as multi Teams Master in Games, games like "Monster Hunter: World"
Now, with Symmetric NAT or uPNP or DNAT-static and other, we can only create One Teams Master.

https://tools.ietf.org/html/rfc3489

https://github.com/Chion82/netfilter-full-cone-nat
https://github.com/LGA1150/openwrt-fullconenat

Full cone NAT:
"A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address."

Symmetric NAT:
"A symmetric NAT applies restrictions exactly the same way as a port restricted cone NAT but handles the NAT translation differently. All types of NAT discussed so far don’t change the source port when NATing connections. For example when a client accesses the Internet using IP 192.168.0.1 and source port 56723 NAT changes the source IP to say 56.35.67.35 but keeps the port number the same; this is known as port preservation. A symmetric NAT NATs ports to new randomly generated ones. This even applies to connections from the same client to different destinations. It's said that Symmetric NAT is more secure."
 
kical
just joined
Posts: 7
Joined: Sun Dec 23, 2018 9:47 pm

Re: FEATURE REQUEST: full cone NAT

Mon Aug 17, 2020 8:20 pm

deploy ipv6 and free of headache
 
User avatar
kiler129
Member
Member
Posts: 352
Joined: Tue Mar 31, 2015 4:32 pm
Location: IL, USA
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Aug 18, 2020 2:00 am

deploy ipv6 and free of headache
Plenty of ISPs don't offer IPv6 (sadly).
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Tue Aug 18, 2020 4:20 am

Then you as a customer, together with other customers, should say "no" and demand IPv6, or you'll go elsewhere. The tricky part is how to increase your numbers above around five people. And then there's the tough decision, if you're really prepared to live without internet, when ISP also says "no".

Don't get me wrong, I actually like IPv6, but...
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Tue Aug 18, 2020 4:22 am

deploy ipv6 and free of headache
PS4/PC Games like MONSTER HUNTER: WORLD not support IPv6

and you cannot make all players use IPv6
 
elbob2002
Member Candidate
Member Candidate
Posts: 252
Joined: Tue May 15, 2018 8:15 pm
Location: Ireland

Re: FEATURE REQUEST: full cone NAT

Tue Aug 18, 2020 9:22 am

Then you as a customer, together with other customers, should say "no" and demand IPv6, or you'll go elsewhere. The tricky part is how to increase your numbers above around five people. And then there's the tough decision, if you're really prepared to live without internet, when ISP also says "no".

Don't get me wrong, I actually like IPv6, but...
Yes. Good Idea. Sell everything and move to another town or city where there is more than one ISP available. Or maybe even another country.

Sometimes it is what it is and you have no choice but to work with what you have.
 
User avatar
kiler129
Member
Member
Posts: 352
Joined: Tue Mar 31, 2015 4:32 pm
Location: IL, USA
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Aug 21, 2020 8:19 pm

Then you as a customer, together with other customers, should say "no" and demand IPv6, or you'll go elsewhere.
The issue is a lot of ISPs don't NEED IPv6 and it provides no real advantage for an average customer. If an ISP offers a cheap fiber and subsells its resources to other smaller ISPs you have no choice really...
For example where I used to live there were essentially 3 services: dirty cheap & good fiber w/o IPv6, cheap coax w/CGN and no IPv6, crappy ADSL w/IPv6. Well, fiber it is.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Fri Aug 21, 2020 9:48 pm

If you read also the other half of my post, to quote myself:
The tricky part is how to increase your numbers above around five people. And then there's the tough decision, if you're really prepared to live without internet, when ISP also says "no".
then I think it's clear that I'm aware how frustrating current state of things is. If not, then I'm stating it explicitly, it's very bad.

And I'm affraid that what you write is not completely true. It seems that average customer doesn't need IPv6. But it's only because the world spent twenty years working around NAT, which is useful thing, but no real solution (that effort should have been spent on polishing IPv6).

There are millions of average users who are unhappy, because their XBox has troubles connecting with others, who can't forward port to their NAS or something, who have to rely on "clouds", or in other words be at mercy of someone who runs them, etc. All these people would benefit from IPv6, only they have no idea that it exists. ISPs are the ones who must do something. After all, they are supposed to be the professionals who know about these things and should provide best service to their customers. But in reality...
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 4:41 pm

Regarding Full Cone NAT, I don't know about others, but most people around me who use RouterOS are using it as a home router. And for home routers, the highest network requirement is to play games, such as XBox, PS5, and Switch. These games mainly use the network for online gaming, and when you play online, it requires port mapping. Different people who use RouterOS do not know how to set up port mapping. Of course, people have developed DMZ and uPNP functions for this, but in the end, you will find that these do not solve the problem effectively. That's why Full Cone NAT appeared.

Full Cone, also known as NAT1, is the most relaxed NAT UDP conversion method, which can solve the port mapping problem for most people. External devices can actively send messages to devices in the NAT1 network. All requests from the same internal IP and port number Endpoint1 will be mapped to the same external IP and port number Endpoint2, and any external host can send packets to this internal host through the mapped Endpoint2. That is, all packets sent from the outside to Endpoint2 will be forwarded by NAT to Endpoint1. There are no restrictions on the source of external requests. Many online games need this functionality.

More and more home routers are starting to support Full Cone NAT, and users only need to turn on this option to solve the online gaming problem. I think RouterOS should also follow this.

Some may say that there is no such trouble with IPv6, but you have ignored one problem. Some games need Full Cone NAT because your online gaming is not through a server, but is peer-to-peer. Then if you want to play IPv6 with the other person, you need to let the person who is playing with you also have IPv6, and his IPv6 is not NAT. If his IPv6 is NAT, I'm sorry, you will not be able to send the game's UDP data to him unless he does the correct port mapping.

For some technical aspects of Full Cone NAT, you can see some implementations from the following link, I hope it will be helpful.
https://github.com/Chion82/netfilter-full-cone-nat

With MikroTik's more and more home routers hAP ax2, RB5009, I still look forward to the Audience AX. I believe supporting Full Cone NAT will be a good thing for every RouterOS user at home.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 5:26 pm

It looks a lot like you are tasking MikroTIk with solving problems that actually are the problem of your game and/or the ISP.
I guess that will not fly.
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 2855
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 6:30 pm

...
More and more home routers are starting to support Full Cone NAT, and users only need to turn on this option to solve the online gaming problem. I think RouterOS should also follow this....
I don't think so. If you want "one button" solution then buy other SOHO brands.
If you want to have full control over "what is behind the scenes" then you should get lessons on configuring routers.
Some games need Full Cone NAT because your online gaming is not through a server, but is peer-to-peer.
So "one button" should open the security Pandora's box?
 
guipoletto
Member Candidate
Member Candidate
Posts: 195
Joined: Mon Sep 19, 2011 5:31 am

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 6:41 pm

It looks a lot like you are tasking MikroTIk with solving problems that actually are the problem of your game and/or the ISP.
I guess that will not fly.
Off course we are, We the ISP, buy the Mikrotik gear precisely BECAUSE it fixes the ISP issues, like:
"i need a core switch" - enter CRS317 for the save
"i need a router with a stable and performant BGP implementation" - Enter CCR2xx/ROS7
"i need to firewall port25 at the ISP level, due to longstanding policy/implementation issues on all sides" - enter CCR1036 to firewall tens of gigabytes of trough-traffic....

- we most definitely don't buy this gear because the routers make for cute paperweights.

the need to somehow fix certain deficiencies of general CPE and Application-layer(read shitty network stack on games) issues arises because that's the part of the network that's under OUR (the ISP) purview

we cannot fix the game
cannot fix the customer's internal network
cannot force them to only buy good gear properly configured by us
and simply there are not enough man-hours to setup port forwarding for every single customer, with different CPE/firmware/bugset

so, a "standard" solution that takes pressure off and frees resources at the ISP level, so we can focus on other stuff is very much welcome;
By the way, i deliver FIXED Ipv6 for my whole customer base, it's free/included in the package, and enabled by default.

They don't care, cause their shit PS4/Xbox won't play their games, and it's obviously the ISP's fault, that we don't pull IPV4 address-space from our tails and magically "Just enable Upnp" like the crappy guide provided by "Sony/Microsoft" states "we should do".

So yeah,
"Full-cone", codified by RFC3489
"PCP", codified on RFC6887
and/or anything else that can be used to de-crapify the edge deficiencies at the ISP-core level (therefore improving the user experience / usability of the actual network)
are very welcome additions in the Mikrotik/ISP toolset.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 6:44 pm

Any modern competitive game uses client-server approach, for others mostly uPnp is enough, so it is only some edge cases that would benefit from cone NAT.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 6:54 pm

we cannot fix the game
cannot fix the customer's internal network
cannot force them to only buy good gear properly configured by us
But at least you can give every customer IPv6.
 
guipoletto
Member Candidate
Member Candidate
Posts: 195
Joined: Mon Sep 19, 2011 5:31 am

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 6:57 pm

Any modern competitive game uses client-server approach, for others mostly uPnp is enough, so it is only some edge cases that would benefit from cone NAT.
Lack of PCP support breaks Upnp at the CGN level.

Does Mikrotik have plans to implement this in the future?
 
guipoletto
Member Candidate
Member Candidate
Posts: 195
Joined: Mon Sep 19, 2011 5:31 am

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 7:00 pm

But at least you can give every customer IPv6.
Well we do!

But Application support is nigh non-existent. (especially when talking games/consoles)
Basically all IPV6 traffic is either from/to Netflix, Meta, or Google.

all the other good stuff either rely on manual port-mapping, deterministic NAT/STUN/Full Cone, or Upnp.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 7:12 pm

When games want to have peer-to-peer communication between devices, they should support IPv6.
Even when MikroTik would support the required NAT, part of the customers would be out of luck because they are behind another NAT layer (at the ISP).
 
guipoletto
Member Candidate
Member Candidate
Posts: 195
Joined: Mon Sep 19, 2011 5:31 am

Re: FEATURE REQUEST: full cone NAT

Mon Feb 13, 2023 8:55 pm

When games want to have peer-to-peer communication between devices, they should support IPv6.
Even when MikroTik would support the required NAT, part of the customers would be out of luck because they are behind another NAT layer (at the ISP).
100% Agreed on principle

In practice, unfortunately, we don't get to force the billion dollar companies to get their IPV6 act together.

And for the end-user, "the internets" and "magic!" are indistinguishable from each other.
So we get the heat, and the mandate to somehow "unbreak" post-nat IPV4.

If we (from an ISP standing) get the tools to minimize customer crying, all parties get happier, less service calls are needed, whilst we continue to bad-mouth Micro$oft and Sony in the IPV6 arena.

PCP and "FullCone NAT" are our friends in the short-to-medium term.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 5:45 am

As users, why do ordinary users reject IPv6?
Taking RouterOS as an example, the AAAA resolution problem was not resolved until the 7.8rc1 version. Before that, if you turned on IPv6, your streaming media would have various problems, such as interrupting while playing. This type of problem is also very common in other home routers. In the general perception, if there is a problem with your home network, such as network congestion, turning off IPv6 will solve the problem. If the video playback is incorrect, turn off IPv6. In short, all problems with your home network can be solved by simply turning off IPv6, returning to the state where there were no problems.

As a common occurrence, most users reject IPv6. For RouterOS, the AAAA resolution issue was only resolved in version 7.8rc1. Before this, if IPv6 was enabled, users would experience various issues with streaming media, such as frequent interruptions. This type of issue is also very common among other home routers, where users perceive any network slowdowns as a result of IPv6, and simply turn it off to resolve the problem. Any video playback errors? Turn off IPv6. In short, any problems with a home network can be resolved by simply turning off IPv6.

This has become a common phenomenon, and even among ISPs who offer IPv6, it is not as wonderful as people imagine. Most ISPs that provide dynamic IPs, when you get a new IPv4, your IPv6 prefix also gets a new one, and the old prefix becomes invalid. This means that your IPv6 prefix is also dynamic.

So, it is often the case that a problem occurs where the customer's device uses an invalid IPv6 address to access the internet, causing problems. This is the same with RouterOS, but the problem was not resolved until RouterOS supported IPv6 NAT and could be resolved through code configuration. Similar problems abound in IPv6, it can only be said that IPv6 is still too young or the configuration of IPv6 is not yet perfect.

So in this case, the user's device will continue to use the outdated and invalid IPv6 prefix, resulting in issues accessing the internet. This is because the ISP informed the user that the IPv6 prefix is only valid for three days, but if the user updates their IPv4 address within that three-day period, they will receive a new IPv6 address and the old IPv6 prefix will become invalid.

Some people may say that the issue can be solved by advertising invalid delegated prefixes. However, only a few routers support this feature, including RouterOS, which does not support advertising invalid delegated prefixes. Furthermore, advertising invalid delegated prefixes requires client support, meaning that the client receiving the broadcast needs to respond to it.
 
Guscht
Member Candidate
Member Candidate
Posts: 236
Joined: Thu Jul 01, 2010 5:32 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 10:20 am

I want to understand whats is the difference between MTs NAT implenation and the "Full Cone" Implentation?

From here:
https://www.networkacademy.io/ccie-ente ... cs-and-nat

A full-cone is one where all packets from the same internal IP address are mapped to the same NAT IP address. This type of address translation is also known as One-to-One.
In 99% of all Home-Users, they have only one public IP. So thats what the basic SNAT/Masquerade-Rule does.

Additionally, external hosts can send packets to the internal host, by sending packets to the mapped NAT IP address.
I understand this that way, if you request the public IP (from any public IP) with any random port (high-port?), it will gets DNATed to the specified internal IP.
AFAIK thats what "Exposed Host" does on so many SOHO-Routers? A simply DNAT-rule does the same on MT.


I cant figure out whats the difference :(
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 12:18 pm

myopic viewpoint of experienced IT professionals here........... surprized NOT.
Mikrotik makes HOME routers , shocking..............
So it does make some sense to understand the requirements.

I am not supporting or poo pooing the idea of full cone nat, but I do challenge the so called experts to stop with ipv6 BS, and provide a config approach that will work withe RoS.
If its as powerful and flexible as you state, then there should be a path to emulate whatever full cone nat is.......

On the other hand concur, gaming console makers and games should not be designed so poorly as to require some weird form of NAT.

Finally, in recognizing that many home users also run servers............... Put zerotrust tunnel by cloudflare in an options package for ALL MT devices! :-)

PS. I have gamed occasionally but only through steam or other online platforms designed for gaming and never had any issues with MT devices and that includes multiple players in the same game. ( not a console person )
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 12:29 pm

Even when MikroTik would support the required NAT, part of the customers would be out of luck because they are behind another NAT layer (at the ISP).

Yeah, that's why full-cone NAT in general is more important for ISP's that have a shortage of public IP addresses and have been forced to switch to CG-NAT thus want to minimize potential issues for existing customers.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 2:23 pm

Which manufacturer has this implemented and how does it work exactly?
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 2:53 pm

Nowadays I believe most carrier grade network equipment manufacturers targeting service providers support all type of nat combinations like eim/eif etc. Or did you mean consumer devices?

- www.a10networks.com/glossary/what-is-carrier-grade-nat-cgn-cgnat/
- www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/217599-understand-nat-to-enable-peer-to-peer-co.html
- vasexperts.com/blog/solution/cg-nat-standard-x86-platform/
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 4:10 pm

I am not supporting or poo pooing the idea of full cone nat, but I do challenge the so called experts to stop with ipv6 BS, and provide a config approach that will work withe RoS.
Fortunately I live in the developed part of the world, where everyone has (or can get, if they enable it) IPv6, and it works without issue.
Aside from the problems introduced in the DNS resolver in version 7.7 (and which have been fixed in the 7.8rc1 version) I have never experienced the trouble with streaming or other services where IPv6 is involved.
It is time that the ISPs that are still in the dark ages get their act together.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 4:36 pm

It is time that the ISPs that are still in the dark ages get their act together.

I agree but unfortunately IPv6 is still in pretty bad shape except for Germany, France, Greece, India and Malaysia. I'm sure I've managed to miss a bunch of countries so check it out for yourself down below. My theory is that ISPs in countries that were early adopters and managed to grab large address blocks for IPv4 are the ones that hesitates to implement IPv6.

Google statistics - Per-Country IPv6 adoption: www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
Google statistics - IPv6 Adoption rate: www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption

EDIT:
Another factor is that many consumer products are incredibly bad at ipv6 and also there is no widespread "best practice" for use by the ISPs (like IPv6 riding in the Wild West).
Last edited by Larsa on Tue Feb 14, 2023 4:45 pm, edited 2 times in total.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 4:43 pm

here is a GPON Modem router from ISP support Fullcone NAT.
photo_2023-02-14_22-42-38.jpg
You do not have the required permissions to view the files attached to this post.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 4:48 pm

So full cone-nat = slow ass speeds and poor security ???
 
guipoletto
Member Candidate
Member Candidate
Posts: 195
Joined: Mon Sep 19, 2011 5:31 am

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 4:50 pm

In the SOHO market, TP-Link also supports "Full Cone" in products sold directly to end-users, such as the ArcherC5/C6/C20 line
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 4:53 pm

So full cone-nat = slow ass speeds and poor security ???

Well, not really. It all comes down to how you configure your firewall (ie connection tracking is still valid) and in terms of speed it all depends on the implementation. Most consumer products are not as flexible as RoS, thus in some cases there might be som security gaps in their semi-automatic management of the firewall if changes are made to the nat settings.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 5:05 pm

RFC states:
Full Cone: A full cone NAT is one where all requests from the
same internal IP address and port are mapped to the same external
IP address and port. Furthermore, any external host can send a
packet to the internal host, by sending a packet to the mapped
external address.
So full cone config on MT is:
/ip firewall nat
add chain=srcnat out-interface=wan action=src-nat to-address=wan_ip
add chain=dstnat in-interface=wan action=dst-nat to-address=local_ip
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 5:48 pm

So full cone-nat = slow ass speeds and poor security ???

Well, not really. It all comes down to how you configure your firewall (ie connection tracking is still valid) and in terms of speed it all depends on the implementation. Most consumer products are not as flexible as RoS, thus in some cases there might be som security gaps in their semi-automatic management of the firewall if changes are made to the nat settings.
The idea of full cone NAT is that a device can send a packet to a server with some source port number, and then ANYONE with knowledge of that source port number as it arrived at the server can reach that same client on that same portnumber.
That precludes the use of connection-tracking. And it is about the same as disabling the firewall for that one port.
You have to hope that the client will have proper firewalling on the ports it uses for outgoing traffic, i.e. it does not, for example, do NTP queries from port 123 as a source-port as that would open its NTP service for the world. When that is not sufficiently hardened, it can then be used as a DDoS amplifier.
That is likely one of the reasons why some (many?) ISPs are blocking NTP port 123 on the client side, which then affects users who want to use NTP on their router.

All in all I don't think it is a good idea to have this enabled globally on a router. Somewhat more secure would be to open it on a client-by-client basis, but not in the way that mrz suggests (which effectively exposes the entire client to internet without firewall).
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 5:58 pm

That is not a full cone but restricted cone.
Restricted Cone: A restricted cone NAT is one where all requests
from the same internal IP address and port are mapped to the same
external IP address and port. Unlike a full cone NAT, an external
host (with IP address X) can send a packet to the internal host
only if the internal host had previously sent a packet to IP
address X.
Full cone is just a basic src and dst nat that does not restrict anything and achievable by two rules provided earlier.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 6:25 pm

thanks mrz!! but its not quite clear as not sure what the intent is here.
It seems mixing dynamic, static WANIPs??

/ip firewall nat
add chain=srcnat out-interface=wan action=src-nat to-address=wan_ip
( like static )
add chain=dstnat in-interface=wan action=dst-nat to-address=local_ip ( like dynamic )

wouldnt it be
/ip firewall nat ( static)
add chain=srcnat out-interface=ether1 action=src-nat to-address=fixed wan_ip
add chain=dstnat dst-address=fixed wan_ip action=dst-nat to-address=local_ip


OR
/ip firewall nat
add chain=srcnat action=masquerade out-interface=wanX
add chain=dstnat action=dst-nat in-interface=wanX to-address=local_ip
Last edited by anav on Tue Feb 14, 2023 6:31 pm, edited 1 time in total.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 6:30 pm


Well, not really. It all comes down to how you configure your firewall (ie connection tracking is still valid) and in terms of speed it all depends on the implementation. Most consumer products are not as flexible as RoS, thus in some cases there might be som security gaps in their semi-automatic management of the firewall if changes are made to the nat settings.
The idea of full cone NAT is that a device can send a packet to a server with some source port number, and then ANYONE with knowledge of that source port number as it arrived at the server can reach that same client on that same portnumber.
So by definition, given this NAT table:
IPV4	TCP	192.168.70.5:45596	188.x.x.163:443
IPV4	TCP	192.168.70.5:46222	185.x.x.153:443
IPV4	TCP	192.168.70.122:35542	63.x.x.172:443
IPV4	TCP	192.168.70.122:35868	213.x.x.164:443
IPV4	TCP	192.168.70.122:40152	54.x.x.132:443
IPV4	TCP	192.168.70.122:40750	54.x.x.170:443
IPV4	TCP	192.168.70.122:41408	52.x.x.118:443
IPV4	TCP	192.168.70.122:53382	54.x.x.93:443
IPV4	TCP	192.168.70.122:53542	82.x.x.205:443
IPV4	TCP	192.168.70.122:53696	35.x.x.102:443
IPV4	TCP	192.168.70.140:41402	139.x.x.24:5094
IPV4	TCP	192.168.70.140:49126	142.x.x.188:5228
IPV4	TCP	192.168.70.140:51256	80.x.x.132:5223
IPV4	TCP	192.168.70.155:37450	34.x.x.49:443
IPV4	TCP	192.168.70.155:38418	3.x.x.174:5222
IPV4	TCP	192.168.70.155:45968	173.x.x.188:5228
IPV4	TCP	192.168.70.155:48724	54.x.x.17:443
IPV4	TCP	192.168.70.155:57452	149.x.x.91:5222
IPV4	TCP	192.168.70.181:38288	35.x.x.252:6179
IPV4	TCP	192.168.70.181:58246	142.x.x.227:80
IPV4	TCP	192.168.70.181:58756	173.x.x.188:5228
IPV4	TCP	192.168.70.183:10101	79.x.x.200:31337
IPV4	TCP	192.168.70.183:10103	79.x.x.200:31337
IPV4	TCP	192.168.70.183:10106	79.x.x.200:31337
IPV4	TCP	192.168.70.183:10124	79.x.x.200:31337
IPV4	TCP	192.168.70.183:54147	20.x.x.85:443
IPV4	TCP	192.168.70.183:62352	140.x.x.26:443
IPV4	TCP	192.168.70.183:62360	54.x.x.153:443
IPV4	TCP	192.168.70.183:62370	140.x.x.3:443
IPV4	TCP	192.168.70.184:36542	18.x.x.119:443
IPV4	UDP	192.168.70.5:55826	93.x.x.19:123
IPV4	UDP	192.168.70.108:54321	52.x.x.77:8053
IPV4	UDP	192.168.70.155:33530	82.x.x.212:4500
Would mean that I will have these dst nat rules in place, right? By activating the "Full Cone NAT" feature?
TCP	wan_ip:10101	> 192.168.70.183:10101
TCP	wan_ip:10103	> 192.168.70.183:10103
TCP	wan_ip:10106	> 192.168.70.183:10106
TCP	wan_ip:10124	> 192.168.70.183:10124
TCP	wan_ip:35542	> 192.168.70.122:35542
TCP	wan_ip:35868	> 192.168.70.122:35868
TCP	wan_ip:36542	> 192.168.70.184:36542
TCP	wan_ip:37450	> 192.168.70.155:37450
TCP	wan_ip:38288	> 192.168.70.181:38288
TCP	wan_ip:38418	> 192.168.70.155:38418
TCP	wan_ip:40152	> 192.168.70.122:40152
TCP	wan_ip:40750	> 192.168.70.122:40750
TCP	wan_ip:41402	> 192.168.70.140:41402
TCP	wan_ip:41408	> 192.168.70.122:41408
TCP	wan_ip:45596	> 192.168.70.5:45596	
TCP	wan_ip:45968	> 192.168.70.155:45968
TCP	wan_ip:46222	> 192.168.70.5:46222	
TCP	wan_ip:48724	> 192.168.70.155:48724
TCP	wan_ip:49126	> 192.168.70.140:49126
TCP	wan_ip:51256	> 192.168.70.140:51256
TCP	wan_ip:53382	> 192.168.70.122:53382
TCP	wan_ip:53542	> 192.168.70.122:53542
TCP	wan_ip:53696	> 192.168.70.122:53696
TCP	wan_ip:54147	> 192.168.70.183:54147
TCP	wan_ip:57452	> 192.168.70.155:57452
TCP	wan_ip:58246	> 192.168.70.181:58246
TCP	wan_ip:58756	> 192.168.70.181:58756
TCP	wan_ip:62352	> 192.168.70.183:62352
TCP	wan_ip:62360	> 192.168.70.183:62360
TCP	wan_ip:62370	> 192.168.70.183:62370
UDP	wan_ip:33530	> 192.168.70.155:33530
UDP	wan_ip:54321	> 192.168.70.108:54321
UDP	wan_ip:55826	> 192.168.70.5:55826	
I'm gonna run out of ports fast (well, unlikely for a home user, but the CG-NAT scenarios posted above ¯\_(ツ)_/¯). What happens when there are two clients using the same src port? who wins? first come, first served?
And this is a pretty "quiet" router regarding the number of clients behind it.
Or I misunderstood it?
And this will create a whole lot of holes in my network, for what?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 7:49 pm

Full cone is just a basic src and dst nat that does not restrict anything and achievable by two rules provided earlier.
Your two rules implement more than what a "full cone NAT" would do. What you describe is called "DMZ host" in consumer routers.
(ALL traffic incoming on your external address that is not related to outgoing traffic from other internal clients is forwarded to ONE specific client IP)

However that means:
- the client also gets traffic unrelated to earlier outgoing traffic (i.e. you disable all firewalling)
- there can be only ONE client that is treated like this

A real full cone NAT would be able to handle more than one client, and would still protect the client from traffic towards ports it is only listening on but does not use as source ports for outbound traffic.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 7:54 pm

I'm gonna run out of ports fast (well, unlikely for a home user, but the CG-NAT scenarios posted above ¯\_(ツ)_/¯). What happens when there are two clients using the same src port? who wins? first come, first served?
And this is a pretty "quiet" router regarding the number of clients behind it.
Or I misunderstood it?
And this will create a whole lot of holes in my network, for what?
Sure you run out of ports... but that is a common problem with every NAT solution.
Normally most routers will first check if a given source port is already "in use" and if not, the port number will be kept untranslated.
When it is "in use", the port number is replaced by another one.
That can still work in those gaming setups: the game will send a packet to some registration server, that will note the (translated) port number corresponding to the particular client (game console behind a NAT) and will tell the port number to other gamers that want to connect to that console.
These other gamers will then send traffic to that port number, and it will arrive at the game on the "standard" port number (translated by the router).

I think in practice the whole thing uses only UDP. Maybe many "home routers that offer full cone NAT" will only do it for UDP, not for TCP. For TCP it makes less sense and is more prone to overloading the port table.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 8:34 pm

So in other words, it's basically alternative to UPnP that works automatically without requiring client to do anything. And the key part is that it can work for multiple clients sharing same public address (unlike mrz's NAT 1:1, which is otherwise fine, but it needs one public address for each internal one). Correct?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 8:35 pm

Yes MRZ needs to come back and fess up.
So far i don't see a viable MT configuration yet.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 9:09 pm

Well we can always script it. But that would put a lot of load on the router doing the NAT.
Aren't consoles using something similar to UPnP to open ports anyway? isn't that enough?
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 10:31 pm

Regarding CGNAT/LSN:

1) port allocation there is plenty of information online but here is a short and concise answer
https://networkengineering.stackexchang ... allocation

2) connections tracking is only performed when the client side initiates a connection (packet flow) ie there is no 1:1 mapping from the outside.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 14, 2023 10:38 pm

That "short and concise answer" doesn't apply to current discussion.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 7:03 am

My understanding of FullCone NAT is as follows, if there are any errors, I welcome correction:

We first assume the following environment data:

PC1 192.168.88.100
PC2 192.168.88.200
LAN 192.168.88.0/24
WAN IP 34.56.78.90
The destination to be visited is 1.2.3.4:2345

When a device PC1 in the LAN network visits the destination UDP://1.2.3.4:2345, then there will be a record in the NAT table
src-address = 192.168.88.100:2345
dst-address = 1.2.3.4:2345 / reply-dst-address: 34.56.78.90:12345

When a device PC2 in the LAN network visits the destination UDP://1.2.3.4:2345, then there will be a record in the NAT table
src-address = 192.168.88.200:2345
dst-address = 1.2.3.4:2345 / reply-dst-address: 34.56.78.90:23456

At this point, as the visited person 1.2.3.4:2345, you will see two requests respectively from 34.56.78.90:12345 and 34.56.78.90:23456 UDP requests.
If we want 1.2.3.4 to be able to return the data normally to 192.168.88.100:2345 and 192.168.88.200:2345,
then we need to add two dstnat mappings to 88.100 and 88.200, respectively.

The problem now is that 12345 and 23456, the two WAN ports bound to the NAT table, are random, that is, if the NAT table expires.
Then perhaps 10 minutes later, when the two PCs visit 1.2.3.4:2345, the NAT table will allocate two new ports, which can be any unused UDP.

We can solve this problem by recording every request from each device in the network and setting the corresponding port mapping.
Of course, someone says we can read the NAT table and then write the dstnat rule, congratulations on what you said, and I have implemented it.
But there will be a situation, you need to cycle this thing at a certain time, when you write the rules according to the known request,
the relevant data has returned to the port, but it has not reached PC1 / PC2 correctly and then failed on the APP on PC1 / PC2.

Similar problems are like the dns-to-address-list currently supported by RouterOS,
I have also written the script this way, by traversing the dns cache, and then reading the record and writing it to the relevant address-list according to the domain name you need.
That is, dns-to-address-list is implemented by the script, but you will find that many times
when the client visits the destination, the expected record has not been written to the address-list by the script.

It is still not possible to rely on the script alone when more and more devices in the system need fullcone NAT.
You need to make RouterOS internally support this feature.

Regarding security concerns, Fullcone NAT now comes with a device list feature, similar to a DMZ list. This means that only devices on the list will be subjected to Fullcone NAT. Of course, if there is malicious software on your computer, it will increase security risks. However, this is no different from the security risks of UPnP and is considered a disclaimer.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 7:06 am

nat.png
here is NAT types defined in STUN
Full-cone NAT
All requests from the same private IP address and port (for example, IP1:Port1) are mapped to the same public IP address and port (for example, IP:Port). In addition, any host on the Internet can communicate with the host on the intranet by sending packets to the mapped public IP address and port.

This is a relatively loose NAT policy. As long as the mapping between the private IP address and port and the public IP address and port is established, any host on the Internet can access the host on the intranet through the NAT device.

Restricted-cone NAT
All requests from the same private IP address and port (for example, IP1:Port1) are mapped to the same public IP address and port (for example, IP:Port). A host on the Internet can send packets to the host on the intranet only if the host on the intranet has previously sent a packet to the host on the Internet.

Port-restricted cone NAT
Port-restricted cone NAT is similar to restricted-cone NAT, but the restriction includes port numbers. That is, a host on the Internet (for example, IP2:Port2) can send packets to a host on the intranet only if the host on the intranet has previously sent a packet to the host on the Internet.

Symmetric NAT
All requests sent from the same private IP address and port to a specific destination IP address and port are mapped to the same IP address and port. If a host sends a packet with the same source IP address and port number to a different destination, a different NAT mapping is used. In addition, only a host on the Internet that receives a packet from a host on the intranet can send a packet back.

Unlike port-restricted cone NAT that maps all requests from the same private IP address and port to the same public IP address and port, regardless of their destinations, symmetric NAT maps requests with the same source IP address and port number but different destinations to different public IP addresses and ports.
You do not have the required permissions to view the files attached to this post.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 7:54 am

[...]
Regarding security concerns, Fullcone NAT now comes with a device list feature, similar to a DMZ list. This means that only devices on the list will be subjected to Fullcone NAT. Of course, if there is malicious software on your computer, it will increase security risks. However, this is no different from the security risks of UPnP and is considered a disclaimer.
The question I've asked above remains, aren't the services/games that rely on "Full Cone NAT" meant to have some functionality to open random ports via UPnP or similar when needed instead of me butchering the NAT table opening ports that the app might not even need?
Considering that the said software/game is written in the last decade the devs responsible for networking should be aware that nobody has a public IP dedicated for the console or the said app, at home.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 8:50 am

I might be wrong but I'm pretty sure "the said" developers didn't deliberately construct a game that required full cone (or whatever definition you prefer) because this functionality was not available, at least not widespread or standard on consumer devices.

So you still persist that these kind of issues with old and poorly designed games are important for MT to solve and not the actual game developer?

In my opinion regarding Mikrotik there is absolutely no need for a new construction as this can already be solved using normal settings in RoS.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 9:30 am

My English might be rusty but I wrote no such thing.
They didn't probably think of "full cone nat" but some of them figured that all these consoles can talk freely over the internet with each other with no sweat, which is obviously wrong.
I didn't point fingers to MT as they would be the ones to "fix" this. Point me where I've said that.
And IYHO you seem wrong to think that it's an easy fix like ticking a box in RouterOS, even after all these walls of text written in this topic.

I've only asked if there is some UPnP-like protocol that consoles can use to take care of the port opening (and the current UPnP isn't enough), if there is, a feature request for the said protocol should be made.
So far we only got a mention of "PCP", RFC6887.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 10:47 am

Regarding security concerns, Fullcone NAT now comes with a device list feature, similar to a DMZ list. This means that only devices on the list will be subjected to Fullcone NAT.
What do you mean? Are you talking about the implementation on some other NAT router here?
(where the manufacturer realized that this is a big hole and probably not a good idea to enable for e.g. a TV or other IoT device)
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 2:51 pm

Assuming the pretty pictures above are accurate.......
Q remains.....can RoS accomplish same?
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 7:28 pm

To be perfectly clear, yes. You can accomplish the exact same thing using Ros but with even greater precision.

I've discussed this "issue" with my son who is a true gamer (maniac) since the age of 5 and is now studying computer science in his 5th year. He has literally had all available game consoles and has set up his own servers for Minecraft, Valheim, Terraria, Space Engineers, etc.

I've helped him over the years at home with most network issues and at most we've had to open a few ports in/out but never been forced into any kind of fully open 1:1 NAT (full cone) so there's no indication that this would be a widespread problem.

However instead of hypothetical speculations, I'd suggest that we try to compile a list of examples with games where the game developer or other related source clearly states that "full cone" NAT is required for it to work.

OT:
Nowadays, he has his own Asus (Merlin fw) with a dedicated public ip that he takes care of all by himself so the rest of us in the family avoids any network disturbances. ;-)
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 7:45 pm

I think you can't:

- You can have NAT 1:1, but that's only for one internal device (or more, if you have multiple public addresses, but who has enough?)
- You can forward ports manually, but that's missing the "just works without user interaction" part
- You can use UPnP, but it's again not the "just works without anything else"
- You could try to write a script to add dstnat rules automatically, based on connections table, but... yikes

For the record, I don't need it personally, but if it wouldn't be too difficult to add (e.g. if the linked existing netfilter module is in good shape), then why not, it would be another tool that would make someone happy.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 8:27 pm

Sorry, but I beg to differ.

Regarding your first point it all depends on the implementation but in general you have never been dependent on a DMZ-like (1:1) configuration but sometime for a port range. So yes, this can be accomplished using RoS 1:1 mappings for a port range. The rest of the following points, they might be valid for a dedicated consumer device.

As for the last sentens, I really don't agree, in any case as long as there are unresolved problems with the core functionality of Ros, this should be cleared up before embarking on similar extensions.

And as I said in my previous post I still believe this is a non-existent problem. Thus again, instead of hypothetical speculations bring me facts this is actually a widespread problem for gaming. However, the only thing I would agree with is implementing this feature for purely marketing purposes targeting the consumer market.
Last edited by Larsa on Wed Feb 15, 2023 8:49 pm, edited 1 time in total.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 8:48 pm

If you mean forwarding port ranges to different devices, it wouldn't really work, would it? Not without some configuration on those devices that would force them to use these ports as source. If I'm dstnatting e.g. 1000-1999 to device A and 2000-2999 to device B, then if device A uses e.g 1500 as source and router keeps it, it will be fine. But if device A uses some random 36313, then I can still srcnat it into 1000-1999 range, but I won't have dstnat from 1xxx to internal 36313. With this thing, it would just work for any device without any extra config on it.

And sure, there are more important things, but it doesn't mean that there can't be other ideas in queue. Also, what's wrong with consumer market? MikroTik is clearly interested in it. There might be more customers who would appreciate this than those who need BGP (don't take it too seriously :)).
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 9:21 pm

Well, you have the same basic problem with "full-cone" nat as requests from the same internal ip/port are mapped to the same external ip/port so there are no automatic overlapping that separates two devices using the same port range. Nowadays many also suffer from CGNAT (ie double nat) which becomes a natural limitation and makes this feature less important.

To be honest I don't really care what MT decide as I'm not dependent on it all but if they really want to enter the consumer market they've a pretty tough challenge ahead of them.

On the other hand, there is a huge pile of money in the gambling industry for those who succeed. Gamers spend ridiculous amounts of money on everything related to gaming, my son is a good example of that (well not really ;-) )

However for the existing customer base I really hope for their sake MT makes a serious effort to shape up v7 and make it fit for production.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 9:57 pm

No, this, as I understand it, solves it. Imagine some udp-based game or another system with p2p communication. If it was ideal NAT-less internet:

- client A sends packet from a.a.a.a:aaa to remote server
- client B sends packet from b.b.b.b:bbb to remote server
- server tells these addresses with ports to other clients
- anyone else can connect to a.a.a.a:aaa and reach A
- anyone else can connect to b.b.b.b:bbb and reach B

But if there's NAT, it's not longer possible. But this would make it work again:

- both clients A and B are behind same NAT, to make it more challenging
- A sends packet from 192.168.88.101:12345 to server
- router can keep the port if it's free, or choose different one, it doesn't matter; let's say it keeps it, so source will become p.p.p.p:12345 (p.p.p.p = its only public address)
- router adds (invisibly) what's basically dstnat from p.p.p.p:12345 to 192.168.88.101:12345
- B sends packet from 192.168.88.102:12345 to server
- router changes source to p.p.p.p:23456 (it can't keep 12345, because it's already taken by A)
- router adds dstnat from p.p.p.p:23456 to 192.168.88.102:12345
- also, if B sends packet from same 192.168.88.102:12345 to different remote server, router will use same p.p.p.p:23456
- server tells these addresses and ports to other clients
- anyone else can connect to p.p.p.p:12345 and reach A
- anyone else can connect to p.p.p.p:23456 and reach B

It's as if the NAT disappeared. Neat, isn't it? Too bad I don't have any use for it myself, I'm starting to like it. ;)
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 10:27 pm

That looks more like some kind of variation of full-cone and symmetric nat. Check RFC 3489 (5. NAT Variations), the external/public port is always mapped to the same internal port number and is why it's sometimes called Static or 1-to-1 (1:1) NAT.

I think Cisco and probably many of the other carrier grade cgnat vendors have some pretty good white papers that describe the different variants in great detail.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 10:52 pm

Well, the definition by itself is not completely clear. For full cone it says that "all requests from the same internal IP address and port are mapped to the same external IP address and port", but that's not necessarily same internal and external port number. So i.i.i.i:1234 always mapped to e.e.e.e:4321 should be fine. It's sort of subset of NAT 1:1 (which allows also incoming connections without previous outgoing one). The key difference from current srcnat/masquerade (except NAT 1:1) is that it allows new incoming connections from anywhere (any unrelated address) and they can reach internal host.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Wed Feb 15, 2023 11:37 pm

It certainly might be as it all depends on the implementation currently in use or as the wiki states: many NAT implementations combine these types, so it is better to refer to specific individual NAT behavior instead of using the Cone/Symmetric terminology.

Thus in this particular case someone should start looking for a reference implementation that possible might fit the purpose. I had a quick look and there are a bunch of open source modules for nftables/netfilter. However I persists and still claim this is a non-existent problem for the modern gaming industry todays, nor for MT owners using Ros.

As for the other suspects, well show me the real problem! ;- )
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 12:54 am

As for the other suspects, well show me the real problem! ;- )
@Larsa - Fair point!
@kcarhc - Okay buddy, please elucidate on actual problems encountered with your Playstation 5? / Xbox live or Series X/S? If you have any friends with MT and they have also similar issue would be worth reviewing.......
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 1:53 am

On the PS5, there are four types of NAT: NAT1, NAT2, NAT3, and NAT4. If there are other NAT types, I may not have encountered them on the PS5, and I welcome any corrections.

NAT1: Full Cone NAT (One-to-One)
NAT2: Restricted Cone NAT (Address Restricted Cone)
NAT3: Port Restricted Cone NAT
NAT4: Symmetric NAT
Generally, the lower the number, the more open the NAT is, and the higher the number, the more restricted it is.

To illustrate, let me use the game "Monster Hunter," which I play on a daily basis, as an example. The game has different versions, such as "World," "Rise," and "Sunbreak." In the game, there is a place called the Gathering Hall, where players can voice chat and undertake missions.

If you have NAT1, then you will have no problem with voice chat. However, if you have NAT2/3/4, and you want to speak with others, there must be at least one person in the Gathering Hall who has NAT1. If everyone has NAT2/3/4, you may see an indication that someone is speaking, but everyone will hear white noise or nothing at all.

Another thing to consider is the online gaming experience. If several players have a NAT type other than NAT1, it is best to have the NAT1 player create the room, as other players may have a higher chance of experiencing disconnections. However, if all players have NAT1, the online experience is smoother and more enjoyable.

These games typically use P2P (peer-to-peer) connectivity, where a large amount of game data is transmitted between players instead of going through a game server.

If I have made any mistakes, please feel free to correct me.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 2:16 am

Are we talking about NAT status from the internet test?

There is a pretty detailed description somewhere on Steam's website that describes the different levels and what you can do about it but those who encounter type 3 problems are often caused by CGNAT (i.e. double-NAT) with an ISP that has very tight restrictions on how the ports are opened to the outside world and how long they are open etc. i.e. there is not much you can do.

If you're at home you shouldn't use NAT at all because it can cause issues due to double NAT (or in worst case triple NAT if your ISP is using CG-NAT)

Unfortunately I don't have a PS5 close by to test on tho but I'll check with my son when I'm back home.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 9:55 am

Based on my understanding, the typical internet setup for home users is as follows: using PPPoE or DHCP to obtain a dynamic public IP address.
In other words, using the pppoe-client/dhcp-client in RouterOS to obtain an IPv4 address and an IPv6 prefix on that interface for use.

Furthermore, all ports can be accessed from the outside except for specific ports that are forbidden by the ISP, such as TCP ports 80/443,
unless you apply for a fixed IP address and pay the required fees.

However, if you need to access the internal LAN, you need to set up port forwarding. Overall, this type of internet structure is very simple.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 10:06 am

Many people around me use this type of internet access, including gaming friends.
Most of them have switched their DSL modem router from router mode to bridge mode after my persuasion and have adopted RouterOS as their router.

As for CGNAT, commonly used private network ranges include 100.64.0.0/10, 10.0.0.0/8, and 172.16.0.0/12.
There was a period of time where some people experienced these private network ranges in their homes,
but they were able to have it changed to a public IP address by calling their ISP and making a complaint.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 10:55 am

Furthermore, all ports can be accessed from the outside except for specific ports that are forbidden by the ISP, such as TCP ports 80/443,
unless you apply for a fixed IP address and pay the required fees.
Well, here there are no such additional restrictions or fees, nearly everyone gets a static address on home internet connections and ports like 80 or 443 are open, there are only some ISPs who block ports that are or have been widely abused (123, 135-139, 161, 3306 for example).
Many people around me use this type of internet access, including gaming friends.
Most of them have switched their DSL modem router from router mode to bridge mode after my persuasion and have adopted RouterOS as their router.
Why did you do that??? RouterOS is not targeted towards gamers, they would probably be better off with their standard ISP router which supports your "full cone NAT" feature.

I would recommend MikroTik routers only to people who want to setup VPNs between locations, want to run different networks on the same router, etc.
That is where they shine relative to standard home routers. Not for ease of use, single-checkmark configuration of advanced features, modern WiFi, etc.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 2:52 pm

The advantage of RouterOS for me is its stability, which is the most important factor.

RouterOS version 6.x is indeed very stable. As for WiFi, most people use access points such as UBNT, Linksys, or other brands of routers to operate in access point mode. However, RouterOS 7.0 is a disaster, especially on devices like hAP ac2 with a small 16MB hard disk. The total disk size is 16MB, but the available space is only 1-2MB, which can cause disk leakage and eventually become a brick.

I have used MikroTik WiFi products, including all models with built-in WiFi for home use, and finally discovered the performance issue with MikroTik WiFi, which unfortunately cannot be resolved by MikroTik and the root cause has not been found. I believe that some people have encountered the same issue as me and have assumed that it was due to the poor quality of the MikroTik WiFi models. However, through testing, I found that it was not the case.

You can perform a test by using a MikroTik device as an access point and connecting a RouterOS and another brand of router to it respectively, and then conduct a speed test on the speedtest.net website. You will find that the WiFi performance running on RouterOS is worse than that connected to the other brand of router, even though they are both in access point mode. In other words, there is a performance issue when exchanging data between MikroTik routers and access points.

Using the same mobile phone and the same access point, but connecting to different routers, one is RouterOS and the other is another brand of router. The WiFi performance connected to the other brand of router is better than using RB4011iGS+5HacQ2HnD-IN as a WiFi router directly.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 3:07 pm

Regarding MikroTik's AP performance issue, a friend of mine came up with a classic saying: ?

"Don't connect MikroTik's AP to MikroTik's RouterOS if you don't want your AP's performance to deteriorate."
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 3:57 pm

These are my conclusions after been talking to my son and his buddies: neither full-cone NAT nor DMZ is needed for normal online games and port forwarding is usually only needed if you are running a self hosted server. Depending on the game, you only need "normal" NAT, UPnP/NAT-PMP or sometimes as a last resort port forwarding.

When it comes to UPnP, you should be aware that it can mean a security risk as any malware can open up ports for unauthorized access to your network. You can mitigate the risk by allowing UPnP only for specific devices using static ip address.

Regarding Steam online games they usually work out the box. When it doesn't, it's usually due to double NAT as a result of the ISP running CG-NAT. A public ip address is more or less a requirement if you want to be able to utilize all features in the games (this was mentioned in a previous post regarding different NAT "levels")

My son often goes to lan parties at the uni where there is a huge gaming society club for youngster and where there can be 100's of people playing games from Steam like CS with no special setup in the router besides upnp and a dedicated subnet for gaming. If there is interest, I can ask exactly what their router configuration looks like.

Mikrotik routers are very flexible but also requires significantly deeper knowledge than normal consumer devices. Also, there aren't as many guides for Mikrotik when it comes to gaming as there are for other vendors like Asus, TPlink and similar. If you are ever going to invest in a new router for gaming purposes, I would recommend Asus with the Merlin FW which enables a lot of extended features and the ability to install add-ons (which is very popular in the gaming community)

Some guides I browsed through that might be useful:

https://steamcommunity.com/app/582010/d ... 7430299615
https://portforward.com/nat-types/
https://steamcommunity.com/sharedfiles/ ... =561836866
https://help.mikrotik.com/docs/display/ROS/UPnP
https://steamcommunity.com/sharedfiles/ ... =165136021
https://steamcommunity.com/app/582010/d ... 7430299615
https://help.steampowered.com/en/faqs/v ... -DA21-31EB
https://steamcommunity.com/app/582010/d ... 470/?ctp=2
https://www.top10vpn.com/guides/how-to- ... -nat-type/
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 4:24 pm

You mentioned that the type of online gaming you are referring to is through server relay and not for a few people playing on a host platform like Switch/XBox/PS5. These platforms require Fullcone NAT, and if you don't play games, you should not question the needs of a gamer.

As for your statement that it is a wrong idea to deeply understand RouterOS, the MikroTik team has made many efforts to lower the entry barriers, including launching the MikroTik Home app. Similarly, I have developed similar software to provide simple management tools to make using RouterOS as easy as using Asus and other consumer routers.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 5:14 pm

Sorry, my bad I didn't mentioning we also discussed gaming consoles, mostly xbox and ps but the same applies to nat usage as well. Regarding the switch (lite) we got stuck talking about cracking rather than possible network problems.

If you call quick-set a "consumer" friendly inteface we definitely have different options regarding that but that's ok. ;-)

My advice is that you put some more effort to and dig deeper what you really need in terms of connectivity before shouting out loud that full cone nat is the only solutions for a hypothetical very common problem (that might not even exist). Thus, if you bring us a full network topology where all ports/connections are stated in full detailj that demonstrates it's a very common problem I think you will get better attention and who knows, even a possible solution.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 5:24 pm

So Larsa, If I have a tenant who plays online with a gaming console with others and is having issues, lets say not hearing others, what is the solution..............
Enable upnp to that single device ( the gaming console) or in my case the isolated VLAN the gaming console is on. Also enable upnp on the input chain rules for that vlan....

Or is port forwarding enough or do both................
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 6:05 pm

I see, is that "tenant" possibly called anav? ;-)

If you already have a controlled env the easiest way to solve it is probably to use upnp otherwise you have to set up a bunch of port forwards that might be a problem when you want to switch games. I presume "he" has a public ip, right?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 6:30 pm

Not me, too old for such things LOL, I think its hockey or something........ I have a public IP yes...........
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 6:54 pm

UPnP should be solution (for single NAT) for everything that supports it. That should be any non-ancient game. Unless authors were too progressive and went only with more modern PCP. It wouldn't be wisest choice to support only that without UPnP as backup, but if you wanted, you could partially blame also router manufacturers who don't support modern technologies. ;)
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 6:57 pm

"Don't connect MikroTik's AP to MikroTik's RouterOS if you don't want your AP's performance to deteriorate."
rofl, stroke of genius right there.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 7:20 pm

@anav: Be careful with untrusted others. UPnP's problem is lack of security. You can help it a bit, e.g. you can control who uses it (or more precisely who can control it), by allowing access only from some devices (firewall filtering by IP or better MAC address) or interfaces. So you can allow access from your gaming console that you mostly trust to not do anything bad (unless it gets some virus) and block everyone else. Not great, but better than nothing. But granting access to your wannabe hacker tenant is not safe and VLAN won't help you at all, because anyone who can control UPnP can add any rule with any destination, not just to own address. It could be your super important server in different network. You could prevent it with firewall filter config (basically get rid of universal "allow all dstnat" rule and use only manual ones, which would be slightly annoying). In this case, static dstnat would be better (safer). Problem with that is that it's not flexible, because it requires manual configuration.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Thu Feb 16, 2023 8:14 pm

Not me, too old for such things LOL, I think its hockey or something........ I have a public IP yes...........

Sure, blink blink. haha....

Anyhow, I forgot to mention regarding upnp (besides to only use it on the vlan) make sure you turn of "allow-disable-external-interface". If you decide to use static forwarding instead, upnp is a great trace tool in order to show what ports that are needed.
 
marekm
Member
Member
Posts: 379
Joined: Tue Feb 01, 2011 11:27 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 1:35 am

I'd like to say "me too" asking for this feature in RouterOS.
I'm running a small local ISP and would like to provide pre-configured MT routers to customers, with as few support issues as possible. Just tired of cheap buggy unsupported SOHO routers.
Some customers are gamers, and I've heard some (though rare) complaints about NAT issues, using some (back then unfamiliar to me) terminology where at some other ISP they had "open NAT" while on my network they see "moderate NAT" and they want the "open" back. I provide public IPv4 via PPPoE (no CGNAT) and enabling UPnP in customer's router fixed the issue, but when I help them configure their routers, I prefer to disable insecure options by default (like UPnP, or WPS) so I'm not the one to blame when they get hacked. But without UPnP and without full cone NAT, I need to explain to them how to set up port forwarding etc. So the "full cone NAT" option would be a nice middle ground (easy to enable with no special configuration unlike port forwarding, and less insecure than UPnP).
It's not trivial to implement (as shown by Linux still not supporting it, not sure about *BSD) but another benefit could be reduced size of conntack table - instead of many (src-address, dst-address, reply-src-address, reply-dst-address) entries, just one (src-address, ANY, ANY, reply-dst-address) for one local UDP socket (IP:port) talking to many remote ones.
While I'm all for IPv6 too, some issues still prevent me from deploying it: MT PPPoE server not fully supporting "Delegated-IPv6-Prefix" so I switched to VyOS, but then it turned out too many customers have buggy Phicomm routers that break when IPv6 is enabled on accel-ppp server (MT PPPoE doesn't have this bug, it's a combination of specific Phicomm+accel-ppp bugs that breaks IPv4 even though Phicomm doesn't even support IPv6, but tries to negotiate it anyway then fails miserably and disconnects whole session against the RFC recommendation, bad luck...).
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 7:37 am

[...]when I help them configure their routers, I prefer to disable insecure options by default (like UPnP, or WPS) so I'm not the one to blame when they get hacked.
So the "full cone NAT" option would be a nice middle ground (easy to enable with no special configuration unlike port forwarding, and less insecure than UPnP).
[...] another benefit could be reduced size of conntack table - instead of many (src-address, dst-address, reply-src-address, reply-dst-address) entries, just one (src-address, ANY, ANY, reply-dst-address) for one local UDP socket (IP:port) talking to many remote ones.[...]
Somehow the text above screams at me WRONG.
Also they kinda contradict eachother.
Opening a ton of ports in customer routers you consider safer?
UPnP can be secured, I've made a feature request (SUP-65820) a while ago (12/Nov/21) so that clients can open ports only for themselves, not for other IPs, it was replied that they'll look into it if they get more similar requests.
Guess nobody wants a more secure UPnP in RouterOS because it hasn't been done yet.
So you keep using that insecure UPnP or manually open ports if you're too lazy to write a feature request for what bothers you.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 10:14 am

Full cone nat is just a fancy name for 1:1 nat or static nat or whatever you want to call it. It is achievable in ROS by adding one srcnat and one dstnat rule, thats it.
Or by "full cone support" you mean adding checkbox "enable full cone nat" next to "enable nat" in quickset?
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 11:12 am

You mentioned that the type of online gaming you are referring to is through server relay and not for a few people playing on a host platform like Switch/XBox/PS5. These platforms require Fullcone NAT, and if you don't play games, you should not question the needs of a gamer.

As for your statement that it is a wrong idea to deeply understand RouterOS, the MikroTik team has made many efforts to lower the entry barriers, including launching the MikroTik Home app. Similarly, I have developed similar software to provide simple management tools to make using RouterOS as easy as using Asus and other consumer routers.

Manually adding a dstnat rule can only map to one IP, and when there are several devices in the home that require mapping, it won't work. This is because the initiating port may be different every time, and it's a large range. It's not feasible to map all ports to one internal IP. Therefore, it's necessary for RouterOS to support fullcone NAT.

If a checkbox can be added to achieve this, it would be great.

rfc3489 specifies the usage of port 3478, but in reality, many games and software use UDP ports 3478-3481. This includes commonly used applications such as Skype. Games typically instruct users to be mindful of which ports are blocked by their firewall.

If a single rule is used for each port, setting 3478 for Xbox while other devices use 3478 will render the rule ineffective. This is because the console or app will use its own mechanism to determine which port to use, which is outside the user's control. Some games always use port 3478, while others randomly select ports from 3478-3481.

in RFC3489

A STUN server MUST be prepared to receive Binding Requests on four
address/port combinations - (A1, P1), (A2, P1), (A1, P2), and (A2,
P2). (A1, P1) represent the primary address and port, and these are
the ones obtained through the client discovery procedures below.
Typically, P1 will be port 3478, the default STUN port. A2 and P2
are arbitrary. A2 and P2 are advertised by the server through the
CHANGED-ADDRESS attribute, as described below.

https://www.rfc-editor.org/rfc/rfc3489
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 11:28 am

Full cone nat is just a fancy name for 1:1 nat or static nat or whatever you want to call it. It is achievable in ROS by adding one srcnat and one dstnat rule, thats it.
No, that is not correct.
1. that 1:1 mapping is not called "full cone NAT", it is called "DMZ host". that is a different thing, maybe you want to put a config item for it in Quick Set (additional to the port mapping button).
2. the "full cone NAT" works for SEVERAL devices on the local network (also with ONE external IP), and it works automatically.

Of course it is a big security risk, and you may want to have a pre-configured list of internal devices that have it enabled, where the default is "disabled".
But that again introduces a config exercise.

I still think it is a problem of the game software, but seeing that one of the affected systems is from Microsoft, I do not expect any clever development in the network side of things there.
Of course there are other devices that are in a similar NAT mess, like VoIP phones.
 
holvoetn
Forum Guru
Forum Guru
Posts: 5326
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 11:54 am

1. that 1:1 mapping is not called "full cone NAT", it is called "DMZ host". that is a different thing, maybe you want to put a config item for it in Quick Set (additional to the port mapping button).
Obviously I have nothing to say in the matter (I dislike gaming but that's a personal choice) but this sounds like a very VERY bad idea ... simply an accident waiting to happen.
There is a reason on most devices/modems I have seen, that setting is usually part of a separate Advanced section with added warnings and disclaimers.
As it should be.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 12:01 pm

There probably should be a warning on entry of RouterOS management interfaces then, that says "everything you do here can be dangerous".
We frequently see people deleting, disabling or modifying firewall rules in such a way that they remove all security. There is nothing that can be done about that in a system like RouterOS. It may be the reason that other manufacturers use a simplified management interface with limited capability, but RouterOS is not for that market.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 12:17 pm

You keep mentioning rfc3489 which clearly says what "full cone nat" is supposed to be.
"A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address."

Further if we look at what anyone else is saying, for example:
https://learningnetwork.cisco.com/s/que ... minologies
If we look at RFC 3489 in section: 5. Variations, the Full Cone NAT means that the private IP and port of an internal host are always mapped or translated to the same public IP and port when going to internet, this means that from this point of view, this internal host is reachable from internet using its own public IP and Port. In vendor’s language, this type of NAT behavior is called Static NAT.

From, let’s say Cisco vendor a Static NAT allows the mapping of public IP Addresses to hosts inside the internal network. In simple english, this means you can have a computer or a server on your private network that exists on the Internet with its own real IP. It is one-to-one mapping of a private IP address to a public IP address, or private IP/Port to a public IP/Port.
So we can conclude that the Full Cone NAT is defintely a Static NAT people traditionally used with many vendors.

Which means It is not supposed to work with more than one host behind NAT, because it is literally a 1:1 mapping.

So from everything you are saying you need something else not a "full cone nat" defined in RFC 3489.

To create a solution, more info is required on what exactly those games that do not work require. Otherwise it looks like request to create a "magic" that allows router without any port mapping (in fact without any info at all) guess that random host on the internet wants to connect specifically to one of the internal hosts behind nat.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 12:23 pm

No wonder that rfc 3489 is obsolete and does not mention any cones or other shapes of NAT anywhere else.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 12:41 pm

Which means It is not supposed to work with more than one host behind NAT, because it is literally a 1:1 mapping.
NO NO NO that is not true! You misunderstand the matter.
It is not different from normal NAT in that outgoing traffic from an internal host+port creates a mapping to the external address+port. The mapping is not for all traffic, but only for that particular port.

So HOST1 sends a UDP packet from port 5000 to the SERVER at port 5000. The NAT translates it to EXTERNAL:5000 and sends it to SERVER.
Now HOST2 sends a UDP packet from port 5000 to the SERVER at port 5000. As port 5000 is already allocated, it translates it to EXTERNAL:65000 and sends it to the SERVER.
Up to this, not different from the usual NAT operation.

The difference is: when now some arbitrary other system on internet sends a packet to EXTERNAL:5000 it is forwarded to HOST1:5000. When an arbitrary system on internet sends a packet to EXTERNAL:65000 it is forwarded to HOST2:5000.
That is different from normal NAT: that would check the source address of the traffic, find no corresponding outgoing traffic, and discard it.
So it essentially is NAT without the matching of external addresses. Because of that, the SERVER can tell another client (on another internet connection) what EXTERNAL:port combination it knows for a client, and the clients can communicate directly (peer-to-peer). That is not possible with normal NAT usually, unless the server tells both clients "try sending traffic to port 5000 at another external IP", and it MAY work when both of the routers decide to leave the port number untranslated. That will of course fail when there are multiple clients on the same internet line (using the same port).
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 12:53 pm

But that is what I am trying to say, what you describe does not match the definition of "full cone nat" in RFC 3489. It is something else.
Do you know any standard, document/specification, or RFC that describes this type of nat? Or it is just someone's interpretation of what a "full cone nat" should be?
As far as I have found "full cone nat" behavior differs between different vendors and none of them match the statement in RFC except the ones that mask 1:1 mapping behind the "full cone" checkbox.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 12:53 pm

Which means It is not supposed to work with more than one host behind NAT, because it is literally a 1:1 mapping.
NO NO NO that is not true! You misunderstand the matter.
[...]
Read the RFC again slowly.
If other vendors decided to name "Full Cone NAT" something that it's not described in that RFC, doesn't mean some other Vendor has to do the same thing.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 12:54 pm

[...]
Agree.
I've asked earlier what that option does on other devices that have such a thing, I got crickets.
Anyway, any plans to add more features to the existing UPnP?
Or replace it with MiniUPnP which seems to support even NAT-PMP / PCP and expose all it's settings? It would even support the asked for, "secure mode".
Or make it an extra package?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 1:04 pm

We can implement it and maybe call it "tetrahedron nat" to avoid confusion.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 2:09 pm

Just to be clear, RFC-3489 is NOT a spec on "NAT types". The now obsoleted RFC merely describes the NAT'ing schemes that the protocol might face & not an endorsement for them. ICE is the preferred mechanism for NAT traversal today, which includes STUN. I'd say the IETF standards in fact highlight the problems of routers from doing weird things with NATs, and merely describe the needed mechanism to deal with the odd-ball scheme employed in circa 2003. There is no need for innovation in IPv4 NAT'ing.

So I just don't see the generic problem here... Any modern application, games included, have a variety of choices on how to communicate outside. The standards would point applications to WebRTC for simple needs, or directly using ICE for more complex needs, if ports need to be opened. uPnP gets a bad wrap because it's original specs were flawed, but that's always an option too, since a lot of applications do support it. Or enabling IPv6, which is underutilized and useful here. Plus, RouterOS does offer "netmap" which offers a lot of capacity for doing much of the "DMZ host" things.

What specific application, or game, does this even come up as a need?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 2:13 pm

All I know is that at one time I tried so many things port fowarding, upnp, isolating host on vlan, but I never got it to work the way the gamer said it should work. I came to the conclusion it was not feasible on RoS. Not being a gamer I could care less, but as an MT homeowner I would be royally pissed if MT implemented this hard to pin down issue BEFORE...............
An options package for ZeroTrust Clouflare tunnel for ALL devices. Then hosting any type of server not just game servers could be done without exposing public IPs................ :-) :-) :-)
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 2:49 pm

[...] but as an MT homeowner [...]
You wrote lawn mower wrong.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 3:13 pm

Online games that use P2P for networking, whether on PC or console platforms, still use the stun method for networking. Additionally, NAT1 is required, so Fullcone NAT is necessary, and most home routers have added this feature. This is why I believe that MikroTik should add support for

Fullcone NAT or at least add this feature to devices in the "Wireless for Home and Office" category on their website.
https://mikrotik.com/products/group/wir ... and-office
 
marekm
Member
Member
Posts: 379
Joined: Tue Feb 01, 2011 11:27 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 3:21 pm

We can implement it and maybe call it "tetrahedron nat" to avoid confusion.
At least one other vendor already uses the Full Cone / Restricted Cone / Port Restricted Cone / Symmetric NAT terms.
I think it is quite well explained there, even with some drawings.
https://info.support.huawei.com/info-fi ... n/NAT.html

These terms are also reported by some VoIP devices (I think I've seen it in some Grandstream ATA - so it's not just for games).
I don't think it's a good idea to invent another new terms for something that works as already described, that would cause even more confusion.
While we may not trust that Chinese company too much, they are still a big vendor and lots of ISPs use their devices (like GPON routers).
BTW, while I think GPON is too complex/proprietary/expensive, it wouldn't be bad if some MT new products support both ends (client and ISP) of simpler, open standard 10G-EPON someday.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 3:42 pm

 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 4:16 pm

I'm just thinking this can be solved with the right netmap action in the NAT.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 4:50 pm

You kinda shot yourself in the foot with those links.
Neither of them contain an example of what you think that "full cone nat" is.
Take the Juniper example, the "full cone" configuration there is nothing more than a 1:1 static NAT of 5 external IPs to 5 internal IPs, get it into your head already.
Last edited by Znevna on Fri Feb 17, 2023 5:01 pm, edited 1 time in total.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 4:54 pm

here is fullcone NAT from cisco and juniper

https://www.cisco.com/c/en/us/support/d ... er-co.html
From that cisco manual:
Cisco IOS® routers' NAT implementation when it performs PAT is symmetric by default. Therefore, you are expected to see UDP connection issues with these routers that perform NAT.

However, the Cisco IOS-XE routers' NAT implementation when it performs PAT is not symmetric. When you send two different streams with the same source IP and port but to different destinations, the source gets NATED to the same inside global IP and port.
As per RCFC 4787: With Endpoint-Independent Mapping (EIM), the NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port.
From a client, when the endhost runs the commands nc -p 23456 10.0.0.4 40000 and nc -p 23456 10.0.0.5 50000, on two different terminal windows, here are the results of the NAT translations if you use EIM:
Pro Inside global Inside local Outside local Outside global

tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.4:40000 10.0.0.4:40000

tcp 10.0.0.1:23456 192.168.0.2:23456 10.0.0.5:50000 10.0.0.5:50000
Here you can see that different traffic flows that have the same source address and port get translated to the same address/port regardless of the destination port/address.

Just checked RouterOS does exactly that. nc -p 12345 1.1.1.1 11111 and nc -p 12345 2.2.2.2 21111
[test@MikroTik] /ip firewall connection> print detail interval=2 where dst-address="1.1.1.1:11111" || dst-address="2.2.2.2:21111"
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
1 C s protocol=tcp src-address=192.168.88.115:12345 dst-address=1.1.1.1:11111 reply-src-address=1.1.1.1:11111
reply-dst-address=x.x.x.x:12345 tcp-state=syn-sent timeout=0s orig-packets=3 orig-bytes=192 orig-fasttrack-packets=0
orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

2 C s protocol=tcp src-address=192.168.88.115:12345 dst-address=2.2.2.2:21111 reply-src-address=2.2.2.2:21111
reply-dst-address=x.x.x.x:12345 tcp-state=syn-sent timeout=3s orig-packets=2 orig-bytes=128 orig-fasttrack-packets=0
orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

as you can see RouterOS also maps to the same inside global ip and port for all streams.


as for huawei they just try to clasify their existing nat methods based on rfc3489 description and basically shows in examples static nat, the same as mentioned before in this topic.

So none of those docs provide any actual answer what is the problem.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 5:34 pm

as you can see RouterOS also maps to the same inside global ip and port for all streams.
Yes. But now when 3.3.3.3 tries to connect to x.x.x.x:12345, will it reach 192.168.88.115:12345? No, because RouterOS will correctly see it as new unsolicited connection. But this <whatever_it_would_be_called> NAT would allow it.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 5:38 pm

It would if you configure static nat/full cone nat x.x.x.x to 192.168.88.115.
But you just ran out of public IPs for the rest of your consoles (if you have only one public IP that is).
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 5:51 pm

Correct. But with <whatever_it_would_be_called> NAT being dynamic and creating incoming dstnats for each outgoing connection, one public address would be good enough for several consoles.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 6:12 pm

There's no standard describing that behaviour, can you link to any?
 
marekm
Member
Member
Posts: 379
Joined: Tue Feb 01, 2011 11:27 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 6:31 pm

Technically not a standard, but RFC 3489 was mentioned, and already explained quite well here. Smaller NAT table size (just one private IP1:port1 <-> public IP2:port2 mapping for any number of external peers communicating with one internal host:port over the Internet) may not matter much when done in software (RAM is cheap), but also helps with limited (16-bit) port numbers if all you have is a single public IPv4 address, and for L3 HW offloaded NAT (some high end switch chips can do it, but have limited table sizes). If it's too open, it can always be restricted by filter rules (for example to specific ports used by specific games), but NAT alone (without filtering) was not really meant for security.

There are various other ways around it, but they are either a bigger security risk (UPnP) or need manual configuration (DSTNAT aka port forwarding), or limited to one internal host (aka "DMZ" in SOHO routers), and many customers need help (believe me, it is sometimes exhausting enough to tell them on the phone how to configure basic PPPoE and WiFi on a cheap router accidentally reset to factory defaults, because they thought the reset would magically fix whatever issue they had, or the same button is shared with WPS and their new printer's manual said to press that button, they didn't have time read about manual WPA2 setting a few pages later).
Last edited by marekm on Fri Feb 17, 2023 6:42 pm, edited 1 time in total.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 6:32 pm

Aha, looking for some kind of automatic NAT feature! :-D

For the vast majority this is solved using consumer tailored protocols as UPnP that was followed up with NAT-PMP and lately PCP. Static one-to-one (1:1) NAT-like solutions are only needed in very rare cases and might in most cases be solved using standard RoS. This might be a nice to have feature, but if anyone is looking for a gaming router with a consumer friendly interface better look elsewhere IMO.

https://en.wikipedia.org/wiki/Universal_Plug_and_Play
https://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol
https://en.wikipedia.org/wiki/Port_Control_Protocol

You are most welcome! :-)
Last edited by Larsa on Fri Feb 17, 2023 6:53 pm, edited 2 times in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 6:37 pm

It is more like "we have a device made by [company without clue about networking] and we are using it on [network with too few addresses]. now instead of solving either of those problems, we want third parties to solve it for us!".
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 6:51 pm

You are most welcome! :-)
¡Bonjour! :lol:

Apple introduced NAT-PMP in 2005 by as part of the Bonjour specification,
Yeah I think Mikrotik skips the RFCs that have "Apple Inc." somewhere at the top. Just ask the 50K readers of mDNS thread.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 6:57 pm

Technically not a standard, but RFC 3489 was mentioned[...]
[...]There are various other ways around it, but they are either a bigger security risk (UPnP) [...]
rfc3489 only describes some nat types (variations?), and it does not cover the automatic dstnat rule creation some of you keep mentioning here.
also rfc3489 was obsoleted by rfc5389 which in turn was obsoleted by rfc8489, which .. guess what, has no mention of such a thing.
Anything from the last decade that you can mention?
Also are you seriously considering UPnP/NAT-PMP/PCP a "bigger security risk" which only opens ports if an app wants/needs to open a port VS blindly opening ALL the ports that an app uses? IN WHAT WORLD is the "bigger security risk" in the first option?
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 7:36 pm

Different types, but I agree that both are security risks.

As for "automatic NAT" and pals, any kind of automation can be exploited especially if there is no built in secure like for UPnP. I don't know the situation of UPnP today but NAT-PMP is significantly better and PCP is very secure due to built-in authentication and access control mechanisms.
 
marekm
Member
Member
Posts: 379
Joined: Tue Feb 01, 2011 11:27 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 7:56 pm

rfc3489 only describes some nat types (variations?), and it does not cover the automatic dstnat rule creation some of you keep mentioning here.
also rfc3489 was obsoleted by rfc5389 which in turn was obsoleted by rfc8489, which .. guess what, has no mention of such a thing.
Anything from the last decade that you can mention?
Also are you seriously considering UPnP/NAT-PMP/PCP a "bigger security risk" which only opens ports if an app wants/needs to open a port VS blindly opening ALL the ports that an app uses? IN WHAT WORLD is the "bigger security risk" in the first option?
No need for any "automatic dstnat rule" creation if NAT code is modified to add a single entry to the connection table (map internal ip1:port1 <-> public ip2:port2 for any remote ip:port), then any packets reaching public ip2:port2 from outside will find their way to internal ip1:port1 and just refresh the timer to keep the mapping alive, without creating any new one.
The fact the RFC 3489 is obsolete doesn't mean all its copies must be removed, it's still not a DMCA crime to read it :)
UPnP allows any host on the LAN to open any ports for any (even different) host on the LAN, unless specifically configured to restrict it. Perhaps the newer solutions are better, but people just want their games to work and will change ISPs to one who gives them "open NAT" if they only have "moderate NAT" (whatever that means, probably some Xbox term) in my network.
An untrusted app can always compromise the host it's running on, opening all ports on that host is just one way to do it but there are others (without opening ANY ports, like encrypt all files it has access to and ask for some bitcoin to decrypt) but that still doesn't compromise the whole network.
As a small ISP (one person business for a few hundreds of customers) I'm just trying to find some middle ground to give people reasonably secured routers that don't cost me hours of support calls to configure properly, and also don't break their games (some of which want direct p2p communication with other users).
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 8:13 pm

No need for any "automatic dstnat rule" creation if NAT code is modified to add a single entry to the connection table (map internal ip1:port1 <-> public ip2:port2 for any remote ip:port), then any packets reaching public ip2:port2 from outside will find their way to internal ip1:port1 and just refresh the timer to keep the mapping alive, without creating any new one.
But bruh, that's called a dst-nat rule, I mean, that's exactly what it does, here, we have a manual for it:
https://help.mikrotik.com/docs/display/ ... inationNAT
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 8:16 pm

As a small ISP (one person business for a few hundreds of customers) I'm just trying to find some middle ground to give people reasonably secured routers that don't cost me hours of support calls to configure properly, and also don't break their games (some of which want direct p2p communication with other users).
Then why have you chosen MikroTik? There are dozens of brands of typical home routers that fit that bill perfectly.
Or is it a Wireless ISP where you give them e.g. LHG5 that function both as the link and the home router?
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 8:32 pm

Don't overthink it, it's just a tool, it's up to you how you use it. Take the netfilter module from first post (https://github.com/Chion82/netfilter-full-cone-nat). If it was in RouterOS, you could do e.g:
/ip firewall nat
add chain=srcnat src-address-list=consoles protocol=udp out-interface=WAN action=tetrahedronnat to-ports=60000-65000 comment="Gaming consoles in LAN"
add chain=srcnat protocol=udp out-interface=WAN action=masquerade to-ports=20000-59999 comment="everything else" 
add chain=dstnat in-interface=WAN protocol=udp dst-port=60000-65000 action=tetrahedronnat
by which you'd allow this automatic port opening initiated by LAN devices in "consoles" list, with dedicated port range. And everything else would be safe. What's wrong with that?

But again, I'm not pushing it, I just find it interesting. If it's choice (is it?) between this and all features one might ever need for IPv6 but are not available yet (you know, to think more about the future than the past and to help it happen sooner), I'm all for the latter (and this kind of NAT could be added after that, if anyone would be still interested).
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 8:33 pm

But that behavior is not based on anything.
Just some random module based on some other random implementation.
Also, I saw what AnyDesk does, when you connect to a remote computer, it opens a random external port via upnp(? I didn't check via what, I'm using miniupnpd here) and maps it to localip:listenport (listenport that's always the same) so that session attempts to talk directly with your computer via that random port, not via the servers (if it can).
So adding some random "feature" that would add a dst-nat rule for the said listenport would be useless for this program, as example.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 9:18 pm

Well, perhaps in keeping with the style, action="tetrahedron-nat"
Perhaps "unmasqed-masquerade"?
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 10:02 pm

@Znevna: I agree that it's slightly weird. I suppose you can see the possible problem and how this solves it *1, right? The weird part is, how is it actual problem, unless we're talking about some software from pre-NAT times? Because anything aware of NAT must assume that direct incoming connections don't work. It can be user error, when software supports UPnP, but user doesn't enable it. Even if there are good reasons why not enable UPnP *2, it's still user who broke it. This is for single NAT. With multi-NAT, the problem is elsewhere, it would need either some "UPnP chaining" (I didn't study it much, but PCP should have it), or this type of NAT would do the trick too.

-
*1 my previous description how it nicely "neutralizes" NAT
*2 your suggestion to (I assume optionally) limit UPnP to allow opening ports only for own IP address would certainly improve security and remove one reason for avoiding it
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 10:19 pm

Of course there is a reason why any modern solution uses "cloud servers". When everybody connects a cloud server outbound from their client behind NAT, and those cloud servers relay the traffic to the correct client, it all works perfectly.
I can understand that when gaming, you want the lowest possible latency, but of course most cloud service providers have data centers all around the world and it would usually be possible to select a cloud server that adds almost no latency.
When you still want to communicate peer-to-peer, there is IPv6. Not trivial either, because you will need some firewall exception, but at least it is well understood: allow new traffic incoming on some port number, that can be a fixed number. And there is no issue when having several consoles, as they will have a different address.

So in fact, it is only the stubborn that are suffering. And of course the customers of the clueless game console makers.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 11:03 pm

Yeah, and it's somewhat amusing that much of the debate now seem to focus on new variants of "xxx-NAT", how it might be implemented or how "xxx-NAT" makes RoS gamer friendly rather than try to identify the real issue.

But why!? (@Sob!) Just because you can or is fun to have?? Bring us the real problem!

If one really want to please Xbox and Playstation players, I'd suggest fixing UPnP/SSDP in the first place by adding more security settings for control and access, instead of pushing hypothetical discussions about full-cone nat et al.

FIW, I checked my son's Asus and with UPnP IGD enabled his Xbox always gets "moderate NAT" and he has never had any problems except when our previous ISP switched to CGNAT and started charging for a public IP address (with the new provider, we got 4 public addresses for free).
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 11:29 pm

But why!? (@Sob!) Just because you can or is fun to have?? Bring us the real problem!
What did I do? I'm just explaining and discussing interesting technical thing. Because it's just that, interesting. I'm not saying that MikroTik should drop everything else and add this, not even necessarily add it at all. I even wrote it explicitly. English is not my native language, so it's possible that it could be expressed better, but I still think it was clear. Should I get some lawyer-approved disclaimer and stick it to every post? And it's not like anyone from MikroTik listens to me, I'm just random nobody, so if they happen to add this, it won't be because of me. And in case they would, I would blame myself so much for not using my talent to get something more useful. :lol:
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 11:30 pm

I guess what are you looking for? [to those actually requesting this...]

if it's a RouterOS replica of the "full cone nat"? Not a lot of places for it, other than /ip/firewall/nat... [so look like @Sob's example if they did this ]
Or, are y'all asking NAT-PMP, etc support? Totally different.

In other words, what's going to make the Xbox, etc happy with a Mikrotik?
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 11:39 pm

Sob: Should I get some lawyer-approved disclaimer and stick it to every post?

Yes, that's exactly what I mean! It's very much important for the formal structure of the debate! :lol:
Last edited by Larsa on Fri Feb 17, 2023 11:53 pm, edited 1 time in total.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Fri Feb 17, 2023 11:53 pm

Amm0: In other words, what's going to make the Xbox, etc happy with a Mikrotik?

A fully working UPnP/SSDP with IGD.

I'd also recommend some extended security settings for control and access of what devices can use this feature and "sandbox" the rest of the RoS environment for unauthorized access.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 12:02 am

Basic uPnP is already covered by RouterOS. SSDP has nothing to do with NAT, AFAIK, so not sure what you mean by "UPnP/SSDP"?

But, perhaps, good news for Sob is that NAT64 is prerequisite for [PCP] IGD. https://www.rfc-editor.org/rfc/rfc6970
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 12:16 am

Those are core parts of UPnP. SSDP is used for communication and IGD is an extension for managing NAT. Unfortunately, the documentation does not include which parts and versions of UPnP that are implemented in RoS.

PCP is a winner but I'm not sure about the status regarding Xbox and Playstation. Asus Merlin supports both NAT-PMP and PCP since many years back. I believe it's included in the standard fw these days.

Btw, there is a full-cone NAT add-on available for the Merlin fw, but the developers advise against using it since "Many gamers are convinced this is the magic bullet to solve all their console-related port forwarding issues [when the basic problem usually lies elsewhere]". Sounds familiar? ;- )
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 1:40 am

Let's clarify one thing, the router doesn't care about SSDP - it's multicast on the local subnet by design and not routed. But does same thing as mDNS, so it's possible to proxy between subnet – but that's a different topic I think. Especially since MT does not support mDNS proxy either. Neither SSDP nor mDNS were design to be routed across subnets.

IGDP, NAT-PMP, and IGD-PCP are all application-requested things.
- Mikrotik's supports IGDP via /ip/upnp - https://en.wikipedia.org/wiki/Internet_ ... e_Protocol
- NAT-PMP is from same era, but from the Bonjour/zeroconf family. Not support by Mikrotik.
- Haven't studied RFC-6887 for "IGD PCP" but seem to replace IGDP and include(/require?) IPv6 support. Referenced NAT64, which isn't support as of 7.8rc1.

This "full cone NAT" that start us here... From the docs, it's look exactly like @Sob if done "by hand" - it just some firewall rules [requiring additional support in netfilter/connection tracking]. "Automatic" stuff comes from the above protocols (e.g. application/game console/etc requests their preferred port configuration from a router)

But I'm just thinking enabling /ip/upnp with wan set to "external" and the lan set to "internal" help in most "gaming cases".... I have seen /ip/upnp work do various mapping port mapping from security cameras and the like, so I know it's not broken. Just old.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 3:29 am

Automatic stuff, if it means that mapping created by outgoing connection also serves for new independent incoming connections, comes from this NAT type itself and doesn't need anything else. That's why it's in both srcnat and dstnat chains. The one in srcnat can be exactly same as existing masquerade/src-nat, only with some extra flag to mark created mappings. The new one doing something not previously available is the other half in dstnat. It would look at connections table for these mappings and if destination of new connection matches what's in reply-dst-address, it would forward it to src-address, as if there was dstnat rule from reply-dst-address to src-address.

If one (annoying) property of NAT (srcnat where you hide internal subnet behind single public address) is that it doesn't allow incoming connections to individual internal hosts (without adding dstnat rules), this is sort of anti-NAT. You could literally take some P2P software from pre-NAT times, stick it behind this and it would work as if there was no NAT at all. Just an example, obviously not something you'd need often.

Disclaimer: I'm just discussing interesting technical thing, because I find it interesting. I'm not saying that MikroTik must add it. No animals were harmed while writing this post, only one cat claims that he was neglected and not given enough food that he deserves, but I wouldn't believe him, he's fed more than enough.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 4:19 am

Automatic stuff, if it means that mapping created by outgoing connection also serves for new independent incoming connections, comes from this NAT type itself and doesn't need anything else.
In the case of "tetrahedron-nat", the client doesn't really get confirmation and may expect that per one of these protocol. ICE/STUN can deduce the decision, but they can already do that with masquerade (and any ALG turned off).

But as I understand the problem, it's that some stuff has preferred port's they'd like to open. So they do it by one of via one of the PCP protocols. Cameras NVRs do this all the time, imagine same as games.
- device (console, camera, other consoles in same house, etc.) use SSDP to find the router or other "local neighbors" – this has nothing to do with NAT'ing.
- device (game or camera NVR) request some specific port map, to ideally keep their defaults the same (e.g. 8080 inside, 8080 outside) – with 8080 being being some listen port for the device. Thus avoid needing a hairpin nat configuration, assuming 8080 wasn't taken and exact firewall config.
- the latest "IGD PCP" spec is way more complex and deals with more cases than just client<->router... e.g. IPv6 and likely large-scale CGNATs.

Now this "tetrahedron-nat" NAT-type may be need to fulfill some aspect of PCP, but I doubt it. e.g. if client is negotiating the port, the result be dynamic dstnat/srcnat NAT entries based on PCP/etc decision, this is what's done for the older UPNP protocol supported by Mikrotik.


Disclaimer: I'm certainly advocating for this either. Just trying to unwind it. Still think...
There is no need for innovation in IPv4 NAT'ing.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 4:46 am

If we're talking about single NAT, this is best suited for ancient/dumb/ignorant client.

"If I connect to some server and tell it that I'm alive, then server sees my address and port I'm using, and if I'm listening on that, then anyone who server tells it to can connect to me, right? What? My real address and port could be different from what server sees? NAT? What is that? It will still work, right? Asking router to open port? Eh, come again?"

This kind of client. :) So I understand questions whether it really exists (probably yes, everything exists) and if it's widespread (probably no).
 
mada3k
Long time Member
Long time Member
Posts: 682
Joined: Mon Jul 13, 2015 10:53 am
Location: Sweden

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 11:50 am

This is why Mikrotik should not bother with the Consumer/Ho-market.

Side-note: CGNAT-providers should provide more than one CGNAT-adress to avoid NAT-over-NAT issues.
 
holvoetn
Forum Guru
Forum Guru
Posts: 5326
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 11:55 am

CGNAT was created to solve ipv4 issues.
So... there's already a solution for that.
It's called ip6.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 12:09 pm

Carrier-grade NAT is an ISP-level solution that is not related to regular users. Even for DHCP and PPPoE that use CG-NAT, only one port and one IP address are allocated, and it does not allow assigning an IP address to each device.

Therefore, CG-NAT only solves the NAT problem up to the router, but not the NAT problem between the router and the game console in the home network.

Applying for support of Fullcone NAT is a solution to the NAT problem between the router and the game console, which is the problem in the LAN network behind the router, not at the ISP level. Moreover, these users' routers already have a public IP.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 12:28 pm

But that is what I am trying to say, what you describe does not match the definition of "full cone nat" in RFC 3489. It is something else.
As I wrote before, you do not understand it. What I wrote describes what is in RFC 3489 as well. You probably think "maps to the same address and port" means that the internal and external ports have to be the SAME, but it does not. It means that the translated port number does not depend on the external address, but only in the internal address.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 1:00 pm

So we're doing this in the weekend too then, ok.
rfc3489 is this:
STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)

Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs) (STUN) is a lightweight protocol that
allows applications to discover the presence and types of NATs and
firewalls between them and the public Internet. It also provides the
ability for applications to determine the public Internet Protocol
(IP) addresses allocated to them by the NAT. STUN works with many
existing NATs, and does not require any special behavior from them.
As a result, it allows a wide variety of applications to work through
existing NAT infrastructure.
Just because someone included there some NAT Variations with fancy names 20 years ago with short, interpretable descriptions, these are not the subject of that rfc.
https://www.rfc-editor.org/rfc/rfc3489 -> https://www.rfc-editor.org/rfc/rfc5389 -> https://www.rfc-editor.org/rfc/rfc8489
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 1:14 pm

So we're doing this in the weekend too then, ok.

:D :D :D

Just want to add that how various variants of NAT behaves regarding port mapping entirely depends on the implementation.

And lastly, full-cone NAT (or whatever one want to call it) is definitely no magic bullet to solve CGNAT related issues. Just buy a public ip address, enable UPnP or if possible implement ipv6 and you are ready to go.

Have a nice weekend! (tho I might come back :- )
Last edited by Larsa on Sat Feb 18, 2023 2:26 pm, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 1:29 pm

So we're doing this in the weekend too then, ok.
rfc3489 is this:
Some people have to go to work on some times at weekdays and cannot reply immediately.
I was referring to this from RFC3489:
5. NAT Variations

It is assumed that the reader is familiar with NATs. It has been
observed that NAT treatment of UDP varies among implementations. The
four treatments observed in implementations are:

Full Cone: A full cone NAT is one where all requests from the
same internal IP address and port are mapped to the same external
IP address and port. Furthermore, any external host can send a
packet to the internal host, by sending a packet to the mapped
external address.
Apparently @mrz thinks that this means that there must be a 1:1 mapping between internal and external address.
While that provides the above when having only 1 internal host, it is not a full cone NAT. It is what home router manufacturers call "DMZ host".
I think he mis-understands that in "IP address and port are mapped to the same external IP address and port" the two "ports" (internal and external) must be the same number.
That is not what is intended there, just like the internal and external IP are not the same address. What is intended is that any time an internal IP and port are translated to external, they are translated to the same external IP and port, i.e. a constant external port number for the internal host+port is chosen and maintained, independent of the external destination of the packet. AND the mapping works inbound as well, unlike a "restricted cone NAT", which has connection-tracking much like RouterOS has.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 1:38 pm

I can't find any reference in that document to support your personal interpretation.
Plus, you have the Juniper example somewhere above which contradicts with your personal interpretation:
https://www.juniper.net/documentation/s ... guring.pdf
nat-full-cone-configuring.pdf

[edit services]
nat {
pool static_nat_range {
address-range low 10.200.253.1 high 10.200.253.5;
}
rule static_nat_rule {
term sample-term {
nat-type full-cone;
from {
source-address-range {
low 10.100.136.1 high 10.100.136.5;
}
}
then {
translated {
source-pool static_nat_range;
translation-type {
source static;
}
}
}
}
}
}
It's just static NAT, no random dst-natted ports or other made up "solutions".
And something from Cisco https://learningnetwork.cisco.com/s/que ... minologies
If we look at RFC 3489 in section: 5. Variations, the Full Cone NAT means that the private IP and port of an internal host are always mapped or translated to the same public IP and port when going to internet, this means that from this point of view, this internal host is reachable from internet using its own public IP and Port. In vendor’s language, this type of NAT behavior is called Static NAT.

From, let’s say Cisco vendor a Static NAT allows the mapping of public IP Addresses to hosts inside the internal network. In simple english, this means you can have a computer or a server on your private network that exists on the Internet with its own real IP. It is one-to-one mapping of a private IP address to a public IP address, or private IP/Port to a public IP/Port.

So we can conclude that the Full Cone NAT is defintely a Static NAT people traditionally used with many vendors.

And:
RFC 3489 has been obsoleted by RFC 5389 where it is stated in Section 2 :

"Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there."
You do not have the required permissions to view the files attached to this post.
Last edited by Znevna on Sat Feb 18, 2023 2:19 pm, edited 1 time in total.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 2:15 pm

What you describe there is "symmetric NAT", also called "net map".
What do you think the term "cone" in "full cone NAT" stands for? Would you apply the term "cone" to a structure that is the same width on both ends?

And please don't come back with different RFC numbers all the time, I am not discussing with you but with @kcahrc and @mrz who refer to that old RFC 3489, not to other ones.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 2:23 pm

Oh, no. Symmetric NAT is explained right below what I've quoted previously from the same Cisco link.
For Symmetric NAT, RFC 3489 explains this kind of NAT as follow: internal host’s IP/Port are translated to different public/port when going to different destination on the internet. And it add an interesting sentence: only the external host that receives a packet can send packet back to the internal host, this means that this internal host is not reachable directly from internet like the Full Cone NAT but after initiating a traffic then the response is sent back to this host.

To conclude Symmetric NAT is another term of PAT from Cisco's perspective and Full Cone NAT is equal to Static NAT from Cisco's perspective.
You seem oddly confused about these terms.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 2:34 pm

Gentlemen, as many NAT implementations combine these types it is better to refer to specific individual NAT behavior instead of using the Cone/Symmetric terminology. Have a nice weekend! :-)
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 3:05 pm

Tetrahedron ftw.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 3:12 pm

Oh, no. Symmetric NAT is explained right below what I've quoted previously from the same Cisco link.
I am not that interested in Cisco (or Juniper) links. We are talking about home routers here, right?
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 3:52 pm

No, we are talking about "full cone NAT" as per the topic title, and the only decent documentation I've found regarding it is what I've linked already in here.
And sorry, I tend to trust some documentation instead of some random ideas from a random expert from the internet.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 4:27 pm

Full cone NAT is simply 1:1 IP:Port mapping between internal IP and external IP. Any half decent network engineer should know this. If they don't, they should go back to networking fundamentals in high school.

This is already provided in the Edge and BNG guide for ISPs here in the CGNAT section, which you can copy/paste to home user CPE device:
viewtopic.php?t=176358

In short, use netmap instead of src nat or masquerade as action. However, as of ROSv7.7 and latest Linux Kernels post Ubuntu 20.04, even src nat itself is doing the same 1:1 port mapping as netmap.

Port randomisation is the enemy of P2P via STUN. Cisco and Juniper made it popular, but it also exists in Linux codebase, it's a feature created by fools for fools.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 4:29 pm

I should note, these dumb terms were invented by Cisco, so that back in the early 2000s they could sell their firewall appliances where NAT is marketed as a security tool.

In the real world on Linux in 2023, these terms make no sense once you look into the actual source code and the function of the different types of translation methods.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 4:58 pm

Amen to that!
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 5:12 pm

The so what? Does this mean for consoles to work as expected (including voice), all one needs is.........???
- nothing Ros 7.7 fixes all issues
- upnp only
- port forwarding only
- something else on RoS
- some combo of the above
- throw console in garbage ( and gamers have to get a life )
 
holvoetn
Forum Guru
Forum Guru
Posts: 5326
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 5:57 pm

I vote 6...
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 6:06 pm

I should note, these dumb terms were invented by Cisco, so that back in the early 2000s they could sell their firewall appliances where NAT is marketed as a security tool.
Invented by cisco, right. But wasn't the marketing folks. cisco bought dozens of home routers as part of the work that went into development the STUN protocol, in the context of SIP standardization. Needing to classify the ways home router did NAT into a few simple categories, in circa 2000 – since many were problematic for SIP at the time. So the much discussed NAT modes in RFC3489 were used to describe the situations in which STUN protocol was designed to operate, that's it. It certainly wasn't an endorsement of them, rather a response to way NAT schemes that were already implemented.

The underlying problem being of how to get a SIP phone to ring, when path to a PBX went through some 1999-era home router. Even in ~2000, conntrack still had timeouts. And perhaps like some games, SIP (at its core) really wants to use its own port.

Most consumer stuff (and IP NVR too) latched on UPnP as an alternative to STUN. Mikrotik supports that. And imagine a lot Steam games, which got us here, use it & favored by Windows. Apple went with NAT-PMP route, which they invented. PCP seem to be the combined result in RFC chain.

BUT, today the only thing that's arguable here is if Mikrotik should support the newer Port Control Protocol (PCP) in the RFC-6887 as an update to UPnP. But I'm not sure how widely it's used...
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 6:33 pm

The so what? Does this mean for consoles to work as expected (including voice), all one needs is.........???
- nothing Ros 7.7 fixes all issues
- upnp only
- port forwarding only
- something else on RoS
- some combo of the above
- throw console in garbage ( and gamers have to get a life )
You don't need UPnP/Manual port forwarding. If you have at least a /32 IPv4 public IP, netmap the RFC1918 range to that IP. STUN will take care of the rest. For video calls, WebRTC+ICE will take care of it.

Since you're performing 1:1 IP:Port mapping using netmap, P2P traffic can work with STUN.

I stopped using UPnP/Port forwarding in home use years ago. Netmap makes the experience painless for gaming, VoIP etc.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 6:36 pm

I should note, these dumb terms were invented by Cisco, so that back in the early 2000s they could sell their firewall appliances where NAT is marketed as a security tool.
Invented by cisco, right. But wasn't the marketing folks. cisco bought dozens of home routers as part of the work that went into development the STUN protocol, in the context of SIP standardization. Needing to classify the ways home router did NAT into a few simple categories, in circa 2000 – since many were problematic for SIP at the time. So the much discussed NAT modes in RFC3489 were used to describe the situations in which STUN protocol was designed to operate, that's it. It certainly wasn't an endorsement of them, rather a response to way NAT schemes that were already implemented.

The underlying problem being of how to get a SIP phone to ring, when path to a PBX went through some 1999-era home router. Even in ~2000, conntrack still had timeouts. And perhaps like some games, SIP (at its core) really wants to use its own port.

Most consumer stuff (and IP NVR too) latched on UPnP as an alternative to STUN. Mikrotik supports that. And imagine a lot Steam games, which got us here, use it & favored by Windows. Apple went with NAT-PMP route, which they invented. PCP seem to be the combined result in RFC chain.

BUT, today the only thing that's arguable here is if Mikrotik should support the newer Port Control Protocol (PCP) in the RFC-6887 as an update to UPnP. But I'm not sure how widely it's used...
I’m aware of the history and well aware of PCP. But most Telcos and transits have moved to IPv6. Not even AT&T uses PCP. I worked with a few Telcos and none of them gave a damn about PCP.
I also do not like UPnP, but it's okay-ish for the average home user who's not into networking. Furthermore, I just netmap and call IPv4 a day, for both NAT44 and NAT444. 99% of my work and personal home network is IPv6, so I really stopped wasting my time on IPv4.

And yes, I'm a gamer too. Even CoD Warzone works fine with netmap at both NAT44 and NAT444. NAT Type moderate, sometimes open.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 6:49 pm

Full cone NAT is simply 1:1 IP:Port mapping between internal IP and external IP. Any half decent network engineer should know this. If they don't, they should go back to networking fundamentals in high school.
When I was in high school, networks weren't really a thing yet. And in the networks I maintain, NAT is normally not used except for the basic use in internet access.
I would never try to setup a system like the starter of this topic wants to have. I am not in gaming, and I consider the whole problem the responsibility of the end system developer, not of a magic router in between.

This whole discussion has deteriorated into name calling based on definitions of terms found in commercial manufacturer's documents. I am out of here!
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 6:53 pm

Not being console game demographic, it was this "NAT Type" classification that had me curious here.
And yes, I'm a gamer too. Even CoD Warzone works fine with netmap at both NAT44 and NAT444. NAT Type moderate, sometimes open.
Google was helpful. Stream's forums had an @anav-ish 'How to change NAT type to Open [Updated 2021]', quite the tale:
https://steamcommunity.com/sharedfiles/ ... =561836866

They had a chart of the "game console" NAT Types classifications, for those confused by the term "Moderate NAT" (like me)
Image
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 7:18 pm

DarkNate: I stopped using UPnP/Port forwarding in home use years ago. Netmap makes the experience painless for gaming, VoIP etc.

UPnP works great for gamers who don't know shit about networking, but as for the rest you should write a guide about using netmap and stun for Mikrotik gamers and maybe we can end the whole full cone nat discussion.

Regarding console NAT types, here is a brief translation of the table for all non gamers: ;-)
- OPEN = DMZ
- MODERATE = UPnP
- STRICT = CGNAT
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 8:12 pm

Open NAT = The IP:Port is accessible from the internet, same thing as hosting on port 80/443.
Moderate NAT = The IP:Port is not directly accessible via internet, but it is accessible via STUN binding for P2P/WebRTC/ICE
Strict NAT = The IP:Port is not accessible whatsoever, and you'll need to perform a TURN relay using a gamer who's behind OpenNAT or the game itself will connect to the third party TURN

Open NAT = lowest overhead on Layer 3-7
Moderate NAT = additional overhead on Layer 3-7 including SIP which now need STUN because idiots refuses to deploy IPv6
Strict NAT = Extreme overhead on L3 as traffic is routed via TURN meaning increased latency and even worse if the ISP is not peered with the ASN hosting that TURN relay. Everything about end-to-end principle goes out the window.

This type of in-depth network knowledge is often ignored even by CCIEs. I do not know why or how. It's like they never bothered to learn the Linux networking stack to understand this at low-level. Still stuck on Cisco/Juniper world, which both companies have migrated to Linux based and userland. Check JunOS Evolved.

STUN is deployed at app level source code, STUN is not user-interactive. Google Chrome is an example of an app that makes active STUN calls on launch, run a WireShark PCAP to see this in action.

At user level, use netmap and call it a day. If you can't do it correctly, get off the grid and move back to the cave you crawled out from:
/ip fi nat
add action=netmap chain=srcnat comment="netmap for egress" ipsec-policy=out,none out-interface-list=WAN src-address-list=lan_subnets to-addresses=1.1.1.1
1.1.1.1 here is example for public IP.
lan_subnets contains all your RFC1918 space.
If you have dynamic IP, then use scripting.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 8:31 pm

When I was in high school, networks weren't really a thing yet. And in the networks I maintain, NAT is normally not used except for the basic use in internet access.
I would never try to setup a system like the starter of this topic wants to have. I am not in gaming, and I consider the whole problem the responsibility of the end system developer, not of a magic router in between.

This whole discussion has deteriorated into name calling based on definitions of terms found in commercial manufacturer's documents. I am out of here!
Whoever you are in real life, I hope we do not meet at any networking event. I do not and cannot tolerate self-proclaimed network engineers, who can't even do high-school level NAT correctly and complying with the KISS principle in network engineering. I bet you probably still use MPLS in SP space. Unaware certain large-scale global Telcos dumped MPLS completely and migrated to Layer 3 up to the customer link termination—Hint: You will not find this information on Google or some cert book. This is real life.

It's not just a networking issue here, this problem is apparent in other fields of computer science, nobody learns the low-level facts, and information any more.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 10:12 pm

At user level, use netmap and call it a day. If you can't do it correctly, get off the grid and move back to the cave you crawled out from:

Haha, maybe not exactly what I had in mind but you're on the right track! :- ) I intended a reasonably useful guide for gamers so we can finish the discussing about full cone NAT. You obviously have the skills but maybe it's too easy or consumer-friendly for your taste??
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 10:44 pm

Haha, maybe not exactly what I had in mind but you're on the right track! :- ) I intended a reasonably useful guide for gamers so we can finish the discussing about full cone NAT. You obviously have the skills but maybe it's too easy or consumer-friendly for your taste??
I mean, I've shared the NAT rule example that would do netmap correctly. I use the same NAT rule in my home. P2P/Games/VoIP works fine, no need for UPnP/Manual port forwarding.

If they can't even do it after sharing the example, then really, they should get off the grid.
 
marekm
Member
Member
Posts: 379
Joined: Tue Feb 01, 2011 11:27 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 11:03 pm

Then why have you chosen MikroTik? There are dozens of brands of typical home routers that fit that bill perfectly.
Or is it a Wireless ISP where you give them e.g. LHG5 that function both as the link and the home router?
Dozens of brands of typical home routers - that's what my customers already have now. Each one with different bugs, most with no more firmware updates (one big advantage of MT is that even old hardware can still be upgraded to latest ROS), too risky to open for remote management, no or buggy IPv6 support, some (Phicomm) only support IPv4 but still break when IPv6 is enabled on my PPPoE servers. People sometimes ask me to support their various routers, so I plan to offer new pre-configured MT hAP ax-lite/2/3 rented as an additional paid service with remote management and full support, or "buy any home router, and configure it any way you want, but then you are on your own, don't ask me for support" as an alternative with no additional fees.
Yes I'm mostly a wireless ISP (some wired too but not much yet) using different 5/6/60 GHz radios, but they all transparently bridge PPPoE (one VLAN for PPPoE traffic another VLAN for management). Customers get an access port, and can use any PPPoE client to get a static public IPv4 /32, static IPv6 /64 + PD /56 will work soon (when the Phicomm issue is solved), RFC 4638 (MTU 1500) works where all hardware in between has enough L2 MTU.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 11:30 pm

[...]
At user level, use netmap and call it a day. If you can't do it correctly, get off the grid and move back to the cave you crawled out from:
/ip fi nat
add action=netmap chain=srcnat comment="netmap for egress" ipsec-policy=out,none out-interface-list=WAN src-address-list=lan_subnets to-addresses=1.1.1.1
1.1.1.1 here is example for public IP.
lan_subnets contains all your RFC1918 space.
If you have dynamic IP, then use scripting.
How is that example different vs using masquerade?
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 11:34 pm

How is that example different vs using masquerade?
Did you even read the official MikroTik docs and also Linux man page on what masquerade does? Do you not understand why it is different from modern src nat/netmap? No? Then keep using masquerade and don't expect P2P/VoIP to work correctly without TURN.

Not to mention, I already explained it here:
viewtopic.php?p=985222#p985174
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 11:46 pm

You don't have to be a douche all the time.
Netmap makes sense when you have multiple public IP's, but using netmap for a whole internal subnet to just one public IP? how does that work in real world?
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 11:48 pm

You don't have to be a douche all the time.
Netmap makes sense when you have multiple public IP's, but using netmap for a whole internal subnet to just one public IP? how does that work in real world?
I'm not getting paid to explain myself here. Either use netmap or don't. It's applicable to a /32 and also an entire /24 if you have one.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat Feb 18, 2023 11:51 pm

Sure you don't, nobody is. Yet we're not douches all the time in this forum.
So how is netmap taking care of your port forwards?
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 12:01 am

Sure you don't, nobody is. Yet we're not douches all the time in this forum.
So how is netmap taking care of your port forwards?
You don't port forward in the first place for apps such as VoIP/Gaming etc. Did you even read anything? Apparently not.

viewtopic.php?t=165060#p985174

This is my last reply on this thread. Have fun with masquerade or src nat action on older ROS versions.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 12:04 am

Indeed I'm not, and don't have any problems either.
But you've mentioned it replaces UPnP and manual port forwarding, just curious how that is done.
But sure, be a douche :p easier.
You've brought nothing usefull to this topic, nobody will miss your replies about how awesome a network engineer you are.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 12:35 am

/ip fi nat
add action=netmap chain=srcnat comment="netmap for egress" ipsec-policy=out,none out-interface-list=WAN src-address-list=lan_subnets to-addresses=1.1.1.1
1.1.1.1 here is example for public IP.
lan_subnets contains all your RFC1918 space.
If you have dynamic IP, then use scripting.
@DarkNate, It seems that you may have some misunderstandings about the use of network for gaming consoles at home. I guess you don't play gaming consoles, so you may not be familiar with it. It's not your fault.

Firstly, in the home scenario, netmap can only solve part of the problems of srcnat, which is what I said, just part of it.

The reason is simple. When you have a host that initiates a stun connection request to 1.2.3.4:3478, and the IP of the game console is 192.168.88.10 and the external network IP is 3.4.5.6, then using netmap, it will look like this in the firewall-connection:
src-address=192.168.88.10:12345 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:12345

At this time, your netmap has taken effect on srcnat, but if the second game console also initiates a stun connection request to 1.2.3.4:3478, and the IP of the game console is 192.168.88.20 and the external network IP is 3.4.5.6, according to the rules of netmap, it should be the following record:
src-address=192.168.88.20:12345 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:12345

However, 3.4.5.6:12345 has already been used by 192.168.88.10:12345, and another random port other than 12345 will be used, which depends on which idle ports are available in the NAT table.

If the local bound port for 192.168.88.10 and 192.168.88.20 accessing 1.2.3.4:3478 is random, there will be two connections with different src-ports,
but in fact, many games will bind to a fixed UDP port when initiating requests, and different games will have a different initial port, unless this port is already in use on the game console.

src-address=192.168.88.10:12345 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:12345
src-address=192.168.88.10:23456 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:23456

In this case, how can I set up the dstnat mapping?

As we know, netmap mapping cannot point to an IP address range. Although the code can be setup, the function is incorrect. When it is written as "to-address=192.168.88.0/24", the data will be mapped to 192.168.88.193.

Here is the code to set up the srcnat/dstnat mapping:
/ip firewall nat add action=netmap chain=srcnat out-interface-list=WAN src-address-list=LAN to-addresses=WAN
/ip firewall nat add action=netmap chain=dstnat dst-address=WAN in-interface-list=WAN to-addresses=192.168.88.0/24
address-list LAN=192.168.88.0/24
address-list WAN=3.4.5.6
NAT_type_Symmetric.png
this image shows Symmetric NAT even after using the netmap solution you suggested.
NAT_type_FullCone.png
this image shows Full Cone NAT that the port 50000-65535 being dstnat to the test PC.

The game console needs to show Full Cone NAT to be recognized as NAT1.

You can use the NATTypeTester to test this. I have uploaded the file as an attachment.
NatTypeTester.7z
If I have made any mistakes in my statement or code usage, please point them out and I will make corrections.
You do not have the required permissions to view the files attached to this post.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 1:21 am

@DarkNate, It seems that you may have some misunderstandings about the use of network for gaming consoles at home. I guess you don't play gaming consoles, so you may not be familiar with it. It's not your fault.

Firstly, in the home scenario, netmap can only solve part of the problems of srcnat, which is what I said, just part of it.

The reason is simple. When you have a host that initiates a stun connection request to 1.2.3.4:3478, and the IP of the game console is 192.168.88.10 and the external network IP is 3.4.5.6, then using netmap, it will look like this in the firewall-connection:
src-address=192.168.88.10:12345 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:12345

At this time, your netmap has taken effect on srcnat, but if the second game console also initiates a stun connection request to 1.2.3.4:3478, and the IP of the game console is 192.168.88.20 and the external network IP is 3.4.5.6, according to the rules of netmap, it should be the following record:
src-address=192.168.88.20:12345 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:12345

However, 3.4.5.6:12345 has already been used by 192.168.88.10:12345, and another random port other than 12345 will be used, which depends on which idle ports are available in the NAT table.

If the local bound port for 192.168.88.10 and 192.168.88.20 accessing 1.2.3.4:3478 is random, there will be two connections with different src-ports,
but in fact, many games will bind to a fixed UDP port when initiating requests, and different games will have a different initial port, unless this port is already in use on the game console.

src-address=192.168.88.10:12345 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:12345
src-address=192.168.88.10:23456 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:23456

In this case, how can I set up the dstnat mapping?

As we know, netmap mapping cannot point to an IP address range. Although the code can be setup, the function is incorrect. When it is written as "to-address=192.168.88.0/24", the data will be mapped to 192.168.88.193.

Here is the code to set up the srcnat/dstnat mapping:
/ip firewall nat add action=netmap chain=srcnat out-interface-list=WAN src-address-list=LAN to-addresses=WAN
/ip firewall nat add action=netmap chain=dstnat dst-address=WAN in-interface-list=WAN to-addresses=192.168.88.0/24
address-list LAN=192.168.88.0/24
address-list WAN=3.4.5.6

NAT_type_Symmetric.png
this image shows Symmetric NAT even after using the netmap solution you suggested.

NAT_type_FullCone.png
this image shows Full Cone NAT that the port 50000-65535 being dstnat to the test PC.

The game console needs to show Full Cone NAT to be recognized as NAT1.

You can use the NATTypeTester to test this. I have uploaded the file as an attachment.
NatTypeTester.7z

If I have made any mistakes in my statement or code usage, please point them out and I will make corrections.
I do not have any misunderstandings whatsoever. Of course netmap has limitations. That's why we have IPv6.

You are not completely wrong, but I propose you read this to understand why netmap + stun solves 98% of the problems. NAT Testers do not test for STUN reachability.
https://tailscale.com/blog/how-nat-traversal-works/
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 1:33 am

Of course netmap has limitations.
Since you know that netmap has limitations, I thought you didn't know.

So we need to use Fullcone NAT for regular users, instead of telling them to understand this and that,
as well as IPv6. They just need to know that enabling this will make gaming easier, and that there may be security risks.
It's similar to enabling uPNP with security risks.

This discussion is from the perspective of an ordinary user's home router.
it is pointless to discuss solutions that cannot solve the problem.
Bringing up Fullcone NAT is to solve the problems of home users, and most home routers now support this feature.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 1:38 am

As someone said, you are just a network engineer who is here to show off your skills.
The key is that you know netmap has limitations, yet you keep touting how good it is here.

In fact, what you said is not able to solve the problem mentioned here.
What we need is a solution to the problem, not you showing off your skills.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 1:47 am

Since you know that netmap has limitations, I thought you didn't know.

So we need to use Fullcone NAT for regular users, instead of telling them to understand this and that,
as well as IPv6. They just need to know that enabling this will make gaming easier, and that there may be security risks.
It's similar to enabling uPNP with security risks.

This discussion is from the perspective of an ordinary user's home router.
it is pointless to discuss solutions that cannot solve the problem.
Bringing up Fullcone NAT is to solve the problems of home users, and most home routers now support this feature.
So called "Full cone NAT" ain't going to happen on MikroTik. Either use my method and ensure your firewall doesn't block STUN, or keep praying for Full cone NAT.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 2:06 am

Without enabling firewall, using netmap as you suggested, it is unable to display Fullcone NAT in NatTypeTester.
You can test it yourself, I have uploaded the NatTypeTester software.
I think the reason is that the PC is accessing port 3478, but the returned data source is from a random port between 3479 and 3481.
Perhaps this is causing the netmap you mentioned not to work, as the source port during online gaming on the game host can be any port that you haven't accessed before.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 2:17 am

If what you said is feasible, then netmap can replace Fullcone NAT.

Don't just stay on the verbal argument, provide the complete and correct code you mentioned, so that everyone can confirm it or you can test it yourself using NatTypeTester.

I have tested the method you mentioned and the result is that netmap cannot achieve Fullcone NAT. And I ruled out the possible firewall issue that you mentioned.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 2:43 am

Without enabling firewall, using netmap as you suggested, it is unable to display Fullcone NAT in NatTypeTester.
You can test it yourself, I have uploaded the NatTypeTester software.
I think the reason is that the PC is accessing port 3478, but the returned data source is from a random port between 3479 and 3481.
Perhaps this is causing the netmap you mentioned not to work, as the source port during online gaming on the game host can be any port that you haven't accessed before.
I already explained it before:
NAT Testers do not test for STUN reachability.
And here someone explained it in full details:
https://tailscale.com/blog/how-nat-traversal-works/

It seems you're just an end user playing network engineer.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 3:49 am

You are wrong. I have never pretended to be a network engineer like you and showed off my skills.
I am just an ordinary user and not a network engineer.

I am just a player who encountered an issue while using a game console and proposed a functional requirement.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 4:04 am

NAT Testers do not test for STUN reachability.
So, on PS5/XBOX, you cannot connect with other P2P online players as a NAT1 user,
because the PS5/XBOX detects that you are not a NAT1 user.
Of course, you can try contacting Sony or Microsoft with a URL and ask them why it's not working.

Therefore, game console players still need Fullcone NAT.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 4:09 am

So, on PS5/XBOX, you cannot connect with other P2P online players as a NAT1 user,
because the PS5/XBOX detects that you are not a NAT1 user.
Of course, you can try contacting Sony or Microsoft with a URL and ask them why it's not working.

Therefore, game console players still need Fullcone NAT.
No clue what you're talking about. I have an Xbox + PC Gaming Pass for Xbox games. All of them work fine with my config. I verified using WireShark PCAP to ensure P2P between myself and the other player is properly working. I can see My IP:Port connected to Their IP:Port.

Good luck with "Full cone" whatever.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 6:09 am

Using this tool:
https://github.com/HMBSbige/NatTypeTest ... /tag/6.2.0

1. I enabled src nat netmap rule for my public /32 to my private /24
/ip fi nat
add action=netmap chain=srcnat comment="netmap for egress" ipsec-policy=out,none out-interface-list=WAN src-address=100.64.0.0/24 to-addresses=1.1.1.1
2. Firewall is disabled on router completely
3. Firewall is disabled on Windows 11 machine completely

Here's the end result:
Image

The lesson here is, leave network engineering to network engineers and as a home user/end user/normal user, shove your ego up somewhere in your orifices and learn from network engineers, who takes high school fundamentals very seriously.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 9:43 am

Yo, high school fundamentals.
You just did a 1:1 NAT, of course it works. We know that, it was explained above.
You're not doing rocket science.
But what happens when you have more than one machine active in your LAN? or more gamers/consoles/PCs? And your "netmap" has to deal with more than just one internal IP? hm?
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 2:44 pm

You cannot share a single public IP:port with two internal hosts you idiot. If you have two Xboxes, you use a separate port for each.
https://portforward.com/portforward-two-xboxes/
Xbox has allowed the use of port 3074 (UDP and TCP) only. However, if you have another Xbox console you cannot forward that same port to the second console. A port only allows one set of data to pass through at a time. This works great for the primary Xbox but the secondary Xbox will lag and have trouble playing an online game in general.

To solve this problem Activision has made it so you can port your second Xbox to 3075 (UDP and TCP). If you have a third console go ahead and port 3076 (UDP and TCP) to that one.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sun Feb 19, 2023 2:50 pm

We can already use that without switching to netmap.
So, what are you screaming about in here?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Mon Feb 20, 2023 11:38 am

The reason is simple. When you have a host that initiates a stun connection request to 1.2.3.4:3478, and the IP of the game console is 192.168.88.10 and the external network IP is 3.4.5.6, then using netmap, it will look like this in the firewall-connection:
src-address=192.168.88.10:12345 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:12345

At this time, your netmap has taken effect on srcnat, but if the second game console also initiates a stun connection request to 1.2.3.4:3478, and the IP of the game console is 192.168.88.20 and the external network IP is 3.4.5.6, according to the rules of netmap, it should be the following record:
src-address=192.168.88.20:12345 dst-address=1.2.3.4:3478 reply-dst-addres=3.4.5.6:12345
That is what I have asked previously where is the magic?
If both consoles are using the same source port and the same dst-address with the same dst port, then, when 1.2.3.4:3478 sends packet to 3.4.5.6:12345 what magic should happen for router to guess which one of
192.168.88.x:1234 is the real recipient? I also do not see how here mentioned "full-cone" interpretation will help in this scenario. This could wotk if consoles encode internal IP in the data, in that case NAT helper is needed that looks deeper and decodes internal IP from the packet data. Full cone quad cone or any other nat shape cannot solve this problem when working just with layer3/layer4 data.
 
marekm
Member
Member
Posts: 379
Joined: Tue Feb 01, 2011 11:27 pm

Re: FEATURE REQUEST: full cone NAT

Mon Feb 20, 2023 2:36 pm

Both consoles use the same internal source port but with full-cone NAT it is mapped to different port numbers on the single public IP:
192.168.88.10:12345 <-> 3.4.5.6:12345
192.168.88.20:12345 <-> 3.4.5.6:12346

If the same internal port number can't be used externally (because it's already used by some other NAT mapping, some service on the router itself, or is not in the allowed range) then a new port number is chosen from the allowed range. This way any number of game consoles (or IP phones, or...) behind one public IP can communicate with their respective servers, which can tell their other clients which IP:port to talk to without any additional configuration. No magic really.

The way NAT currently works is different, as an example these are the connection table entries (public IPs obfuscated, timeouts deliberately made longer to see them all at once before they disappear) created by an NTPsec process on internal host (acting as both client and server on UDP port 123) talking to a few public NTP servers:
> ip firewall connection print detail where src-address~"192.168.1.139"
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat 
 0  SAC Fs  protocol=udp src-address=192.168.1.139:123 dst-address=162.xxx.xxx.123:123 reply-src-address=162.xxx.xxx.123:123 reply-dst-address=91.xxx.xxx.37:123 timeout=1m25s orig-packets=77 286 orig-bytes=5 873 736 orig-fasttrack-packets=0 
            orig-fasttrack-bytes=0 repl-packets=77 072 repl-bytes=5 857 472 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 

 1  SAC Fs  protocol=udp src-address=192.168.1.139:123 dst-address=91.xxx.xxx.77:123 reply-src-address=91.xxx.xxx.77:123 reply-dst-address=91.xxx.xxx.37:123 timeout=2m46s orig-packets=126 313 orig-bytes=9 599 788 orig-fasttrack-packets=0 
            orig-fasttrack-bytes=0 repl-packets=126 160 repl-bytes=9 588 160 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 

 2  SAC Fs  protocol=udp src-address=192.168.1.139:123 dst-address=195.xxx.xxx.22:123 reply-src-address=195.xxx.xxx.22:123 reply-dst-address=91.xxx.xxx.37:123 timeout=2m orig-packets=10 orig-bytes=760 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 
            repl-packets=10 repl-bytes=760 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 

 3  SAC Fs  protocol=udp src-address=192.168.1.139:123 dst-address=178.xxx.xxx.24:123 reply-src-address=178.xxx.xxx.24:123 reply-dst-address=91.xxx.xxx.37:123 timeout=1m55s orig-packets=19 orig-bytes=1 444 orig-fasttrack-packets=0 
            orig-fasttrack-bytes=0 repl-packets=19 repl-bytes=1 444 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 

 4  SAC Fs  protocol=udp src-address=192.168.1.139:123 dst-address=193.xxx.xxx.136:123 reply-src-address=193.xxx.xxx.136:123 reply-dst-address=91.xxx.xxx.37:123 timeout=2m12s orig-packets=8 orig-bytes=608 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 
            repl-packets=8 repl-bytes=608 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 

 5  SAC Fs  protocol=udp src-address=192.168.1.139:123 dst-address=193.xxx.xxx.182:123 reply-src-address=193.xxx.xxx.182:123 reply-dst-address=91.xxx.xxx.37:123 timeout=2m12s orig-packets=14 orig-bytes=1 064 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 
            repl-packets=14 repl-bytes=1 064 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 
and with Full-cone NAT these whould all become just one entry: src-address=192.168.1.139:123 dst-address=ANY reply-src-address=ANY reply-dst-address=91.xxx.xxx.37:123 with the side effect that any traffic from outside (not just replies from the servers) to port 123 would reach the internal host. Then of course some filtering rules need to be configured (on the router or in NTPsec itself) to restrict if that is too wide open (not a public NTP server), or port range restricted to high numbers like 49152-65535.

With this port number restriction (which is safer, avoids exposing well known service ports) the two mappings from the top of this message would be:
192.168.88.10:12345 <-> 3.4.5.6:49152
192.168.88.20:12345 <-> 3.4.5.6:49153
(or some other random ports from the allowed range) but p2p communication would still work as long as the game server (or IP PBX) tell its other clients (or IP phones) on which IP:port to communicate directly with each other, this would reduce traffic on the servers to just exchange information about IP/ports but not relay any media like video calls.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Mon Feb 20, 2023 3:56 pm

That is what I have asked previously where is the magic?
If both consoles are using the same source port and the same dst-address with the same dst port, then, when 1.2.3.4:3478 sends packet to 3.4.5.6:12345 what magic should happen for router to guess which one of
192.168.88.x:1234 is the real recipient? I also do not see how here mentioned "full-cone" interpretation will help in this scenario. This could wotk if consoles encode internal IP in the data, in that case NAT helper is needed that looks deeper and decodes internal IP from the packet data. Full cone quad cone or any other nat shape cannot solve this problem when working just with layer3/layer4 data.
Full-Cone NAT already works in vanilla Linux and RouterOS using netmap partially, but it is good enough to work with STUN binding.

What the OP and RFC means is this:
Full-Cone NAT on L3/L4 basis:
192.168.0.2:123 > netmapped to 1.1.1.1:123 for dst 8.8.8.8:3333
192.168.0.2:123 > netmapped to 1.1.1.1:123 for dst 4.4.4.4:6666

Now, port 123 is opened on public IP 1:1:1:1 for ANY external host at kernel level. So Even 9.9.9.9:1234 can now talk to 1.1.1.1:123 without any dst-nat rule (UPnP, manual, PCP).
However, on vanilla Linux this particular piece “ANY” doesn't work without UPnP/PCP or manual dst-nat config. On Cisco IOS-XR, “ANY” works without any "dst-nat" rule.

So basically, once a port is mapped towards a host as example above, that port is OPENED completely to the public internet without UPnP/PCP/Manual dst-nat config, so hence "Full Cone NAT" instead of "Open NAT" is achieved. "Open NAT" is UPnP/PCP/Manual dst-nat forwarding rule which is best avoided for average user.

Another example:
Xbox1:
192.168.0.2:123 > netmapped to 1.1.1.1:123 for dst 8.8.8.8:3333
192.168.0.2:123 > netmapped to 1.1.1.1:123 for dst 8.8.8.8:6666

Xbox2:
192.168.0.3:124 > netmapped to 1.1.1.1:124 for dst 8.8.8.8:3333
192.168.0.3:124 > netmapped to 1.1.1.1:124 for dst 8.8.8.8:6666

If Xbox 3 is using the same port then use either pseudorandom, random or deterministic algorithm to map like this:
192.168.0.4:124 > netmapped to 1.1.1.1:125 for dst 8.8.8.8:3333
192.168.0.4:124 > netmapped to 1.1.1.1:125 for dst 8.8.8.8:6666

No magic bullcrap helper is required for Layer 5-7 (ALG). Just plain code to open up a mapped port on L3/L4.

Although, personally, I do not use this feature which Cisco IOS-XR offers natively, if MikroTik implements this, it will be benefit:
1. Push the patch for Linux kernel upstream
2. Help MikroTik ISP customers who are using MikroTik as CGNAT to overcome complaints from customers
3. More or less the best simplest option without UPnP/PCP crap.
 
marekm
Member
Member
Posts: 379
Joined: Tue Feb 01, 2011 11:27 pm

Re: FEATURE REQUEST: full cone NAT

Mon Feb 20, 2023 8:32 pm

Just checked RouterOS does exactly that. nc -p 12345 1.1.1.1 11111 and nc -p 12345 2.2.2.2 21111
[test@MikroTik] /ip firewall connection> print detail interval=2 where dst-address="1.1.1.1:11111" || dst-address="2.2.2.2:21111"
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
1 C s protocol=tcp src-address=192.168.88.115:12345 dst-address=1.1.1.1:11111 reply-src-address=1.1.1.1:11111
reply-dst-address=x.x.x.x:12345 tcp-state=syn-sent timeout=0s orig-packets=3 orig-bytes=192 orig-fasttrack-packets=0
orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

2 C s protocol=tcp src-address=192.168.88.115:12345 dst-address=2.2.2.2:21111 reply-src-address=2.2.2.2:21111
reply-dst-address=x.x.x.x:12345 tcp-state=syn-sent timeout=3s orig-packets=2 orig-bytes=128 orig-fasttrack-packets=0
orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps

as you can see RouterOS also maps to the same inside global ip and port for all streams.


as for huawei they just try to clasify their existing nat methods based on rfc3489 description and basically shows in examples static nat, the same as mentioned before in this topic.

So none of those docs provide any actual answer what is the problem.
In short, the above is Endpoint-Independent-Mapping, but what is also needed is Endpoint-Independent-Filtering. This and other NAT requirements / best practices are well explained in RFC 4787 / BCP 127 (updated by a few newer RFCs, but not obsoleted).
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 12:15 pm

That is what I have asked previously where is the magic?
If both consoles are using the same source port and the same dst-address with the same dst port, then, when 1.2.3.4:3478 sends packet to 3.4.5.6:12345 what magic should happen for router to guess which one of
192.168.88.x:1234 is the real recipient? I also do not see how here mentioned "full-cone" interpretation will help in this scenario. This could wotk if consoles encode internal IP in the data, in that case NAT helper is needed that looks deeper and decodes internal IP from the packet data. Full cone quad cone or any other nat shape cannot solve this problem when working just with layer3/layer4 data.
Full-Cone NAT already works in vanilla Linux and RouterOS using netmap partially, but it is good enough to work with STUN binding.

What the OP and RFC means is this:
Full-Cone NAT on L3/L4 basis:
192.168.0.2:123 > netmapped to 1.1.1.1:123 for dst 8.8.8.8:3333
192.168.0.2:123 > netmapped to 1.1.1.1:123 for dst 4.4.4.4:6666

Now, port 123 is opened on public IP 1:1:1:1 for ANY external host at kernel level. So Even 9.9.9.9:1234 can now talk to 1.1.1.1:123 without any dst-nat rule (UPnP, manual, PCP).
However, on vanilla Linux this particular piece “ANY” doesn't work without UPnP/PCP or manual dst-nat config. On Cisco IOS-XR, “ANY” works without any "dst-nat" rule.

So basically, once a port is mapped towards a host as example above, that port is OPENED completely to the public internet without UPnP/PCP/Manual dst-nat config, so hence "Full Cone NAT" instead of "Open NAT" is achieved. "Open NAT" is UPnP/PCP/Manual dst-nat forwarding rule which is best avoided for average user.

Another example:
Xbox1:
192.168.0.2:123 > netmapped to 1.1.1.1:123 for dst 8.8.8.8:3333
192.168.0.2:123 > netmapped to 1.1.1.1:123 for dst 8.8.8.8:6666

Xbox2:
192.168.0.3:124 > netmapped to 1.1.1.1:124 for dst 8.8.8.8:3333
192.168.0.3:124 > netmapped to 1.1.1.1:124 for dst 8.8.8.8:6666

If Xbox 3 is using the same port then use either pseudorandom, random or deterministic algorithm to map like this:
192.168.0.4:124 > netmapped to 1.1.1.1:125 for dst 8.8.8.8:3333
192.168.0.4:124 > netmapped to 1.1.1.1:125 for dst 8.8.8.8:6666

No magic bullcrap helper is required for Layer 5-7 (ALG). Just plain code to open up a mapped port on L3/L4.

Although, personally, I do not use this feature which Cisco IOS-XR offers natively, if MikroTik implements this, it will be benefit:
1. Push the patch for Linux kernel upstream
2. Help MikroTik ISP customers who are using MikroTik as CGNAT to overcome complaints from customers
3. More or less the best simplest option without UPnP/PCP crap.
Yes, this makes sense if mapped to different public ports and remote devices receive which port to use via the game server.
We will try to add this feature, however, I cannot promise any timeframe.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 5:41 pm

Thanks MRZ!!!
So its.

a. ADD zerotrust cloudflare tunnel options package for all devices, then
b. ADD gaming NAT to RoS.
:-)
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 6:21 pm

You are killing me, I almost died laughing....hahahahahaha. MT, please give in to our cuddy and add the follwing for all devices
.
a. BGP fast failover (BFD)
b. Other necessary fixes for v6 -> v7 parity
...
x. ZeroTier One Client, it's just 4-5 megs, ie drop the Controller to a separate pkg..
y. Zerotrust cloudflare tunnel
z. Gaming NAT to RoS.
😘
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 6:44 pm

You are killing me, I almost died laughing....hahahahahaha. MT, please give in to our cuddy and add the follwing for all devices

STUFF THAT HAS TO GET FIXED CAUSE ITS BROKEN ( maintain functionality )
a. BGP fast failover (BFD)
b. Other necessary fixes for v6 -> v7 parity
...
CAPABILITIES NOT YET REALIZED ( add functionality )
x. ZeroTier One Client, it's just 4-5 megs, ie drop the Controller to a separate pkg..
y. Zerotrust cloudflare tunnel
z. Gaming NAT to RoS.
😘
Almost is not good enough ;-)
 
marekm
Member
Member
Posts: 379
Joined: Tue Feb 01, 2011 11:27 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 8:16 pm

Improving NAT is important not just for gaming. RFC 4787 + later updates are called Best Current Practice for good reasons, based on a lot of experience gained with existing NAT implementations (older than the RFCs - Linux iptables NAT hasn't changed much since early 2000s). Too many things depend on central cloud servers these days, because too many restrictive NAT devices break peer-to-peer connections - it doesn't have to be that way.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 9:46 pm

Yes, this makes sense if mapped to different public ports and remote devices receive which port to use via the game server.
We will try to add this feature, however, I cannot promise any timeframe.
I should emphasised this is not just for “gaming”, this applies to Video calls/Voice Calls over IP, BitTorrent etc. And again, please note the “ANY” and “OPENED completely” factor at code level for L3/L4. It should ensure that once a private IP:Port is mapped to Public:IP, that port is:
1. Consistent for all dst
2. That port is now EXPOSED globally, so even a third party IP:Port that does not exist in the conn_track table in the state established, related, can initiate a fresh P2P connection to that Public:IP port.
3. ZERO dst-nat rules should be required for this work (no UPnP/PCP/manual rules).
4. Verify your future code with Cisco IOS-XR behaviour as their implementation is cleanly RFC compliant. No need for "dst-nat" rules/mapping.
5. Basically, you're modifying the state-machine code in netfilter, which is kinda cool to be honest.

For the time being, the end-users who are not network engineers can follow my simple netmap method to achieve Full Cone-like behaviour in combination with STUN (which happens on your Xbox or application natively). You can still play P2P games, but it won't be as perfect or smooth as Cisco IOX-XR Full Cone NAT for now.
Highly recommend not to listen to idiots playing network engineers like @Znevna or anyone that refuses to learn high-school basic Linux networking fundamentals.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 9:48 pm

You are killing me, I almost died laughing....hahahahahaha. MT, please give in to our cuddy and add the follwing for all devices
.
a. BGP fast failover (BFD)
b. Other necessary fixes for v6 -> v7 parity
...
x. ZeroTier One Client, it's just 4-5 megs, ie drop the Controller to a separate pkg..
y. Zerotrust cloudflare tunnel
z. Gaming NAT to RoS.
😘
BFD is nice, but watch this video, they explain that just because they add a new feature, it doesn't mean, they stop working on BFD or whatever:
https://www.youtube.com/watch?v=vAF7NII9Qcg

Also, you can use OSPF for underlay, learn loopbacks, then configure BGP on loopback to loopback basis. If a link fails, OSPF auto-detects and removes that route/next-hop in a few nanoseconds.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 9:56 pm

Improving NAT is important not just for gaming. RFC 4787 + later updates are called Best Current Practice for good reasons, based on a lot of experience gained with existing NAT implementations (older than the RFCs - Linux iptables NAT hasn't changed much since early 2000s). Too many things depend on central cloud servers these days, because too many restrictive NAT devices break peer-to-peer connections - it doesn't have to be that way.
If you're using Ubuntu 20.04 onwards or modern day Debian, you should be okay. Replace src nat as jump to netmap. Similiar to ROS. It's not perfectly RFC compliant like Cisco IOS-XR, but it is 95% there.

This way, TURN is avoided 100%, STUN binding will ensure P2P NAT punching can work.

Avoid masquerade like covid, it defaults to port randomisation behaviour.

Bottom line, high school network fundamentals pays off in your career and personal home lab :)
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 10:14 pm

BFD is nice, but watch this video, they explain that just because they add a new feature, it doesn't mean, they stop working on BFD or whatever:
https://www.youtube.com/watch?v=vAF7NII9Qcg
Maybe the war is over?

Image

[ Janas from MTU video above, did a presentation on the evils of masquerade a while back, so above from https://youtu.be/D80_a_O86jc?t=20 ]
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Tue Feb 21, 2023 10:22 pm

LIKED: "Avoid masquerade like covid"
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 11:16 am

Highly recommend not to listen to idiots playing network engineers like @Znevna or anyone that refuses to learn high-school basic Linux networking fundamentals.
Ok, few things:
You seem to be the self-proclaimed network engineer / expert number I've stopped counting in this forum. And on top of that you're a top class prick.
Also I wonder why masquerade just works for almost everyone and we're not idiots for using it?
Also the ones that sell/offer routers, appliances and software solutions with masquerade as a default option where NAT is involved, I'm sure that they are not idiots either.
And you can't be the only expert network engineer that thought of using netmap instead, but yet masquerade is almost everywhere and it's fine.
Last edited by Znevna on Wed Feb 22, 2023 5:08 pm, edited 3 times in total.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 5:02 pm

@DarkNate: Highly recommend not to listen to idiots playing network engineers...

Hmm...

Well, as much as I love your sweet talk and diplomatic rhetoric, I unfortunately have to disappoint you in several ways:

As I stated earlier UPnP works fine for the vast majority of consumers (+>99.95%) but as always there are some few exceptions. IMO, it's better to shape up the security around UPnP rather than fixing some kind of static and special tailored NAT-mode. As for the rest, you can keep playing with available RoS features as long as you enjoy it and fix your problems.

However, if (and that's a big if) someone at MT actually is thinking about some kind of new NAT module, my advice is to make it configurable targeting e.g LSN or other special purposes like crippled games and gaming consoles.

As for the BGP workaround, it's a nice solution but for various reasons it's not practically feasible as an add-in replacement, hence the need for BFD.

Regarding NAT/Masquerade it's old news so what's your point? You don't seem to realize that this is the reality for most consumers at home using dynamic IP addresses, regardless of your views on this.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 6:53 pm

Hmm...

Well, as much as I love your sweet talk and diplomatic rhetoric, I unfortunately have to disappoint you in several ways:

As I stated earlier UPnP works fine for the vast majority of consumers (+>99.95%) but as always there are some few exceptions. IMO, it's better to shape up the security around UPnP rather than fixing some kind of static and special tailored NAT-mode. As for the rest, you can keep playing with available RoS features as long as you enjoy it and fix your problems.

However, if (and that's a big if) someone at MT actually is thinking about some kind of new NAT module, my advice is to make it configurable targeting e.g LSN or other special purposes like crippled games and gaming consoles.

As for the BGP workaround, it's a nice solution but for various reasons it's not practically feasible as an add-in replacement, hence the need for BFD.

Regarding NAT/Masquerade it's old news so what's your point? You don't seem to realize that this is the reality for most consumers at home using dynamic IP addresses, regardless of your views on this.
That doesn't change the fact that full-cone is BCP as of current. Unless you wrote a new RFC/BCP to say otherwise? Any links? UPnP is a security hole, and we should just avoid it altogether in 2023. Not to mention Cisco IOS-XR supports full-cone NAT since forever. Juniper supports it since 2010 or so: https://www.juniper.net/documentation/s ... guring.pdf

They don't need anything more advanced than full cone. Deterministic NAT is garbage and limits number of ports per customer.

Running OSPF (or ideally ISIS) as underlay is not a work-around, it is one of the modern approaches to an all BGP network, where we combine iBGP for adjacent and eBGP for vertical relationships on the overlay.
https://datatracker.ietf.org/doc/rfc7938/

Guess who uses this method? Meta/Facebook is one of them and I knew even smaller companies using this model and it scales well. Of course we use BFD, but its not a requirement for fast failover.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 7:30 pm

Fact: UPnP is the recommended and currently most used solution for gaming consoles at home, whether you like it or not. If you want a change, talk to the manufacturers or do you own thing.

Thanks for the clarification regarding "NAT" but that is beside the point. Why bother doing a limited implementation when the actual core module offers a plethora of new features. It's a waste of time and money IMO.

Regarding BCP, you don't seem to have a clue of how to manage compatibility in a large existing install base.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 7:33 pm

Now I know how an ant feels trying to avoid being trampled by the squabbling rhinoceros and hippopotamus! ;-)

(interesting side note: A 2009 study in the journal Brain, Behavior and Evolution (opens in new tab) found that an especially tiny genus of ant has the largest brain for its body size. Brachymyrmex has an average body mass of up to 0.049 milligrams and an average brain mass of 0.006 milligram. That means its brain is roughly 12% of its body mass, giving it a brain-to-body-mass ratio of about 1:8. A hippo 1:28 )
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 7:53 pm

Fact: UPnP is the recommended and currently most used solution for gaming consoles at home, whether you like it or not. If you want a change, talk to the manufacturers or do you own thing.

Thanks for the clarification regarding "NAT" but that is beside the point. Why bother doing a limited implementation when the actual core module offers a plethora of new features. It's a waste of time and money IMO.

Regarding BCP, you don't seem to have a clue of how to manage compatibility in a large existing install base.
Lol, good luck with UPnP and have fun.

OEMs like Asus supports full cone NAT. Cisco, Juniper supports it. Even OpenWRT supports it as already explained by other home users here who know better than you do.
MikroTik just agreed to add full cone support in the future.

I don't need full cone, netmap works sufficiently enough for me. It is for other people who needs it.

Regarding BCP? Do you mean BFD? No clue what you're talking about, I've migrated large sites from ancient iBGP full mesh and confederation to OSPF/ISIS underlay with iBGP + eBGP overlay with no problems. Sounds like you're just incompetent. I wouldn't hire you to fix my network or implement "BCP" or "BFD".
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 8:11 pm

Maybe the war is over?

Image

[ Janas from MTU video above, did a presentation on the evils of masquerade a while back, so above from https://youtu.be/D80_a_O86jc?t=20 ]
Unfortunately the war is not over. Because very few experts as those in this thread are vendor-agnostic, most of them have their network engineering skills foundation based on vendor ABC, can be Cisco, Juniper, Arista, or yes even MikroTik.

Vendor-agnostic network engineers who can see the depths of the various options, protocols, and parameters available and use those correctly to ensure a packet goes from A to B with minimal impact to QoS/QoE and P2P (in the case of NAT) are rare and usually limited to Linux networking-heavy folks, which is an even rarer subset of competent network engineers.

Fundamentally, computer network is a branch of computer science, but most experts lack computer knowledge, very few “network engineers” even have a degree in computer science or similar. Try asking them what's sk_buff and why both NATting and packet filtering should occur before sk_buff.

I'm no self-proclaimed expert, never said that any this forum ever. But I work with people who have 30+ years of well decorated careers in network engineering, and they can also be found on Wikipedia (no cap), and they certainly don't act like the experts in this thread and can easily answer what's sk_buff.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 8:25 pm

NAT wars are vendor-agnostic.

This seems to be a win here, no?

Although, personally, I do not use this feature which Cisco IOS-XR offers natively, if MikroTik implements this, it will be benefit:
1. Push the patch for Linux kernel upstream
2. Help MikroTik ISP customers who are using MikroTik as CGNAT to overcome complaints from customers
3. More or less the best simplest option without UPnP/PCP crap.

Yes, this makes sense if mapped to different public ports and remote devices receive which port to use via the game server.
We will try to add this feature, however, I cannot promise any timeframe.
or at least a battle won...
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 8:40 pm

NAT wars are vendor-agnostic.

This seems to be a win here, no?
or at least a battle won...
Well I agree. Though I was speaking more generally. You can find a lot of misinformation on this forum or similar forums all over the internet. Nobody reads 2023 networking fundamental books and assume everything from 1980 is still relevant today like classful addressing for example. Like look at the state of IRR lol, what a joke, a /24 defined in 100 DBs. Good luck with RPKI.

Regardless, I like that MikroTik mostly, doesn't implement dumb features like mDNS repeater or crappy NAT logic like that Russian BisonRouter product.

But MikroTik needs to dump iptables and allow nftables for newbies and expose XDP at ASIC/hardware level for advanced users.
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1025
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 8:50 pm

@DarkNet, you missed my point for the third time and seem to focus more on your own thoughts instead of responding with a focus on the arguments. You are also changing direction of the conversation with new and irrelevant facts (whataboutism) but never mind.

As for "your migration", you've convinced me even more that you have absolutely no idea or experience for that matter on how to deal with a large install base (since are probably a skilled hobbyist).
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 8:55 pm

@DarkNet, you missed my point for the third time and seem to focus more on your own thoughts instead of responding with a focus on the arguments. You are also changing direction of the conversation with new and irrelevant facts (whataboutism) but never mind.

As for "your migration", you've convinced me even more that you have absolutely no idea or experience for that matter on how to deal with a large install base (since are probably a skilled hobbyist).
I have no idea what you're on about. Good luck with BisonRouter or whatever you use internally. I'm out of here.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 22, 2023 9:26 pm

[...] Even OpenWRT supports it as already explained by other home users here who know better than you do.
For OpenWrt to see something like this it would mean that it has to exist in upstream netfilter (iptables in OpenWrt < 22.03 or nftables in OpenWrt ≥ 22.03), and there's no such thing.
So no, from that list, OpenWrt for sure doesn't have something called 'Full Cone Nat' or 'Tetrahedron NAT' or 'DarkNATe BCP as of 2023 because I exchange letters with a bunch of experts but I'm no expert but you're all idiots if you don't agree with me'.
I'm out of here.
Bye.
 
marekm
Member
Member
Posts: 379
Joined: Tue Feb 01, 2011 11:27 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 24, 2023 5:19 pm

Please, let's not turn this discussion into a flame war about 50 shapes of NAT.
It would be good to review the NAT implementation for compliance with RFCs listed under https://www.rfc-editor.org/info/bcp127 .
BCP stands for Best Current Practices. BCP 127 is mainly about UDP, see also:
BCP 142, RFC 5382, NAT Behavioral Requirements for TCP, October 2008
BCP 148, RFC 5508, NAT Behavioral Requirements for ICMP, April 2009
 
User avatar
Archous
just joined
Posts: 10
Joined: Thu May 12, 2022 7:13 am
Location: USA
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Apr 13, 2023 3:09 am

Hate to necro post (~1 month old not that bad) but I can clarify the need for full cone /endpoint independent NAT and connection tracking. It has to do with NAT traversal techniques and the ability to open a port up by generating an outbound connection and re-use that IP:port mapping from any other host. It works very closely with STUN techniques. Essentially the desired behavior is that a host behind a NAT router (MikroTik) opens a connection to the Internet to a server (STUN?) and that public IP:port mapping is recorded and then communicated to other hosts on other LANs behind other NAT routers to communicate to this host. Essentially allowing NAT traversal and direct TCP/UDP connectivity host to host.

As an implementor ourselves working at the kernel level on other products we have built a well-defined request to Mikrotik in July 2020 via request SUP-20798 which was abandoned and then closed without our acknowledgement. I strongly recommend folks who want this feature reach out to MikroTik and reference SUP-20798 if they care about this feature.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Thu Apr 13, 2023 8:57 am

[...] Essentially the desired behavior is that a host behind a NAT router (MikroTik) opens a connection to the Internet to a server (STUN?) and that public IP:port mapping is recorded and then communicated to other hosts on other LANs behind other NAT routers to communicate to this host. Essentially allowing NAT traversal and direct TCP/UDP connectivity host to host.

As an implementor ourselves working at the kernel level on other products we have built a well-defined request to Mikrotik in July 2020 [...] I strongly recommend folks who want this feature reach out to MikroTik and reference SUP-20798 if they care about this feature.
Um, no? Or at least that's not the behaviour described/wanted in this topic, the bold part in specific.
And without knowing what SUP-20798 contains, nobody will reference it.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Apr 13, 2023 8:59 am

endpoint independent mapping will be available in 7.10beta version when its released.
 
User avatar
Archous
just joined
Posts: 10
Joined: Thu May 12, 2022 7:13 am
Location: USA
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Apr 13, 2023 12:53 pm

[...] Essentially the desired behavior is that a host behind a NAT router (MikroTik) opens a connection to the Internet to a server (STUN?) and that public IP:port mapping is recorded and then communicated to other hosts on other LANs behind other NAT routers to communicate to this host. Essentially allowing NAT traversal and direct TCP/UDP connectivity host to host.

As an implementor ourselves working at the kernel level on other products we have built a well-defined request to Mikrotik in July 2020 [...] I strongly recommend folks who want this feature reach out to MikroTik and reference SUP-20798 if they care about this feature.
Um, no? Or at least that's not the behaviour described/wanted in this topic, the bold part in specific.
And without knowing what SUP-20798 contains, nobody will reference it.
To clarify, the recording and communication of the opened IP/port isn’t the feature being requested. The allowing of any remote IP l/source port to connect to the opened IP and port is the feature. Hence “endpoint independent”.

Suit yourself on not referencing that ticket. It’s the feature discussed here and one of the primary capabilities missing from the MikroTik NAT/firewall implementation that separate it from a true CGN appliance.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Mon Apr 24, 2023 8:05 pm

endpoint independent mapping will be available in 7.10beta version when its released.
It seems you've created the documentation already here:
https://help.mikrotik.com/docs/display/ ... pendentNAT

But it says "Endpoint-independent NAT works only with UDP protocol." - Why?

It should support TCP as well, shouldn't it? Per RFC5128. It should also support src-nat, netmap and "same" actions.

Ironically the example in the docs uses TCP:
/ip firewall nat
add action=endpoint-independent-nat chain=srcnat out-interface=WAN protocol=tcp

/ip firewall nat
add action=endpoint-independent-nat chain=dstnat in-interface=WAN protocol=tcp
It's also unclear why chain=dstnat is required.
 
User avatar
Archous
just joined
Posts: 10
Joined: Thu May 12, 2022 7:13 am
Location: USA
Contact:

Re: FEATURE REQUEST: full cone NAT

Mon May 01, 2023 5:05 am

Funny, they edited it as it now shows UDP. Agreed though this needs to support both UDP and TCP.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed May 03, 2023 11:27 pm

Funny, they edited it as it now shows UDP. Agreed though this needs to support both UDP and TCP.
Unless they properly support TCP/UDP both, and heck maybe all layer 4 protocols (DCCP, UDP-Lite, SCTP etc) – I would not use this half-baked full cone NAT option of MikroTik, sticking to netmap is better, at least I know it works with all protocols without having to think twice.
 
AntiUltimate
just joined
Posts: 10
Joined: Tue Sep 11, 2018 9:25 pm

Re: FEATURE REQUEST: full cone NAT

Fri May 05, 2023 10:36 pm

So let me get this straight, by using my Nintendo Switch as an example (playing Splatoon 3 or whatever).

Does this mean if I set up Endpoint-Independent NAT that, when my Switch initiates an outbound connection using SRC Port 54809 as example here, any other console can now connect to the same port, just like if it was manually setup as dstnat rule by me, automatically? (Even if my console has not initated a connection to the other consoles yet)

That's what I get from here. In all honesty that would be a godsend to anyone playing on the Nintendo Switch. Hope the beta is released soon so i can test :)
 
User avatar
Archous
just joined
Posts: 10
Joined: Thu May 12, 2022 7:13 am
Location: USA
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri May 05, 2023 10:53 pm

So let me get this straight, by using my Nintendo Switch as an example (playing Splatoon 3 or whatever).

Does this mean if I set up Endpoint-Independent NAT that, when my Switch initiates an outbound connection using SRC Port 54809 as example here, any other console can now connect to the same port, just like if it was manually setup as dstnat rule by me, automatically? (Even if my console has not initated a connection to the other consoles yet)

That's what I get from here. In all honesty that would be a godsend to anyone playing on the Nintendo Switch. Hope the beta is released soon so i can test :)
Yes, exactly. In full cone, the connection is no longer restricted by IP address.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Fri May 05, 2023 10:57 pm

So let me get this straight, by using my Nintendo Switch as an example (playing Splatoon 3 or whatever).

Does this mean if I set up Endpoint-Independent NAT that, when my Switch initiates an outbound connection using SRC Port 54809 as example here, any other console can now connect to the same port, just like if it was manually setup as dstnat rule by me, automatically? (Even if my console has not initated a connection to the other consoles yet)

That's what I get from here. In all honesty that would be a godsend to anyone playing on the Nintendo Switch. Hope the beta is released soon so i can test :)
Yes, but only for UDP. If some traffic is sent via TCP by a specific game or application, then no.

MikroTik should support both to avoid confusion and headaches.
 
AntiUltimate
just joined
Posts: 10
Joined: Tue Sep 11, 2018 9:25 pm

Re: FEATURE REQUEST: full cone NAT

Sat May 06, 2023 11:14 am

Yes, but only for UDP. If some traffic is sent via TCP by a specific game or application, then no.

MikroTik should support both to avoid confusion and headaches.
That's dumb, i hope it gets implemented during the beta, it makes 0 sense for this to be exclusive to UDP.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat May 06, 2023 11:32 am

This topic started about gaming, games requiring something like this for multiplayer, mostly, if not all, communicate over UDP.
So not that dumb.
 
AntiUltimate
just joined
Posts: 10
Joined: Tue Sep 11, 2018 9:25 pm

Re: FEATURE REQUEST: full cone NAT

Sat May 06, 2023 11:40 am

This topic started about gaming, games requiring something like this for multiplayer, mostly, if not all, communicate over UDP.
So not that dumb.
On Nintendo Switch from what i can tell, a TCP connection is established to the matchmaking server, and the same port is then used to connect to each other consoles using UDP. This isn't such a big problem, but i can imagine that it wont work with the port randomization feature they implemented for Endpoint Independent Mapping.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat May 06, 2023 11:42 am

I'm sure that they can improve the feature in the future.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: FEATURE REQUEST: full cone NAT

Sat May 06, 2023 1:06 pm

I'm sure that they can improve the feature in the future.
it is called "Simultaneous TCP Open" sessions in RFC
Last edited by volkirik on Sun May 07, 2023 12:06 am, edited 2 times in total.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat May 06, 2023 11:34 pm

I'm sure that they can improve the feature in the future.
If they took 10+ years for BFD on ROSv7 to improve, they will take another 20 years to support TCP.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: FEATURE REQUEST: full cone NAT

Sat May 06, 2023 11:54 pm

RFC allows UDP , TCP and ICMP
Last edited by volkirik on Sun May 07, 2023 12:06 am, edited 2 times in total.
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Sat May 06, 2023 11:59 pm

I wish they didn't make running OpenWrt on their hardware so hard.
The last few stable release topics are .... well, not great.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun May 07, 2023 12:06 am

RFC allows only UDP
Nah check the RFC again. It allows TCP NAT punching via open method.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: FEATURE REQUEST: full cone NAT

Sun May 07, 2023 12:13 am

I edited my post,
but RFC states that
"Simultaneous TCP Open" is not implemented correctly on many systems, including NAT devices.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun May 07, 2023 1:13 am

but RFC states that
"Simultaneous TCP Open" is not implemented correctly on many systems, including NAT devices.
Exactly, this is talking about the LACK of TCP Open support on old OSes at the time AND on NAT devices, aka MikroTik which clearly doesn't support TCP NAT punching.

100 different people in this thread have shown Cisco, Huawei, Juniper all support full cone NAT for both TCP and UDP. Only MikroTik and vanilla Linux does not.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: FEATURE REQUEST: full cone NAT

Sun May 07, 2023 12:17 pm

but RFC states that
Exactly, this is talking about the LACK of TCP Open support on old OSes at the time AND on NAT devices, aka MikroTik which clearly doesn't support TCP NAT punching.

100 different people in this thread have shown Cisco, Huawei, Juniper all support full cone NAT for both TCP and UDP. Only MikroTik and vanilla Linux does not.
+1 for the feature request, then..
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: FEATURE REQUEST: full cone NAT

Sun May 07, 2023 4:26 pm

does anyone have 7.10alpha release for mipsbe?
 
AntiUltimate
just joined
Posts: 10
Joined: Tue Sep 11, 2018 9:25 pm

Re: FEATURE REQUEST: full cone NAT

Sun May 07, 2023 5:21 pm

You know, it would be nice if we could add Src and Dst ports to a list too so we can manually port forward them without having to wait on Mikrotik implement EIM-NAT for TCP.

EDIT: Infact if you live alone you can already have Full Cone NAT by just adding everything your device connects to to an Adress List and DST-NATing to that. I wouldn't do it with a PC but for a Nintendo Switch that looks to be great.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun May 07, 2023 7:06 pm

You know, it would be nice if we could add Src and Dst ports to a list too so we can manually port forward them without having to wait on Mikrotik implement EIM-NAT for TCP.

EDIT: Infact if you live alone you can already have Full Cone NAT by just adding everything your device connects to to an Adress List and DST-NATing to that. I wouldn't do it with a PC but for a Nintendo Switch that looks to be great.
You can avoid both by using the netmap method, it allows STUN to do its job and ensures the remote end-point can connect to your IP:Port combo matching the port number actually in use by the application on the host.

EIM-NAT aka full cone NAT of MikroTik is half-assed, I would avoid it, because it's overly complex once you start looking into it on the packet processing layer, due to lack of TCP support and also no explanation given for why dst-nat chain is required. This isn't required on other vendors.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun May 07, 2023 10:19 pm

netmap if you configured it correctly, it will result in two things:
1. Mapping will be "Address and Port-Dependent Mapping"
2. Filtering will be "Address and Port-Dependent Filtering"

This is of course not proper full cone NAT, however it allows both UDP/TCP to work the moment both end-points send a packet to each other and open a hole in the NAT state mechanism. This happens is like 1ms, so delays don't occur or packet timing mismatch on the internet.

However, the problem with this method is it require the app to make use of STUN to inform all peers to send packets to each other in order for all valid peers to be talking to each other directly.

If MikroTik supports proper full cone NAT, then the above isn't required, STUN only needs to discover IP:Port once, the client will send one packet, NAT hole will open, and now ANY external peers can connect directly without the client having had to send any traffic to all the peers and vice versa.

So in short, netmap method works fine, it's just additional traffic in the network. Full cone proper will remove additional traffic, ask MikroTik to support it properly.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Wed Jun 21, 2023 4:42 pm

Thank you for bringing Endpoint-Independent NAT through RouterOS 7.10.
It allows game consoles to support Full Cone NAT through simple configuration.

Here is the configuration code:
/ip firewall nat
add action=endpoint-independent-nat chain=srcnat out-interface-list=WAN protocol=udp
add action=endpoint-independent-nat chain=dstnat in-interface-list=WAN protocol=udp
Here is the URL for more information:
https://help.mikrotik.com/docs/display/ ... pendentNAT
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed Jun 21, 2023 7:49 pm

Thank you for bringing Endpoint-Independent NAT through RouterOS 7.10.
It allows game consoles to support Full Cone NAT through simple configuration.
It's broken, it's not full-cone, it's port restricted cone with EIM.
viewtopic.php?t=197095#p1008596
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Wed Jun 21, 2023 10:40 pm

In my test any external IP address can reach the port, I haven't used that testing tool, just directly opened connections.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 22, 2023 7:20 pm

In my test any external IP address can reach the port, I haven't used that testing tool, just directly opened connections.
Please share your testing methodology with us that confirms ANY external IP can reach. And why isn't TCP also supported?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Jun 22, 2023 8:31 pm

Concur, since MT went down this rabbit hole for the few, ( vice zerotrust cloudflare tunnel for the many ), I'm with darknate to ensure that the implementation is done properly.

However Darknate at leasts part of your query is answered. i think......

In the RFC document linked under applicablitily:

1. Applicability Statement

This protocol is not a cure-all for the problems associated with NAT.
It does not enable incoming TCP connections through NAT. It allows
incoming UDP packets through NAT
, but only through a subset of
existing NAT types.
In particular, STUN does not enable incoming UDP
packets through symmetric NATs (defined below), which are common in
large enterprises. STUN's discovery procedures are based on
assumptions on NAT treatment of UDP; such assumptions may prove
invalid down the road as new NAT devices are deployed. STUN does not
work when it is used to obtain an address to communicate with a peer
which happens to be behind the same NAT. STUN does not work when the
STUN server is not in a common shared address realm. For a more
complete discussion of the limitations of STUN, see Section 14.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Fri Jun 23, 2023 3:25 pm

That RFC is specifically for STUN, however that's also ancient. In 2023, STUN servers supports TCP/UDP and any other protocol that you want.

TCP NAT punching is a very real thing, that EIM-NAT/Full Cone NAT should fully support:
https://datatracker.ietf.org/doc/html/rfc7857#section-2

https://en.wikipedia.org/wiki/TCP_hole_punching
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Jun 23, 2023 6:06 pm

Sweet, in the second link there is this statement.......

TCP hole punching is an experimentally used NAT traversal technique for establishing a TCP connection between two peers on the Internet behind NAT devices. NAT traversal is a general term for techniques that establish and maintain TCP/IP network and/or TCP connections traversing NAT gateways.

Is there an RFC for this............. or does the first article support TCP hole punching with some definition.......

Regardless, they should complete the work.....
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Fri Jun 23, 2023 9:12 pm

There are RFCs for it, but I'm not going to find them all. Here's some more. Point is MikroTik should support both TCP/UDP properly. TCP is easy for them, just permit ANY external IP once SYN has been initiated behind the NAT.

https://datatracker.ietf.org/doc/html/rfc7350

https://datatracker.ietf.org/doc/html/r ... tion-6.2.2
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Jun 23, 2023 9:50 pm

Well they seem painfully unable to address OVPN, so not holding out hope for cone nat type changes in the near term.
 
1206799565
just joined
Posts: 1
Joined: Fri Jun 23, 2023 2:54 pm

Re: FEATURE REQUEST: full cone NAT

Sat Jun 24, 2023 1:34 pm

endpoint independent mapping will be available in 7.10beta version when its released.
When using Endpoint-Independent NAT currently, there is a kernel failure after creating a large number of UDP connections.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun Jun 25, 2023 1:35 pm

When using Endpoint-Independent NAT currently, there is a kernel failure after creating a large number of UDP connections.
Lol, what did you expect from MikroTik software quality assurance team? Of course there's kernel failure.
 
mafiosa
Member Candidate
Member Candidate
Posts: 266
Joined: Fri Dec 09, 2016 8:10 pm
Location: Kolkata, India
Contact:

Re: FEATURE REQUEST: full cone NAT

Sun Jun 25, 2023 8:21 pm

Bugtik
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sun Jun 25, 2023 9:41 pm

The so called "EIM-NAT" implementation of MikroTik does not work, even on consoles, I still see "moderate" NAT aka port-restricted cone and similar.
Image

We still need manual port forwarding or UPnP.
 
Guscht
Member Candidate
Member Candidate
Posts: 236
Joined: Thu Jul 01, 2010 5:32 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 1:37 am

@Mikrotik:
Could you please describe IN DETAIL how the EIM-Implementation works?

I wonder how:
- For outgoing connections, always the same SOURCE PORT is used for the same internal IP:Port-combination to an external host? Or Iam wrong?
- What if 2 (or more) internal hosts connect to the same external host using the same source-port? How is this externally mapped with EIM?
- For the answer back, I understand it that way, any DESTINATION PORT (from any external host) will be mapped to the internal host (but form all external hosts or only from the one initally connected to)?
- How does it behve if 2 (or more) internal hosts required a connection to the same external IP with the same internal SOURCE PORT?
- How does the mentioned NETMAP work, if in the "TO-ADDRESS" the WAN-IP is entered? Why does NETMAP allow all(?) external hosts to be mapped to an internal host? Thats a thing I totally not understand, but another user mentioned it will work. AFAIK NETMAP is to NAT a network the same size statically, like a /24 to a /24.

And please consider to enhance your wiki/help. This quite complex and confusing area needs more description as to lines for a src and dstnat-rule...
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 2:27 am

In plain and simple English.

On MikroTik, Full-Cone NAT + EIM-NAT does NOT work properly, as of ROSv7.10.

I tested again on a Juniper and Huawei NAT box, and it works fine there, so problem as usual, is MikroTik.
 
User avatar
loloski
Member Candidate
Member Candidate
Posts: 277
Joined: Mon Mar 15, 2021 9:10 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 7:02 am

If this indeed work https://github.com/LGA1150/openwrt-fullconenat why MT can't just patch their userland and kernel code tweak and adjust accordingly and moved on? just curious sometimes they have this attitude of NIH syndrome, since the underlying OS of ROS is Linux doesn't it make sense to go this route to conserved time?
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 8:10 am

ROS is Linux doesn't it make sense to go this route to conserved time?
I think they did, and that may be the problem. @DarkNate suggested earlier:
Only MikroTik and vanilla Linux does not.
I take that to mean there is not some standard kernel thing that does it.
 
User avatar
loloski
Member Candidate
Member Candidate
Posts: 277
Joined: Mon Mar 15, 2021 9:10 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 10:04 am

If they implement that code and they found it buggy why bother releasing it in the wild specially if the implementation is incomplete? this is just like the date format standardization stuff they release from past release, anyway I hope they were able to sort this out soon or just remove it if it's not worth in the codebase
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 10:38 am

If they implement that code and they found it buggy why bother releasing it in the wild specially if the implementation is incomplete?
MikroTik does not really have multiple release trains. There is no separate "development" branch where things are developed and tested and later merged into a "stable" branch. The names are there to suggest it, but in reality it is just one single development release that at some random point in time is stamped as "stable", including all the half-finished developments that are in it...
And in case of the "full cone NAT" that is not really important, you can just ignore it. In case of the "date format" it is more nasty as users of the stable branch are affected by the partly implemented stuff, they have no choice to ignore that.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 10:45 am

why MT can't just patch their userland and kernel code tweak and adjust accordingly and moved on
Remember that the more patches are made to the kernel, the more difficult it will become to upgrade the kernel version.
That will mean that more and more facilities that are available in the standard kernel of the day will not become available in RouterOS soon.
We have seen how that went with v6, how big of a hurdle it was to release v7 which mainly was "a new kernel". It took many years, and all that time people here were posting complaints like "why don't we have CAKE it has been in the kernel for years", and "why is my hardware not supported (USB stick, network card in x86, etc)".
So you really do not want too many patches in the kernel!
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 10:53 am

In my test any external IP address can reach the port, I haven't used that testing tool, just directly opened connections.
Please share your testing methodology with us that confirms ANY external IP can reach. And why isn't TCP also supported?
There is no rocket science:
Open connection from local client over EIM enabled router to public IP.
Then open connection from other public IP to the same port and observe the flow over the router.
Flows gets mapped properly and forwarded to correct local client and port.
 
User avatar
loloski
Member Candidate
Member Candidate
Posts: 277
Joined: Mon Mar 15, 2021 9:10 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 11:40 am

@pe1chl I hope this situation will be improved in the future, because ROS is not a toy lots of people depends on it every day to deliver what's being advertise, specially in the ISP space this is the part where our management didn't see (hidden cost), In as much as I loved MikroTik for what it's worth but I also missed the stability/correctness of release of other vendor [_insert_vendor_here_] sadly our fleet is dominated by Mikrotik I don't complain the platform itself just the way they do things which break the norms, I realized our decision last year to mix platforms because of lack of BFD in ROSv7 way back then has unintended side effect at least in a good way. We can juggle things up is something goes wrong with MT :)
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 1:49 pm

There is no rocket science:
Open connection from local client over EIM enabled router to public IP.
Then open connection from other public IP to the same port and observe the flow over the router.
Flows gets mapped properly and forwarded to correct local client and port.
Does not work in my testing, port is not reachable from ANY external public IP. Additionally, Cisco/Juniper/Huawei etc supports TCP+UDP for full cone/EIM, yet your employer (MikroTik) fails to support a feature that was invented a decade ago if not more.

This is the configuration I used on MikroTik side:
viewtopic.php?p=1010517#p1010447

Every day, thousands of MikroTik users complain one new problem after the other in this forum, Reddit and other social media platform, yet you and your colleagues fail to comprehend that your software development model and Q/A is utter garbage. You (MikroTik employees, all of them) can keep up with that ego, while people in the operator space migrate away from MikroTik to other vendors because of these very issues. Within the next 12 months, one of my parnters are removing 500+ MikroTik devices because of these dumb issues, and we're moving away to whiteboxes or Juniper. Hell, even for normal home lab, MikroTik is not stable, I'm going to eventually just move to Juniper using refurbished equipment.

Even one of your biggest partner IPArchitechs has recently started moving to OcNOS publicly, that speaks for itself.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 1:51 pm

@pe1chl I hope this situation will be improved in the future, because ROS is not a toy lots of people depends on it every day to deliver what's being advertise, specially in the ISP space this is the part where our management didn't see (hidden cost), In as much as I loved MikroTik for what it's worth but I also missed the stability/correctness of release of other vendor [_insert_vendor_here_] sadly our fleet is dominated by Mikrotik I don't complain the platform itself just the way they do things which break the norms, I realized our decision last year to mix platforms because of lack of BFD in ROSv7 way back then has unintended side effect at least in a good way. We can juggle things up is something goes wrong with MT :)
I would use MikroTik only for basic L2/L3 switching. For routing, edge, BNGs, MPLS/VXLAN/EVPN etc, I would use other vendors.

MikroTik RouterOS v7 is super unstable.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 2:00 pm

We implemented exactly what was asked by the OP, who confirmed that feature he asked works. Yet you do not provide any useful info no configuration no setup in which it is not working, nothing, just some screenshot by some tool which shows "moderate", which is completely useless to identify the problem.
Just a complain "not work, fix or I leave".
If you have a device set up as the manual states and mapping does not work properly then please send a report to support with supout files and other relevant info.
 
User avatar
loloski
Member Candidate
Member Candidate
Posts: 277
Joined: Mon Mar 15, 2021 9:10 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 2:02 pm

Yeah we use Juniper mx40 for the edge and BNG exclusively and lots of 1036 for BRAS and 317 as L2 switch :)
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 3:56 pm

We implemented exactly what was asked by the OP, who confirmed that feature he asked works. Yet you do not provide any useful info no configuration no setup in which it is not working, nothing, just some screenshot by some tool which shows "moderate", which is completely useless to identify the problem.
Just a complain "not work, fix or I leave".
If you have a device set up as the manual states and mapping does not work properly then please send a report to support with supout files and other relevant info.
I clearly provided configuration example in previous comment.
This is the configuration I used on MikroTik side:
viewtopic.php?p=1010517#p1010447
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 10:29 pm

Like I said, send a proper bug report to support.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: FEATURE REQUEST: full cone NAT

Thu Jun 29, 2023 11:00 pm

mrz your replies are disappointingly biased.
First, darknate uses an open source nat tester tool.......did you pass that on to the dev team??
https://github.com/HMBSbige/NatTypeTester

Second he provided what he thinks is enough config info to duplicate the issue

On ROSv7.10, neither method works. Downgraded to ROSv7.9.2 and method 2 works fine
#Method 1#
add action=endpoint-independent-nat chain=srcnat out-interface-list=WAN protocol=udp randomise-ports=no src-address=192.168.0.0/24 to-addresses=1.1.1.1
add action=endpoint-independent-nat chain=dstnat dst-address=1.1.1.1 in-interface-list=WAN protocol=udp randomise-ports=no to-addresses=192.168.0.0/24
add action=netmap chain=srcnat ipsec-policy=out,none out-interface-list=WAN src-address=192.168.0.0/24 to-addresses=1.1.1.1

#Method 2#
add action=netmap chain=dstnat in-interface-list=WAN protocol=udp dst-port=1024-65535 dst-address=1.1.1.1 to-addresses=192.168.0.2
add action=netmap chain=srcnat ipsec-policy=out,none out-interface-list=WAN src-address=192.168.0.0/24 to-addresses=1.1.1.1



Finally, he has been investigating and understanding this problem far deeper and longer than any of your dev staff and actually has experience of this functionality across brands, so he can comparatively state, its broken on the MT.

So quit the arrogance act and get cracking on fixing it.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Jun 30, 2023 10:14 am

If there is indeed deep and long investigation then there should be no problems to create a support ticket and provide that detailed info.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Fri Jun 30, 2023 2:40 pm

If there is indeed deep and long investigation then there should be no problems to create a support ticket and provide that detailed info.
A supout file isn't going to give you any special info, the configuration is dead simple, I've shared the sample. I've even shared an OPEN SOURCE tool that tests for RFC compliance and MikroTik fails miserably. This is sufficient for you to replicate the test/issue.

I've worked with more vendors than you and your colleagues have, on a daily basis, you work with MikroTik daily. I work in daily operations and deployments with all kinds of vendors, even ones you've never heard of. So please, don't tell me your implementation is working correctly. It isn't.

Whether you take this feedback and the previous ones constructively or not is your choice, fix this full cone issue (and other bugs by other users reporting) and you'll ensure your large enterprise customers and partners will remain loyal, or keep up with the ego, arrogance and watch us drop MikroTik from our infrastructure like it's yesteryear, and we'll gladly pay thousands of dollars more to other vendors that “just works” and "gladly fixes bugs". Whether MikroTik likes money or not remains to be seen…
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: FEATURE REQUEST: full cone NAT

Fri Jun 30, 2023 3:17 pm

try to remove dst-address param from rule in dstnat chain.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Fri Jun 30, 2023 4:20 pm

try to remove dst-address param from rule in dstnat chain.
I can't do that, as I have multiple public IPs from “interface list WAN” coming in to the BNG and specifically perform the mapping to specific RFC1918 ranges or 100.64/0 ranges. dst-address param is required for correct mapping.

I will try to test this in home lab later though, single public IP from ISP, not sure why we should remove it still, though?
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Sat Jul 01, 2023 12:51 am

I've tested it in my home lab without the dst-address param. No changes visible. I still see port-restricted cone as the end-result. The port is not reachable from ANY, only reachable by peers that have been solicited outbound.

I found the issue in your implementation, probably. Whilst the mapping behaviour is “Endpoint-Independent Mapping”, however the filtering behaviour isn't “Endpoint-Independent Filtering”, it is actually “Address and Port-Dependent Filtering”. Therefore, it cannot be full cone. Both mapping and filtering should be “Endpoint-Independent” for full cone to work.

Mapping:
https://datatracker.ietf.org/doc/html/r ... ection-4.1

Filtering:
https://datatracker.ietf.org/doc/html/rfc4787#section-5
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Tue Jul 18, 2023 3:04 am

Currently, endpoint-independent-nat does solve the NAT1 issue for home gaming consoles, eliminating the need for manual UDP NAT configuration for PS5, Xbox, and Switch.
However, enabling it is not recommended for now because it can lead to random kernel failures in versions 7.10.x and 7.11betaX.
It has been confirmed to occur on ARM, ARM64, and x86 (CHR) architectures.

If your RouterOS is also experiencing kernel failure,
please disable, or delete the relevant code for endpoint-independent-nat.
Wait for a new version that includes fixes and updates.

viewtopic.php?p=1013703
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Tue Jul 18, 2023 1:05 pm

Currently, endpoint-independent-nat does solve the NAT1 issue for home gaming consoles, eliminating the need for manual UDP NAT configuration for PS5, Xbox, and Switch.
However, enabling it is not recommended for now because it can lead to random kernel failures in versions 7.10.x and 7.11betaX.
It has been confirmed to occur on ARM, ARM64, and x86 (CHR) architectures.

If your RouterOS is also experiencing kernel failure,
please disable, or delete the relevant code for endpoint-independent-nat.
Wait for a new version that includes fixes and updates.

viewtopic.php?p=1013703
The full cone implementation on MikroTik is half-baked. How would it solve anything? Did you not read my findings above? MikroTik has made it clear, they aren't interested in fixing it.
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Mon Jul 31, 2023 12:36 pm

fixed in 7.11rc1

What's new in 7.11rc1 (2023-Jul-28 09:52):
*) firewall - improved system stability when using "endpoint-independent-nat";
 
kcarhc
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 57
Joined: Thu Feb 01, 2018 9:54 am

Re: FEATURE REQUEST: full cone NAT

Mon Jul 31, 2023 12:44 pm

here is the code
/ip firewall nat
add action=endpoint-independent-nat chain=srcnat out-interface-list=WAN protocol=udp
add action=endpoint-independent-nat chain=dstnat in-interface-list=WAN protocol=udp
NatTyperTester.png
You do not have the required permissions to view the files attached to this post.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Tue Aug 15, 2023 4:04 pm

I tested, it's port restricted cone.

You're seeing "full cone" if you run it twice with a few seconds, the reason for that is the MikroTik box maintains the state for a few tens of seconds and the remote end-point whose source IP is just the same as previous one, will be able to reach your IP:Port combo in the "full cone" sense, run it once only, wait for 2 mins and run again.

tl;dr
No visible fix on ROS v7.11 stable.
 
Guscht
Member Candidate
Member Candidate
Posts: 236
Joined: Thu Jul 01, 2010 5:32 pm

Re: FEATURE REQUEST: full cone NAT

Thu Aug 17, 2023 5:37 pm

I see "Full Cone" even if I have no EIN rules created (also with a ROS v6 tested too), if pressing the button twice within a few seconds.
Which leads me to a point, that this software is maybe not as good?!
 
User avatar
Znevna
Forum Guru
Forum Guru
Posts: 1347
Joined: Mon Sep 23, 2019 1:04 pm

Re: FEATURE REQUEST: full cone NAT

Thu Aug 17, 2023 5:48 pm

Something as sketchy as this deservers a sketchy test program with sketchy results.
All good.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Thu Aug 17, 2023 7:49 pm

The only other tool I know of is Xbox networking app. Run the network tests, it'll show you the correct results.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: FEATURE REQUEST: full cone NAT

Thu Aug 17, 2023 8:20 pm

They need a /tool/nat-detect – I'd rather know the situation, before some gamer is screaming about a test on an XBox.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Thu Aug 17, 2023 8:50 pm

They need a /tool/nat-detect – I'd rather know the situation, before some gamer is screaming about a test on an XBox.
I mean this is open source:
https://github.com/HMBSbige/NatTypeTester/

The solution is to patch the source code's bugs, and add support for the remaining RFCs to ensure a wholistic tool for NAT detection other than Xbox.
 
Guscht
Member Candidate
Member Candidate
Posts: 236
Joined: Thu Jul 01, 2010 5:32 pm

Re: FEATURE REQUEST: full cone NAT

Thu Aug 17, 2023 9:26 pm

I tested now with "Packet Sender" and Wireshark. I can conclude it works that way (using the two rules provided in the MT-Help):

If I send a UDP packet (from my LAN) to a random IP on the WAN, like 8.8.8.8:12345 the Source-Port of this packet (eg. a random Highport like 54321) is now open to ANY IP - not only 8.8.8.8.

If I send now a Packet back, from a different WAN-IP (not 8.8.8.8 ) like 25.25.25.25 to the initial WAN-IP:54321, this packet will correctly arrive back on my Windows-Machine.

The inital Destination-Port (on the way back again as Destination-Port) does not work.
Any other port like 54320 or 54322 does also not work. Only the inital/outgoing SOURCE-PORT now as Desination-Port.

If you randomize the port on the -initial- way out (SNAT), you have to use this randomized port to reach the initial machine.

This whole stuff works like a big "dynamic DNAT for UDP". I see still no difference to a stinkin normal DNAT rule without a defined Source-IP.

I cant tell if this behaviour is RFC compliant or not. But it works this way in reproducible way.
I assume if the UDP-Timeout in the conntracking reaches it defaut 10 second-limit, the inital connection drops if no ongoing frames passes.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Fri Aug 18, 2023 5:05 pm

I don't know, seems flaky. Anyway, personally I use IPv6 everywhere, I stopped caring about NATs.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: FEATURE REQUEST: full cone NAT

Tue Feb 13, 2024 7:49 pm

I don't know, seems flaky. Anyway, personally I use IPv6 everywhere, I stopped caring about NATs.
How did you test ? Did you use a public Stun server ?

I did test with a public Stun server and got the same results as you : endoint dependent NAT. But i'm skeptical, because Mikrotik said it's working.

Then i did test with a 1:1 NAT. And same results. With 1:1 NAT we should have an endpoint independent result isn't it ?

Then here is my thought : i think that my Internet provider is filtering in his network to forbid full cone NAT.

A way to check that would be to test with a private Stun server and NettypeTest, between two natted local subnetworks.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 14, 2024 12:37 am

I tested using this:
https://github.com/HMBSbige/NatTypeTester

The software bugs have been fixed (I spoke to the developer of this software directly).

MikroTik still fails the test. When I test on Juniper or Cisco, test passes just fine.

I think MikroTik is failing to test this correctly.

TCP/UDP BOTH work in Juniper and Cisco as per the RFCs for this technology.
 
Mesquite
Member
Member
Posts: 420
Joined: Tue Jan 23, 2024 9:16 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 14, 2024 4:06 am

Darknate you have investigated this functionality for some time to great lengths and depths and its STUNning to me that MT doesnt pay more attention to your writing on this subject!!
Its it just me or is they don't write full requirements for their software...... Mind you I dont know how you right half requirements, its seems a foreign concept. ;-)
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: FEATURE REQUEST: full cone NAT

Wed Feb 14, 2024 12:01 pm

I tested using this:
https://github.com/HMBSbige/NatTypeTester

The software bugs have been fixed (I spoke to the developer of this software directly).

MikroTik still fails the test. When I test on Juniper or Cisco, test passes just fine.

I think MikroTik is failing to test this correctly.

TCP/UDP BOTH work in Juniper and Cisco as per the RFCs for this technology.
Did you test on the same external network with each setup ? there could be a different external filtering on the public IP addresses you did use that could explain those differences. Do you own those public IPs ?

Regardless what i do i cannot get independant endpoint filtering. Even NAT 1:1 does not give it. This is why i think that my public IP could be filtered externally to forbid full cone nat.

I think that we need to test with a local stun server on a private natted subnetwork to be sure. Or manual testing from such a network. Did you do that with the Mikrotik setup ?
Last edited by FIPTech on Wed Feb 14, 2024 12:09 pm, edited 1 time in total.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 14, 2024 12:08 pm

Did you test on the same external network with each setup ? there could be a different external filtering on the public IP addresses you did use that could explain those differences. Do you own those public IPs ?

Regardless what i do i cannot get independant endpoint filtering. Even NAT 1:1 does not give it. This is why i think that my public IP is filtered externally to forbid full cone nat.

I think that we need to test with a local stun server on a private natted subnetwork to be sure. Or manual testing from such a network. Did you do that with the Mikrotik setup ?
I own the whole god-damn Autonomous System and have operated commercial networks at scale. Trust me, dude, MikroTik's EIM-NAT is broken.

Why/How? Not my job to decode their source code, ask MikroTik.

Like I said, no problems on Cisco and Juniper EIM-NAT implementation.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Wed Feb 14, 2024 12:09 pm

Darknate you have investigated this functionality for some time to great lengths and depths and its STUNning to me that MT doesnt pay more attention to your writing on this subject!!
Its it just me or is they don't write full requirements for their software...... Mind you I dont know how you right half requirements, its seems a foreign concept. ;-)
They don't listen to me or anybody, see this:
viewtopic.php?t=204023
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: FEATURE REQUEST: full cone NAT

Wed Feb 14, 2024 12:17 pm

Ok, i'm going to try a new test with a local Stun server on a natted private subnetwork. If it's broken this will make another serious report and they will probably fix it.

I will need some time nevertheless to setup a Stun server. If someone can do it faster than me it would be fine.

I need it because i do not own the public IP i'm using to access one of the public Stun server proposed in the NatTypeTester utility. This IP could be filtered externally, i get it through a MAP-E tunnel.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: FEATURE REQUEST: full cone NAT - Working !

Fri Feb 16, 2024 4:38 pm

Ok i tried it.

Setup : two local sub-networks, on two different VLANs, routed through an RB5009, Ros 7.14RC1.

Source NAT between the two sub-networks using endpoint independent NAT actions in src-nat and dst-nat chains.
NAT Test rules.png
On the "WAN" network, i started a STUNMAN version 1.2.16 STUN server in full mode : two IP addresses and four listening ports. Here is the STUN server setup :

Starting server 1
--------------------------
strMode = full
strPrimaryInterface = 10.50.50.10
strAltInterface = 10.50.50.11
--------------------------

PP = 10.50.50.10:3478
PA = 10.50.50.10:3479
AP = 10.50.50.11:3478
AA = 10.50.50.11:3479
Protocol = UDP
Configuring single threaded mode

Successfully started server.Starting listener thread (4 recv sockets, 4 send sockets)

On the "LAN" side, i used NatType Tester version 8.02 in UDP mode.

Here is the result :
NAtType Tester Result OK.png
This shows that Netpoint independent mapping and filtering works correctly. We have full cone !!

I think that people here saying that it doesn't work made an error : they do not have a firewall rule to permit those connections for UDP traffic from WAN to LAN from foreign IP addresses.

If you do not have such a firewall rule in forward, then endpoint independent filtering will not work anymore, you will get this result :
NAtType Tester Result.png
As you can see, the filtering is now address and port dependent. Full cone is not possible anymore.

Conclusions :

1) Endpoint independent mapping and filtering works correctly. The default firewall established traffic catch forward rule just needs to be modified or another rule added to permit endpoint independent traffic (foreign IPs) to travel in forward from WAN to LAN.

There is a new matcher that seems to be designed for this use in the "Connection NAT State" matchers :
We have now ein-snat and ein-dnat :
.
connection state.png
I tried it but it does not seem to have an effect. Are they designed to permit foreign IP addresses to enter through ports opened by Independent NAT mapping actions ?

2) Mikrotik should add an explanation in the help (https://help.mikrotik.com/docs/display/ROS/NAT), indicating that to get independent filtering working, a firewall rule in forward needs to be added to allow UDP traffic from WAN to LAN for all IP addresses that should be authorized to contact the opened ports.

3) Years of experience in networking is not a serious indicator of a network technician, engineer or manufacturer efficiency or smartness. :lol: :lol: :lol:

4) Gamers can now enjoy full cone NAT with Mikrotik routers :D
You do not have the required permissions to view the files attached to this post.
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 16, 2024 6:17 pm

Chances are high, your testing methodology may be flawed, I don't see network diagrams and full config.

As for firewall, firewall is null in my testing and many others in this thread, so firewall is ruled out from day one. In addition, firewall on Windows laptop was also disabled.

If you believe that MikroTik's EIM-NAT backend implementation is complying with the RFC, to the same level as Cisco and Juniper — Then good luck and have fun, buddy.

My conclusion:
It doesn't work per the RFC fully. OR MikroTik silently fixed it in newer versions without posting in changelog, my last version test was: 7.11

Ain't wasting more time on this than I already have. IPv6 is the future and works fine for my customers, nobody's complaining about NAT problems on native IPv6.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: FEATURE REQUEST: full cone NAT

Fri Feb 16, 2024 6:56 pm

My setup cannot be simpler. I will not spend time for a drawing.
two local sub-networks, on two different VLANs, routed through an RB5009, Ros 7.14RC1.
Just that and default firewall rules to forbid WAN to LAN traffic and allow established traffic.

Then another firewall forward rule to permit WAN to LAN UDP traffic. Without this rule, full cone is not available, and this is normal because foreign IP by definition are foreign. They are not in the connections table and because of that cannot use the established traffic forward rule.

IPv6 for sure is the futur, but still not available everywhere, and will never be for some old games.

For me it's working. As you said, NatType Tester is not buggy, and my tests show that he gives repeatable results.

Then we can probably trust it even if the RFC5780 is not fully implemented. Manual testing at Mikrotik seems to show the same positive results.

There are a lot of things that do not fully follow RFCs. But when it works, it works... And full cone is mainly for gamers or individual use, it will never be implemented inside a provider network anyway. If it works, it works...
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 999
Joined: Fri Jun 26, 2020 4:37 pm

Re: FEATURE REQUEST: full cone NAT

Fri Feb 16, 2024 7:44 pm

Which part of this is unclear? THERE’S NO FIREWALL!
As for firewall, firewall is null in my testing and many others in this thread, so firewall is ruled out from day one. In addition, firewall on Windows laptop was also disabled.

EIM-NAT (not full cone) is used in SP network CGNAT boxes, at least on SP networks that are well-informed on the pros/cons of CGNAT/NAT etc. I operate SP networks and we deploy EIM-NAT on the CGNAT boxes. Customers are happy, we're happy.

MikroTik's UDP-only EIM-NAT seems to work partially, at least for SIP and similar. However, gamer customers still report they see "moderate NAT" on Xbox and not open. If we use Juniper or Cisco for CGNAT boxes, customers report "open NAT".
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: FEATURE REQUEST: full cone NAT

Fri Feb 16, 2024 11:11 pm

...
However, gamer customers still report they see "moderate NAT" on Xbox and not open.
...
If they have a forward accept rule for UDP traffic from WAN to LAN, or no firewall rules at all, and the two needed EIM / EIF rules in NAT then they should get open NAT.

I did test on 7.14RC1. Some enhancements have been done around 7.11 if i'm right.

Are you using pure Ethernet or a L2 or L3 tunnel for connection to the clients ?

When i test NAT on my public IPv4 IP delivered through an IPIPv6 MAP-E tunnel on my RB5009, i cannot get full cone to work. I can't say for sure actually if it's a provider filtering, or a Mikrotik IPIPv6 tunnel problem.
 
FIPTech
Long time Member
Long time Member
Posts: 558
Joined: Tue Dec 22, 2009 1:53 am

Re: FEATURE REQUEST: full cone NAT

Sat Feb 24, 2024 10:43 pm

The only other tool I know of is Xbox networking app. Run the network tests, it'll show you the correct results.
There is another tool that seems quite complete : punch-check.

https://github.com/delthas/punch-check
RFC 4787 defines several NAT properties and which are needed for hole-punching support. Those properties which are checked by this tool are:

port mapping: either endpoint-independent, address-dependent, or address and port-dependent
filtering: either endpoint-independent, address-dependent, or address and port-dependent
hairpinning: supported or unsupported
port assignment: may be contiguous, preserving, and parity-preserving
It gives hairpinning support and port assignment informations, something that NatType tester do not gives.


The RFC 4787 reading probably gives a clear view of the quite complex UDP NAT subject.

https://datatracker.ietf.org/doc/html/rfc4787

Definitely those older terms are not precise enough :
STUN [RFC3489] used the terms "Full Cone", "Restricted Cone", "Port
Restricted Cone", and "Symmetric" to refer to different variations of
NATs applicable to UDP only. Unfortunately, this terminology has
been the source of much confusion, as it has proven inadequate at
describing real-life NAT behavior. This specification therefore
refers to specific individual NAT behaviors instead of using the
Cone/Symmetric terminology.
And some other interesting readings about the subject :

https://bford.info/pub/net/p2pnat/
https://datatracker.ietf.org/doc/html/d ... results-01

Who is online

Users browsing this forum: JDF and 17 guests