FEATURE REQUEST: full cone NAT

kcarhc · 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 · Mon Aug 17, 2020 8:20 pm

deploy ipv6 and free of headache

kiler129 · Tue Aug 18, 2020 2:00 am

deploy ipv6 and free of headache

Plenty of ISPs don't offer IPv6 (sadly).

Sob · 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 · 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 · 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.

kiler129 · 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 · 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 · 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 · 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.

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 · 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.

mrz · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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

anav · 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 )

Larsa · 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.

Znevna · Tue Feb 14, 2023 2:23 pm

Which manufacturer has this implemented and how does it work exactly?

Larsa · 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 · 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.

Larsa · 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).

kcarhc · 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

anav · Tue Feb 14, 2023 4:48 pm

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

guipoletto · 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

Larsa · 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.

mrz · 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 · 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).

mrz · 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.

anav · 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

Znevna · 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 · 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 · 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 · 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?

anav · 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.

Znevna · 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?

Larsa · 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.

Znevna · Tue Feb 14, 2023 10:38 pm

That "short and concise answer" doesn't apply to current discussion.

kcarhc · 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 · 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.

Znevna · 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.

Larsa · 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.

Znevna · 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 · 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)

anav · Wed Feb 15, 2023 2:51 pm

Assuming the pretty pictures above are accurate.......
Q remains.....can RoS accomplish same?

Larsa · 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 · 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.

Larsa · 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.

Sob · 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

).

Larsa · 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 · 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.

Larsa · 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 · 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.

Larsa · 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! ;- )

anav · 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 · 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.

Larsa · 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 · 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 · 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 · 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 · 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 · 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."

Larsa · 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 · 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.

Larsa · 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.

anav · 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................

Larsa · 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?

anav · 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 · 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.

Znevna · 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 · 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.

Larsa · 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 · 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...).

Znevna · 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.

mrz · 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 · 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 · 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.

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 · 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.

mrz · 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.

mrz · 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 · 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).

mrz · 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.

Znevna · 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.

Znevna · 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?

mrz · Fri Feb 17, 2023 1:04 pm

We can implement it and maybe call it "tetrahedron nat" to avoid confusion.

Amm0 · 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?

anav · 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................

Znevna · Fri Feb 17, 2023 2:49 pm

[...] but as an MT homeowner [...]

You wrote lawn mower wrong.

kcarhc · 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 · 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 · Fri Feb 17, 2023 3:42 pm

here is fullcone NAT from cisco and juniper

https://www.cisco.com/c/en/us/support/d ... er-co.html
https://www.juniper.net/documentation/s ... guring.pdf

Amm0 · Fri Feb 17, 2023 4:16 pm

I'm just thinking this can be solved with the right netmap action in the NAT.

Znevna · Fri Feb 17, 2023 4:50 pm

here is fullcone NAT from cisco and juniper

https://www.cisco.com/c/en/us/support/d ... er-co.html
https://www.juniper.net/documentation/s ... guring.pdf

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.

mrz · 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 · 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.

Znevna · 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 · 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.

Znevna · Fri Feb 17, 2023 6:12 pm

There's no standard describing that behaviour, can you link to any?

marekm · 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).

Larsa · Fri Feb 17, 2023 6:32 pm

Aha, looking for some kind of automatic NAT feature!

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!

pe1chl · 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!".

Amm0 · Fri Feb 17, 2023 6:51 pm

You are most welcome!

¡Bonjour!

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.

Znevna · 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?

Larsa · 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 · 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).

Znevna · 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 · 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 · 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).

Znevna · 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.

Amm0 · Fri Feb 17, 2023 9:18 pm

Well, perhaps in keeping with the style, action="tetrahedron-nat"
Perhaps "unmasqed-masquerade"?

Sob · 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 · 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.

Larsa · 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 · 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.

Amm0 · 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?

Larsa · 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!

Larsa · 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.

Amm0 · 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

Larsa · 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? ;- )

Amm0 · 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 · 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.

Amm0 · 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 · 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 · 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.

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 · 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 · 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.

Znevna · 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

Larsa · Sat Feb 18, 2023 1:14 pm

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

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 :- )

pe1chl · 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.

Znevna · 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."

pe1chl · 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.

Znevna · 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.

Larsa · 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!

Znevna · Sat Feb 18, 2023 3:05 pm

Tetrahedron ftw.

pe1chl · 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?

Znevna · 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 · 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 · 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.

Larsa · Sat Feb 18, 2023 4:58 pm

Amen to that!

anav · 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 )

Sat Feb 18, 2023 5:57 pm

I vote 6...

Amm0 · 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 · 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 · 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 · 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!

Amm0 · 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)

Larsa · 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 · 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 · 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.

Larsa · 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 · 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 · 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.

Znevna · 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:
Code: Select all
/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 · 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

Znevna · 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 · 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.

Znevna · 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 · 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.

Znevna · 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 · Sun Feb 19, 2023 12:35 am

Code: Select all
/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.

DarkNate · 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:
Code: Select all
/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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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 · 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:

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.

Znevna · 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 · 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.

Znevna · Sun Feb 19, 2023 2:50 pm

We can already use that without switching to netmap.
So, what are you screaming about in here?

mrz · 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 · 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 · 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 · 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).

mrz · 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.

anav · 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.

Larsa · 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.

anav · 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 · 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 · 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 · 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 · 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

Amm0 · 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?

[ 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 ]

anav · Tue Feb 21, 2023 10:22 pm

LIKED: "Avoid masquerade like covid"

Znevna · 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.

Larsa · 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 · 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.

Larsa · 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.

anav · 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 · 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".