Unfortunately the war is not over. Because very few experts as those in this thread are vendor-agnostic, most of them have their network engineering skills foundation based on vendor ABC, can be Cisco, Juniper, Arista, or yes even MikroTik.
Vendor-agnostic network engineers who can see the depths of the various options, protocols, and parameters available and use those correctly to ensure a packet goes from A to B with minimal impact to QoS/QoE and P2P (in the case of NAT) are rare and usually limited to Linux networking-heavy folks, which is an even rarer subset of competent network engineers.
Fundamentally, computer network is a branch of computer science, but most experts lack computer knowledge, very few “network engineers” even have a degree in computer science or similar. Try asking them what’s sk_buff and why both NATting and packet filtering should occur before sk_buff.
I’m no self-proclaimed expert, never said that any this forum ever. But I work with people who have 30+ years of well decorated careers in network engineering, and they can also be found on Wikipedia (no cap), and they certainly don’t act like the experts in this thread and can easily answer what’s sk_buff.
Well I agree. Though I was speaking more generally. You can find a lot of misinformation on this forum or similar forums all over the internet. Nobody reads 2023 networking fundamental books and assume everything from 1980 is still relevant today like classful addressing for example. Like look at the state of IRR lol, what a joke, a /24 defined in 100 DBs. Good luck with RPKI.
Regardless, I like that MikroTik mostly, doesn’t implement dumb features like mDNS repeater or crappy NAT logic like that Russian BisonRouter product.
But MikroTik needs to dump iptables and allow nftables for newbies and expose XDP at ASIC/hardware level for advanced users.
@DarkNet, you missed my point for the third time and seem to focus more on your own thoughts instead of responding with a focus on the arguments. You are also changing direction of the conversation with new and irrelevant facts (whataboutism) but never mind.
As for “your migration”, you’ve convinced me even more that you have absolutely no idea or experience for that matter on how to deal with a large install base (since are probably a skilled hobbyist).
For OpenWrt to see something like this it would mean that it has to exist in upstream netfilter (iptables in OpenWrt < 22.03 or nftables in OpenWrt ≥ 22.03), and there’s no such thing.
So no, from that list, OpenWrt for sure doesn’t have something called ‘Full Cone Nat’ or ‘Tetrahedron NAT’ or ‘DarkNATe BCP as of 2023 because I exchange letters with a bunch of experts but I’m no expert but you’re all idiots if you don’t agree with me’.
Please, let’s not turn this discussion into a flame war about 50 shapes of NAT.
It would be good to review the NAT implementation for compliance with RFCs listed under https://www.rfc-editor.org/info/bcp127 .
BCP stands for Best Current Practices. BCP 127 is mainly about UDP, see also:
BCP 142, RFC 5382, NAT Behavioral Requirements for TCP, October 2008
BCP 148, RFC 5508, NAT Behavioral Requirements for ICMP, April 2009
Hate to necro post (~1 month old not that bad) but I can clarify the need for full cone /endpoint independent NAT and connection tracking. It has to do with NAT traversal techniques and the ability to open a port up by generating an outbound connection and re-use that IP:port mapping from any other host. It works very closely with STUN techniques. Essentially the desired behavior is that a host behind a NAT router (MikroTik) opens a connection to the Internet to a server (STUN?) and that public IP:port mapping is recorded and then communicated to other hosts on other LANs behind other NAT routers to communicate to this host. Essentially allowing NAT traversal and direct TCP/UDP connectivity host to host.
As an implementor ourselves working at the kernel level on other products we have built a well-defined request to Mikrotik in July 2020 via request SUP-20798 which was abandoned and then closed without our acknowledgement. I strongly recommend folks who want this feature reach out to MikroTik and reference SUP-20798 if they care about this feature.
Um, no? Or at least that’s not the behaviour described/wanted in this topic, the bold part in specific.
And without knowing what SUP-20798 contains, nobody will reference it.
To clarify, the recording and communication of the opened IP/port isn’t the feature being requested. The allowing of any remote IP l/source port to connect to the opened IP and port is the feature. Hence “endpoint independent”.
Suit yourself on not referencing that ticket. It’s the feature discussed here and one of the primary capabilities missing from the MikroTik NAT/firewall implementation that separate it from a true CGN appliance.
Unless they properly support TCP/UDP both, and heck maybe all layer 4 protocols (DCCP, UDP-Lite, SCTP etc) – I would not use this half-baked full cone NAT option of MikroTik, sticking to netmap is better, at least I know it works with all protocols without having to think twice.
So let me get this straight, by using my Nintendo Switch as an example (playing Splatoon 3 or whatever).
Does this mean if I set up Endpoint-Independent NAT that, when my Switch initiates an outbound connection using SRC Port 54809 as example here, any other console can now connect to the same port, just like if it was manually setup as dstnat rule by me, automatically? (Even if my console has not initated a connection to the other consoles yet)
That’s what I get from here. In all honesty that would be a godsend to anyone playing on the Nintendo Switch. Hope the beta is released soon so i can test
On Nintendo Switch from what i can tell, a TCP connection is established to the matchmaking server, and the same port is then used to connect to each other consoles using UDP. This isn’t such a big problem, but i can imagine that it wont work with the port randomization feature they implemented for Endpoint Independent Mapping.
