Don't use this as source as it outdated and not maintained
Source:https://blog.apnic.net/2021/06/24/how-t ... imization/

使用this as source as it is maintained by the author
Credits:https://www.daryllswer.com/edge-router- ... -for-isps/

This is amazing

I'm not the author. Give them the shout out.

I love how the article labels the RoS version 6 kernel asANCIENT:-))

I love how the article labels the RoS version 6 kernel asANCIENT:-))

Everybody knows it is. Check the current mainline versions and compare it.

Yes, isancientwith no doubt.

6.x use the 3.3.5 May 2012

7.1beta6 use the 5.6.3 Jun 2020

8 years are one abyss on technology...


Ask moderators/staff to pin this topic

Ask moderators/staff to pin this topic

I don't know how to reach them? You can ask them to pin it if you want to.

Done, I hope someone reply.

Done, I hope someone reply.

Yeah.

You right, but i do not understand why some basic settings are not set as default like rp-filter=loose instead of no, permit blank/not strong password, still use "admin", just for example.
I hope 7 on new kernel work faster and stronger.

Well, thanks moderatos/staff to pin this topic.

BUMP

FYI, Author is regularly optimizing guide. And there's some recent updates in there for Route loop prevention that all networks seem to have. Check out his blog

https://www.daryllswer.com/edge-router- ... -for-isps/

Very amazing, indeed.

Time Bump.

The author is still updating and maintaining the article as of 2023.

Questions.
Q1: Is the connection tracking tables value useful for my home router CCR1009 setup?

Q2. Should I ask my ISP what is the largest size of MTU they are providing.

Q3. Should I be maximizing my L2 MTU value on all devices in the house or more clearly, find the largest common value amongst devices and use that.

Q3. In contrast it appears I should attempt to set the max L3 MTU values on devices regardless of what others do (APs, switches, routers).

Q4. Assume the bogon table minus own subnets and own WANIPs involved and of course loopback 127........ is also applicable on home router.

Q5. Talking mss clamping and wireguard, when dealing with third party vendors. Is this what the author means by let the router do it, in an automated fashion vice set any specific numbers?? I know we are talking apples and oranges as this is not ppp.
/ip firewall mangle
add action=change-mss chain=forward comment="Clamp MSS to PMTU for Outgoing packets"new-mss=clamp-to-pmtuout-interface=wireguard1 passthrough=yes protocol=tcp tcp-flags=syn

Q7. Is there any application for home router for these config settings.....
interface bridge
add arp=disabled comment="For Static Loop Protection" mtu=1500 name=loopback_1 protocol-mode=none
/ip address
add address=192.168.0.1/31 comment="For Static Loop Protection" interface=loopback_1 network=192.168.0.0
/ip firewall nat
add action=dst-nat chain=dstnat comment="Static Loop Protection" dst-address=103.176.189.0/25 to-addresses=192.168.0.1

Realizing fully the answers may all be --> doesnt apply move on!

Conn_track values is for everybody, every host, every device, the world.

WAN MTU should be capped to 1500 at home. I've never heard of an ISP that can carry jumbo frames inter-AS for residential.

Largest possible MTU on LAN everywhere is fine, as long as L3 MTU matches on all routers, switches, whatever. The bridge will auto select smallest MTU like 2290 on MikroTik Wireless APs.

The RFC6890 route to black hole is applicable for every network device excluding hosts.

TCP MSS clamping is never required in a properly implemented set up i.e. proper MTU end to end. I never needed it for WireGuard or anything else.

No, you don't need that bridge loop prevention in a home environment.

THanks, in another thread you noted to use two raw rules to stop private IPs from leaking in or out of a routerwhen using NAT.
Is this a replacement for bogon rules or an addition to? I have used bogon rules but prefer doing so in ip routes - blackhole.

Please explain, what is the meaning of such a MTU replacement? The final (home) users will still be 1500. For example, to install 9000 on the server, NAS and switch, through which you will do backup, I still understand. And just change on all devices - I don’t understand what the point is.

THanks, in another thread you noted to use two raw rules to stop private IPs from leaking in or out of a routerwhen using NAT.
Is this a replacement for bogon rules or an addition to? I have used bogon rules but prefer doing so in ip routes - blackhole.

I don't remember what you mean. The blackhole routes stop loops aka packets destined towards unused RFC6890 space. The RAW rules prevent NAT related exploits like NAT Slipstreaming etc, using RAW.

Please explain, what is the meaning of such a MTU replacement? The final (home) users will still be 1500. For example, to install 9000 on the server, NAS and switch, through which you will do backup, I still understand. And just change on all devices - I don’t understand what the point is.

You need to do your own study on TCP Windowing, TCP tuning and Jumbo frames, why, when and where. I'm not going to teach 10+ years worth of knowledge into a random forum post.

Try this:
https://www.ietf.org/proceedings/82/slides/grow-2.pdf

The Edge router article is generally not meant for home users, it is meant for ISPs. Though you can use some parts of it at home.

If you are an ISP then you should understand why we deploy jumbo frames in the backbone, for MPLS/VPLS, MACSec, VXLAN and L2 transport services for our customers.

THanks, in another thread you noted to use two raw rules to stop private IPs from leaking in or out of a routerwhen using NAT.
Is this a replacement for bogon rules or an addition to? I have used bogon rules but prefer doing so in ip routes - blackhole.

I don't remember what you mean. The blackhole routes stop loops aka packets destined towards unused RFC6890 space. The RAW rules prevent NAT related exploits like NAT Slipstreaming etc, using RAW.

/ip firewall raw
add action=drop chain=prerouting comment="defconf: drop non global from WAN" src-address-list=not_global_ipv4 in-interface-list=WAN
add action=drop chain=prerouting comment="not LAN" src-address-list=!lan_subnets in-interface-list=LAN

I imagine your not_global_ipv4 is the BOGON list correct? So stating drop any incoming private IPs etc. trying to reach the router!
Whereas the second rule says dont allow any LANIP outbound that is not a bonafide subnet on the local router.

No you nailed it, There is overlap. It would appear that your second rule and the blackhole are similar enough. Your rule is more definitive in that it will drop private subnets that one normally excludes on bogons because the local subnets are included in the wide swath approach of bogons.

Other than that what do you see as pluses or minuses of your rule 2 vs bogon and blackhole?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I dont mean to be silly by why is your first rule not...........as precise as the second rule........??
add action=drop chain=prerouting comment="defconf:drop private IPs from WAN" src-address-list=!lan_subnetsin-interface-list=WAN

Now I understand where my logic failed......

There is a substantial difference between blocking in RAW packets leaving the LAN that are not from LAN subnets existing on the router.
and RBH which is predicated on removing any traffic from the LAN to private IP addresses ( or non-valid public IPs ).

So My takeaway is that all three are distinct and useful!

First raw rule stops any incoming (private IPs or not legitimate Public IPs) on the WAN.
Second raw rule stops any outgoing traffic FROM any IPs not on the router --> based onSOURCE IPoutbound
私人IPs RBH规则停止任何输出流量or not legitimate Public IPs) --> based onDESTINATION IPoutbound.

One clarification needed:

add action=drop chain=prerouting comment="not LAN" src-address-list=!lan_subnets in-interface-list=LAN

On the second raw rule above, why do you have source-address-list=!lan_subnets in-interface-list=LAN and not

add action=drop chain=prerouting comment="not LAN"src-address-type=!localin-interface-list=LAN

(只是想消除潜在的损失ng address list of subnets )

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
After thinking about it, I think I see why you have the list method.................
Due to the fact that remote users coming in VPN will be coming from non-local interfaces and their return traffic needs not to be blocked.
Using !local will catch them and block them (bad) whereas in your list approach they can be included in the list and thus excluded from the blocking (desired).

Also can you confirm what you mean by this statement:"src-address-list=not_global_ipv4", more specifically is that fancy way of saying BOGONs or is it a different list ????

That address list is just RFC6890. IPv4 is already exhausted eons ago, RFC6890 is the ONLY bogon in IPv4.

IPv6 is a complex and different story, that's not covered in the OP's blog post. You'll need to search for other sources regarding IPv6.

iptables src and dst address types have special meanings that isn't suitable for public consumption unless they are expertly or advanced well versed in Linux networking, that's basically 1% of the human population. I personally wouldn't use those parameters in production. At home, okay sure if it's my home.

So your saying the only entry on your ADDRESS LIST is 192.0.0.0/24 ?

AND these are no longer valid to put on that source address list to block incoming 'bad' incoming on WAN?

Netblock Description
0.0.0.0/8 "This" network
10.0.0.0/8 Private-use networks
100.64.0.0/10 Carrier-grade NAT
127.0.0.0/8 Loopback{ removed for black hole }
127.0.53.53 Name collision occurrence
169.254.0.0/16 Link local
172.16.0.0/12 Private-use networks
192.0.0.0/24IETF协议分配{ still valid }
192.0.2.0/24 TEST-NET-1
192.168.0.0/16Private-use networks { removed for black hole }
198.18.0.0/15 Network interconnect device benchmark testing
198.51.100.0/24 TEST-NET-2
203.0.113.0/24 TEST-NET-3
224.0.0.0/4Multicast { removed for black hole }
240.0.0.0/4 Reserved for future use
255.255.255.255/32Limited broadcast { removed for black hole }

The bogons problem is overstated,
you simply have to block what comes from outside that has the same IPs you have inside...
For example, if you don't use 10.x.x.x/8, the packet is dropped regardless (because the router doesn't know where to deliver it) whether it gets stuck in the firewall or not...

Often some ISP already block on transit spoofed or leaked packets, so after some months you never receive packet with that address...

Indeed, usually the attacks always come from real, really assigned IPs, who don't give a damn what you have as "bogons" or not...

Good, like the practical thinking!!

So Darknates first rule should be the same as his second rule (in terms of list of local subnets)

原始规则1块从广域网与SUBNE相同TS ON ROUTER(instead of bogon list)
RAW RULE 2 BLOCK ANYTHING NOT FROM LOCAL SUBNETS COMING FROM LAN

So no reason to blackhole any traffic then????

Please keep it civil, disagreements/discussions regarding approaches or interpretations of networking concepts are fine, but there should be no personal attacks.

I am stiill waiting for a response on Blackhole.
Its clearly an accessible option on the routes menu.

Rextended succintly pointed out its not worth it in most cases, perhaps he meant the home user.
I was hoping darknate could explain why its used in business or if not really applicable there either.

Understanding why its used would help me decide whether or not to use the functionality.

@anav
Simply answering, and this goes for any use,
the blackhole is better because the packet just disappears without a trace OR consequences of it being gone.
Routing decision happen before firewall filter (not RAW) drop the packet,
and since, whether the firewall filter (not RAW) blocks it or not, the packet still goes through routing, it is discarded first.

Otherwise letting the packet "expire" causes (unless it can be disabled) the router to notify the host from which the packet came,
which could also be fake, the notification that the packet has "expired", generating in the event of a targeted attack responses that contribute to DDoS.


What does that have to do with "bogons"?
The incoming packet from WAN that has a private IP of a subnet as its destination IP is obviously fraudulent,
and I wonder how it gets there, because how can the ISP route packets with private IP destinations to you?
It would mean that the ISP has in their routing tables that, for example, 192.168.88.0/24 is on your LAN...

Instead, if the packet is destined to IP of your WAN, but has as source one IP among the private ones (or public, but internal),
it is obvious that it is false (and a true ISP should have already filtered them before...)
所以因为坍塌中只影响到目的地,and not the source, of a packet,
the blackhole only prevents YOUR devices from sending attacks to the internet (when used IPs outside your LAN),
not to defend you against them.

If your ISP already do not do that, for drop incoming from WAN packet from bogon IPs,
you can drop it on firewall RAW, on Routnig Rules or on firewall filters.

Seems pretty simple to me.......... and not the biggest ask in the world.

Two simple rules:
1a) Do not accept packets from the WAN that have as source the IPs that are used internally,
even the public ones if the ISP has assigned them to you more than one.
1b) If the ISP doesn't do its job, block all packets from the WAN that target the private IPs you use on your network.

2) Do not allow your router to send packets across the WAN that have
as their source {any private IP} or {public IP addresses that you DO NOT have in your network}.

Obviously, if the ISP only gives private IPs and does everything with a large NAT,this must be taken into account为了不self-block the connection...

So there is alignment on
原始规则1块从广域网与SUBNE相同TS ON ROUTER
RAW RULE 2 BLOCK ANYhTING FROM WAN WITH DESTINATION OF PRIVATE SUBNETS
RAW RULE 2 BLOCK ANYTHING NOT FROM LOCAL SUBNETS COMING FROM LAN.

No IP Routes with black hole make sense in home setting or SOHO setting.

/ip firewall raw
add action=drop chain=prerouting in-interface-list=WAN src-address-list=LOCALsubnets
add action=drop chain=prerouting in-interface-list=WAN dst-address-list=LOCALsubnets
add action=drop chain=prerouting in-interface-list=LAN src-address-list=!LOCALsubnets

Note:CautionLast rule does not interfere with remote subnets coming in on wireguard tunnel (with wireguard often being a member of the LAN List, and thus after being deposited on the LAN (exit the tunnel), the raw rule might disappear any attempt to reach local lan resources or even the WAN!

Not only local subnets, consider also your WAN IP (how is possible to receive one packet with your own IP?...) and the other public IPs you have (if you have any).
Also from internal subnets can't come your WAN IP...

The first one no clue how to formulat a rule, beyond my scope or understanding
The second one,,,,,,,,,,, I think your saying..

添加链= prerouting action = in-interface-list下降=LAN dst-address=WANIP ???

but we dst-address WANIP for dstnat rules???

I use on default "unreachable" on CPEs, if some interface have some IPs on that range, count more than the unreachable...
(for prevent spoofed traffic or errors go outside), the other controls of incoming packet source are on edge router, and control of packet from CPE are on separate firewall, out of normal client scope.

With this the internal LAN device receive ICMP "host unreachable" when try to contact those networks.
As wroted before, if you have 192.168.88.1/24 on one interface, automatically a route with distance=0 is added for 192.168.88.0/24 and all 192.168.88.0/24 block work correctly.Never put unreachable on WAN direction to not amplify or contribute to DDoS attacks...

When I use blackhole:
On incoming connection to "public.example.ip.254" if for some reason that device is offline, I drop instantly the traffic with blackhole, but never send back unreachable for the same reason I write before.
For example, if your ISP assign to your WAN 8 IPs, but you use only 2, is better put on blackole all is directed to that 6 IPs with no reply.

For example:

example code

/ip firewall address-list add list=unexpected-address-source-from-ISP address=10.0.0.0/8 add list=unexpected-address-source-from-ISP address=127.0.0.0/8 add list=unexpected-address-source-from-ISP address=169.254.0.0/16 add list=unexpected-address-source-from-ISP address=172.16.0.0/12 add list=unexpected-address-source-from-ISP address=192.0.0.0/24 add list=unexpected-address-source-from-ISP address=192.0.2.0/24 add list=unexpected-address-source-from-ISP address=192.88.99.0/24 add list=unexpected-address-source-from-ISP address=192.168.0.0/16 add list=unexpected-address-source-from-ISP address=198.18.0.0/15 add list=unexpected-address-source-from-ISP address=198.51.100.0/24 add list=unexpected-address-source-from-ISP address=203.0.113.0/24 add list=unexpected-address-source-from-ISP address=233.252.0.0/24 add list=unexpected-address-source-from-ISP address=240.0.0.0/5 add list=unexpected-address-source-from-ISP address=248.0.0.0/6 add list=unexpected-address-source-from-ISP address=252.0.0.0/7 add list=unexpected-address-source-from-ISP address=254.0.0.0/8 add list=unexpected-address-source-from-ISP address=my.public.wan.ip add list=unexpected-address-source-from-ISP address=pool.of.my.internal.public.ips add list=expected-adress-dst-from-ISP address=my.public.wan.ip add list=expected-adress-dst-from-ISP address=pool.of.my.internal.public.ips add list=expected-adress-from-LAN address=one.of.my.internal.public.ips add list=expected-adress-from-LAN address=another.of.my.internal.public.ips add list=expected-adress-from-LAN address=192.168.88.0/24 add list=expected-adress-from-LAN address=0.0.0.0 comment="Current network" add list=expected-adress-from-LAN address=224.0.0.0/4 comment=Multicast add list=expected-adress-from-LAN address=255.255.255.255 comment="Local Broadcast" /ip firewall raw add action=drop chain=prerouting in-interface=pppoe src-address-list=unexpected-address-source-from-ISP add action=drop chain=prerouting in-interface=pppoe dst-address-list=!expected-adress-dst-from-ISP add action=drop chain=prerouting in-interface=bri-lan src-address-list=!expected-adress-from-LAN /ip route add distance=1 dst-address=10.0.0.0/8 type=unreachable add distance=1 dst-address=169.254.0.0/16 type=unreachable add distance=1 dst-address=172.16.0.0/12 type=unreachable add distance=1 dst-address=192.0.0.0/24 type=unreachable add distance=1 dst-address=192.0.2.0/24 type=unreachable add distance=1 dst-address=192.88.99.0/24 type=unreachable add distance=1 dst-address=192.168.0.0/16 type=unreachable add distance=1 dst-address=198.18.0.0/15 type=unreachable add distance=1 dst-address=198.51.100.0/24 type=unreachable add distance=1 dst-address=203.0.113.0/24 type=unreachable add distance=1 dst-address=233.252.0.0/24 type=unreachable add distance=1 dst-address=240.0.0.0/5 type=unreachable add distance=1 dst-address=248.0.0.0/6 type=unreachable add distance=1 dst-address=252.0.0.0/7 type=unreachable add distance=1 dst-address=254.0.0.0/8 type=unreachable add distance=2 dst-address=my.unused.public.ip1 type=blackhole add distance=2 dst-address=my.unused.public.ip2 type=blackhole add distance=2 dst-address=my.unused.public.ip3 type=blackhole add distance=2 dst-address=my.unused.public.ip4 type=blackhole add distance=2 dst-address=my.unused.public.ip5 type=blackhole add distance=2 dst-address=my.unused.public.ip6 type=blackhole

For sure I forget something, but this is the example.

Your router must be a very powerful device to check all of these lists of rules or routes... this is the shortest path to choke your hardware. Isn't there any better way to do it?

Your router must be a very powerful device to check all of these lists of rules or routes... this is the shortest path to choke your hardware. Isn't there any better way to do it?

The CPEs I use for my clients don't even notice it, and the rules are not heavy.
You wrote an exaggeration.

Your router must be a very powerful device to check all of these lists of rules or routes... this is the shortest path to choke your hardware. Isn't there any better way to do it?

PROVE IT, or take your baseless comments elswhere [moderator intervention]

This idiot is clearly trolling us here.

This time ... 2 weeks of vacation

but to be fair ... Anav ... please DO NOT "tease" people ... your post also removed.

to be fair, there would have been none if the causing post had been removed earlier, but concur you cannot be everywhere at once.............. I did resist though in both delaying response and the flavour of response, so am trying

OMG, this is absolutely incredible!

Thanks! I'll be sure to check this out!

OMG, this is absolutely incredible!

Thanks! I'll be sure to check this out!

TAG: ###RCHCK### both....

What the hell happened here? Looks like bots or something.

What the hell happened here? Looks like bots or something.

Exactly, is why is present ###RCHCK###
I monitor both posts/users when they edit them to add spam, at which point is the time to ban the user and delete the post.

I'd like to get some further clarification on a couple of topics

RP-Filtering. Can someone explain how loose mode is in any way different to 'none' when a default route exists in the table?
From what i've read, MikroTik does consider a default route when performing reverse path lookup. Hence every IP will be valid and thus it seems to me to be completely pointless on anything other than a router running the full BGP table and no default route installed. What am I missing?

Netmap. This is the first time i've seen an example of it being used with mismatched subnet sizes, in the article these 2 rules do not make sense to meThe way i've used Netmap in the past is to effectively re-write the first 3 octets of an IP range, i.e. 100.70.5.77 i'm going to rewrite as 192.168.1.77 in order to reach the entire /24 subnet inside a customers network by using '100.70.5.x' instead of having to use a VPN or setup a bunch of port forwards (yes, obviously secured and firewalled appropriately, not allowed by the internet etc)
In the case of the above rules in the article, the way i'm reading it is 103.176.189.[0-127] is going to map to 100.64.0.[0-127] and thats it, clearly i'm missing a lot of this picture and I havn't been able to find an answer just looking online

I don't understand how the rule works and how it applies. If 100.64.0.129 (outside of the netmap range of public IP's) goes out the internet (I presume with a src-nat rule) then how does the netmap rule apply here? I presume the intention is that i.e. 100.64.0.129 goes to the internet, the srcnat rule has picked i.e. 103.176.189.5 with a source port of 443, and then somehow this netmap rule does a connection tracking lookup to see that port 443 was mapped to 100.64.0.129, thus all incoming traffic to 103.176.189.5:443 (ignoring the source IP from the direction of traffic coming 'in' from the internet) gets mapped back to 103.176.189.5
Effectively setting up a dynamic port forward, the same as if I manually created that rule
But this raises other questions, if thats how it works and an IP mapping effectively gets dynamically created in memory, then for how long and with what criteria? Is that until the router reboots? Until all connections on that port have timed out? I just don't understand how it works

I'd like to get some further clarification on a couple of topics

RP-Filtering. Can someone explain how loose mode is in any way different to 'none' when a default route exists in the table?
From what i've read, MikroTik does consider a default route when performing reverse path lookup. Hence every IP will be valid and thus it seems to me to be completely pointless on anything other than a router running the full BGP table and no default route installed. What am I missing?

The way i've used Netmap in the past is to effectively re-write the first 3 octets of an IP range, i.e. 100.70.5.77 i'm going to rewrite as 192.168.1.77 in order to reach the entire /24 subnet inside a customers network by using '100.70.5.x' instead of having to use a VPN or setup a bunch of port forwards (yes, obviously secured and firewalled appropriately, not allowed by the internet etc)
In the case of the above rules in the article, the way i'm reading it is 103.176.189.[0-127] is going to map to 100.64.0.[0-127] and thats it, clearly i'm missing a lot of this picture and I havn't been able to find an answer just looking online

I don't understand how the rule works and how it applies. If 100.64.0.129 (outside of the netmap range of public IP's) goes out the internet (I presume with a src-nat rule) then how does the netmap rule apply here? I presume the intention is that i.e. 100.64.0.129 goes to the internet, the srcnat rule has picked i.e. 103.176.189.5 with a source port of 443, and then somehow this netmap rule does a connection tracking lookup to see that port 443 was mapped to 100.64.0.129, thus all incoming traffic to 103.176.189.5:443 (ignoring the source IP from the direction of traffic coming 'in' from the internet) gets mapped back to 103.176.189.5
Effectively setting up a dynamic port forward, the same as if I manually created that rule
But this raises other questions, if thats how it works and an IP mapping effectively gets dynamically created in memory, then for how long and with what criteria? Is that until the router reboots? Until all connections on that port have timed out? I just don't understand how it works

Yeah, default route is not going to do much with loose-mode of course, but that's a problem with MikroTik. They should support per-interface configuration for rp-filter, this way loose/strict can be applied properly depending on the routes from/for/to a given interface. This problem is only on MikroTik and similar OSes. On JunOS, we can configure it per interface for full advantage. No need for full tables logic. And even then, we should use feasible uRPF mode, not loose nor strict.

As for netmap, asmany, users on this forums have shared, it works fine for 1:Many if configured correctly, especially in ensuring STUN works without TURN. Last time I read the article, the author shared screenshots of official MikroTik support confirming the netmap logic is good.

You are confusing how port mapping works. MikroTik uses a code logic whereby if 100.64.0.10:1234 traffic comes in towards egress NAT interface, src-nat chain netmap action will map 100.64.0.10:1234 to public:1234. This ensures 1:1 port mapping, eliminating the need for TURN. However, for additional function the author added dst-nat to allow public:1234 back to 100.64.0.10:1234 - How does this work? You need to ask MikroTik as they didn't share the source code. But this implementation is not 100% perfect as it doesn't always map on dst-nat chain for ANY external IP. This is solved in the full cone EIM NAT technology, which right now is broken on MikroTik as it fails to support TCP, but this technology works 100% on Cisco, Juniper.

You are confusing how port mapping works. MikroTik uses a code logic whereby if 100.64.0.10:1234 traffic comes in towards egress NAT interface, src-nat chain netmap action will map 100.64.0.10:1234 to public:1234. This ensures 1:1 port mapping, eliminating the need for TURN. However, for additional function the author added dst-nat to allow public:1234 back to 100.64.0.10:1234 - How does this work? You need to ask MikroTik as they didn't share the source code. But this implementation is not 100% perfect as it doesn't always map on dst-nat chain for ANY external IP. This is solved in the full cone EIM NAT technology, which right now is broken on MikroTik as it fails to support TCP, but this technology works 100% on Cisco, Juniper.

I understand this but what I don't understand is how it actually works in the above example
I would understand if customers have a static CGNAT address that never changes, but I was (perhaps wrongly) assuming that isn't the case, that a customer could have any randomly assigned address in the 100.64.0.0/10 range and still somehow have ports forwarded internally to them. And that somehow the initial outbound connection establishes this relationship
I still do not understand how this actually works in principle. Can you provide some examples? and how for example netmap works if a customer has the CGNAT IP address of 100.64.0.129 which falls beyond the 128 public IP addresses assigned. As again I am assuming netmap does a 1:1 address translation that maps a specific range to another specific range of equal size, so what actually happens when you have an internal IP beyond that mapped range? And is that internal IP taking the entirely of a public IP for all inbound sessions, or is it being divided whereby port 443 might go to .129 but port 80 goes to another customer i.e. .77

I understand this but what I don't understand is how it actually works in the above example
I would understand if customers have a static CGNAT address that never changes, but I was (perhaps wrongly) assuming that isn't the case, that a customer could have any randomly assigned address in the 100.64.0.0/10 range and still somehow have ports forwarded internally to them. And that somehow the initial outbound connection establishes this relationship
I still do not understand how this actually works in principle. Can you provide some examples? and how for example netmap works if a customer has the CGNAT IP address of 100.64.0.129 which falls beyond the 128 public IP addresses assigned. As again I am assuming netmap does a 1:1 address translation that maps a specific range to another specific range of equal size, so what actually happens when you have an internal IP beyond that mapped range? And is that internal IP taking the entirely of a public IP for all inbound sessions, or is it being divided whereby port 443 might go to .129 but port 80 goes to another customer i.e. .77

Dynamic/Static CGNAT IP doesn't matter, the stateful mechanism in addition to the blackhole routes for RFC6890 will ensure previously tracked states of customer 100.64.0.129, where now 100.64.0.129 was for a few seconds inactive, then re-assigned to new customer, are fully cleared from conn_track. You should read up on how conn_track mechanism works in Linux. You are asking a fundamental question, whose answer can be found in various Linux man pages.

netmap in principle is 1:1, but in MikroTik it supports 1:Many, so if a CGNAT IP exceeds public range, the source code will simply randomly choose any of the public IPs and consistently map it to the customer, as long as the customer IP is active, until then conn_track will purge. This ensures STUN and P2P networking will work, no need for apps to fall back to TURN. Whereas if you used src-nat, it will change public IP mapping for every single connection from the customer, therefore breaking P2P, multithreaded TCP, UDP multiplexing etc.

By the way port 0-1023 will never be active, nor configured for CGNAT, they will never be allowed to function as source nor dst port.