<placeholder post for the final version - once ready>

I am in the habit of taking pictures to document the progression of works, so here it is (9 June 2025 8:00 Zulu):

Previous steps (how this idea was born) on another thread, starting from here:
viewtopic.php?t=217249#p1146842

... working on it ...

EDIT: Attached a tentative version.
I tried to align boxes along a grid where rows are Mikrotik configuration sections and columns are Mikrotik configuration actions chains.
Needs to be reviewed accurately, as I may well have made some mistake, as i changed the layout or the original.
Numbering remains the same for the moment (it will be eventually removed unless deemed necessary for some reason) even if a few numbered boxes were removed (12,15,and 19).

Removed, tentative version 2 (actually 3) below.

This is sort of a new take on the usual diagram. I saw some others attempt similar things, but none were really usable - yours actually looks nice. Who knows, maybe it will catch on. Kudos.

The "received by local process" and "emitted by local process" things definitely shouldn't be left out:
* for encapsulations it is often true that the received and emitted packages bear a (mostly) 1:1 relationship and are "some versions" of each other, however they is *not* the same packet
* in many cases for services a sort of 1:1 relationship exists between received and emitted packages, e.g. a DNS request answered, a ping responded to, however these are most definitely not the same packet somehow proceeding though the packet flow
* in many cases the router just emits a packet: e.g. doing an IP address update for DDNS (in this case the instigating event is not even related to some other packet, but it's based on a timer, config change, etc.) or the router wants to make a DNS lookup...

This is just a nitpick, but the triangles to me suggest that there's something happening there. Maybe it's just how I visually process things...

EDIT: I would consider retaining some version of numbering or lettering of the processing steps. I often find myself explaining the steps of the packet flow for a particular scenario in writing, and a clear reference would be very helpful in those cases.

I think I can re-add them (12 and 19) in an added column between "chain=input" and "chain=forward" keeping all the rest of the new layout unchanged.

The triangle Is the standard symbol in flowchart that means "merge", I could remove the filling if that helps in visualization.

Never seen it to be honest. I'm sure you're right. (Maybe it's like the nabla operator, and simply not used in some regions?)

i like this, credits to its creators
maybe can be useful to inspire this new initiative

@chechito:
Yep, I've seen it and it's generally quite good. The general qualms with it:
* doesn't include the Raw chains (to be fair, it may have been created before raw was accessible in RouterOS)
* it omits the nat/input (srcnat) table altogether
* it doesn't show the bypassing of pre- and postrouting nat chains based on addressing

I'm not saying that these are big deals, and I'm sure it's totally fine for teaching purposes (for which it was apparently created.)

2nd (actually 3rd) attempt.

Items re-numbered as follows:

1 Incoming Packet
2 raw PREROUTING
3 Connection (state) tracking
4 mangle PREROUTING
5 Is src addr router's own?
6 mangle INPUT
7 filter INPUT
8 nat (srcnat) INPUT
9 to router's internal process
10 nat (dstnat) Prerouting
11 Routing Lookup
12 Is dst addr router's own?
13 mangle FORWARD
14 filter FORWARD
15 packet generated by router
16 Initial Routing Lookup
17 raw OUTPUT
18 Connection (state) tracking
19 mangle OUTPUT
20 nat (dstnat) OUTPUT
21 Final Routing Lookup
22 filter OUTPUT
23 mangle POSTROUTING
24 Is dst addr router's own?
25 nat (srcnat) POSTROUTING
26 Outgoing Packet

Moved to Excel (which while being a little poorer on the graphic side is easier for managing this kind of stuff, inkscape - possibly my fault - had a couple issues with connectors' arrows and grid snapping).

Attaching a .png, but this can later become the actual Excel spreadsheet or a pdf.
EDIT: file removed see below

I can't comment on the flowchart you posted yet because it has the same problems with some diagrams on help.mikrotik.com, that the transparent background makes the image unreadable in dark mode. My phone web browser automatically converts web pages to dark mode (conserves battery with OLED screens) and black lines and texts on deep dark background are invisible.

IMHO it makes little sense to create an image with transparent background while the important details have fixed colors on that same transparent background. Maybe add at least some contrasting outlines or just make the background white/light colored.

This is not simply a problem specific to browsers with automatic dark mode. When, according to plans, this forum switches to Discourse in the near future, the forum software will offer the users the ability to select dark themes too and your flowchart as of now will become unreadable.

EDIT: And it's also unreadable on my Windows PC in the default Windows Photo Viewer.

No prob, here it is in .pdf (which I doubt will be useful in dark mode)



and in .xls (zipped).


and in png with a beige background.

EDIT: removed files, see below for new version.

Thank you for the files!

I was not aware of #5 and #24 in RouterOS. Does #5 means that if a random device on the network (let's say on the LAN bridge) sends a packet to the router by faking src-address=192.168.88.1 (assuming that's one of the router's addresses) and dst-address=1.2.3.4, dst-port 53, protocol UDP, that packet lands in Mangle Prerouting and then in Filter Input, and then is received by the router's DNS process, even with dst-address being 1.2.3.4?

Ah I see the #5 and #24 branching box are present on this https://stuffphilwrites.com/fw-ids-ipta ... 024-05-22/. However, I think that applies only to locally (on the router) generated packets. That chart has the distinction between "localhost dest" (as well als "localhost src") and "for this host". I think "for this host" is what really matches your "Is dst address router own" of #12 but is not for #24.

And it means "Is src addr own's" should not be equivalent to "localhost src". From the article, I think it means the packet was generated by the router and destined for the router. And not just any packet with one of the router's addresses in the src-address field.

In the original article, this was mentioned in the changelog:

2018-09-01: Reflects that localhost-sourced/destined packets will not traverse the nat table’s PREROUTING/POSTROUTING chains, respectively. Thanks to commenter Binarus for the pointer.

I don't know.

I am only trying to make the IPTABLES flowchart lurker888 posted a link to at the same time more suited to Mikrotik while keeping it readable by IPTABLES experts AND make it understandable to the "masses" AND attempt to organize it visually in such a way that WHERE the settings are is evident (something that is usually not immediate in most flowcharts I have seen).
Invariably you are pointed to one (or the other) and told "it is mostly like this BUT ..."
My hope is that at the end we can have something that you can point people to and say "it is EXACTLY like this..."

The text of points currently numbered as follows is only an attempt, it can be changed current<- lurker888's<-original:
5 Is src addr router's own? <- src addr is router's addr <- localhost source?
12 Is dst addr router's own? <- dst addr is router's addr <- for this host?
24 Is dst addr router's own? <- dst addr is router's addr <- localhost dest?

From the comments down below on that page https://stuffphilwrites.com/2014/09/ipt ... flowchart/ between the commenter Binarus and the author, it was really only about looped-back packets (generated by the router for the router).

Phil Hagen
September 1, 2018 at 6:32 am
Aha – I see what was meant before and I appreciate the input. I’ve updated this to reflect two differences when handling localhost-to-localhost packets. (Note that the nat/POSTROUTING chain is not used for packets destined to localhost either.)

But when you made the change as suggested by others to "match MikroTik terms", the loopback meaning is lost. Because "Is src addr router's own?" only mention the source address of the packet and that can be faked by the sender at will.

For #24 is less critical, because the Yes branch of that box can only be taken by packets generated by the router (those that went through the output chain), and will satisfy the "loopback" condition if the Yes branch, even with your wordings, is hit.

Thanks both of you for highlighting this! These cases are why these diagrams are really hard to make: either go into too much detail and lose your audience or be a bit vague or imprecise. I may have gone too far, and we should come up with clearer phrasing: none is clear to me immediately, but I hope we can come up with something.

Let me try to clarify what's actually happening:
* in decision 5, the check is actually: is the *ingress interface* the loopback
* in decision 12, the check is: is the route chosen in 11 a "local" route (more about this later)
* in decision 24, the same is true with regard to the last routing lookup performed (for any case where this condition is true, the last routing lookup was made in 21)

About "local": the linux routing table may contain a flag "local", as shown in this output produced on a vanilla Ubuntu: The first "local" in the local table listing signifies the flag deciding this decision.

Maybe "packet from router (itself)" or "packet to router (itself)" would be correct?

EDIT: So to be clear, the case of 5 referd to the ingress interface, while the other two refer to a decision that is indeed made based on the dst addr. (mangling and routing rules may influence this)

Maybe "packet from router (itself)" or "packet to router (itself)" would be correct?

I find this better too. And actually the outgoing line from the Yes branch of #24 doesn't need to go down to #26 and can instead loop up to directly enter #2. This would make the "loopback" explicit.

Maybe "packet from router (itself)" or "packet to router (itself)" would be correct?

I find this better too. And actually the outgoing line from the Yes branch of #24 doesn't need to go down to #26 and can instead loop up to directly enter #2. This would make the "loopback" explicit.

Thanks again for highlighting this.

Well, the packet is technically output on the loopback and then received again (Sometimes this matters.)

I think this latter can be solved, I could add a "loopback" box (between 9 and 26) and from it feed it back to 2. That would be something that I would understand much more than either the current go to Outgoing Packet or "direct re-feeding to #2".

What about the exact text for the decisions (remember that it must fit the diamond/rhombus shape, so not too verbose):
5) ...
12) ...
24) ...

Not saying this is the ultimate, but the decisions could be "from router itself" and "to router itself"

Maybe the loopback situation is best represented by a wavy rectangle (like incoming/outgoing packet") labelled "loopback (lo)" in the center, with an incoming arrow from 24 and an outgoing one to 2? With the arrow leaving 24 to the left it would actually fit ok...

I like the presentation here. While the full detail (other than WG) is in Packet Flow diagrams in docs — those are not very understandable to get the "high level" picture from a "configuration perspective" — so showing the "chains vs /ip/firewall/XXX" is pretty cleaver way to do it. But going into too much detail, any diagram is just going to start looking like MikroTik existing one, so think you've capture the right detail here.

I've never found MikroTik "local process" a good term, so the "Is src-address router own?" (or similar wording, "<from/to> router itself") seems more clear than "local process". And that helps separate out the input/output vs forwarding difference better than mikrotik packet flowIMO.

My only grip be do not use same box for the labels – square boxes are historically a "process", so the "chain=input" and "/ip firewall raw" should use some other shape. Perhaps grid lines might help, dunno.

I have to think about the symbol/shape for "loopback (lo)", instinctively It should be different as It Is "pass-through".
Strictly speaking the wavy rectangle Is not standard flowchart the symbols for "begin" and "end" Is the rectangle with rounded ends, same as currently used for 9 and 15. Or I could use the parallelogram for those, which Is symbol for input/output.
For the text, what do you think of:
"to self? (loopback)"
and
"from self? (loopback)"
I'll see if It fits, better would be (IMHO):
"dst addr=self? (loopback)"
and
"src addr=self? (loopback)".
but they seem too long.
Tomorrow I'll see.
@Ammo
You are right, since those are out of the flowchart they can (and should) be different, I'll see if I can make them into "fat" arrows pointing downwards for chains and right for sections.

I am only trying to make the IPTABLES flowchart lurker888 posted a link to at the same time more suited to Mikrotik while keeping it readable by IPTABLES experts AND make it understandable to the "masses" AND attempt to organize it visually in such a way that WHERE the settings are is evident (something that is usually not immediate in most flowcharts I have seen).

Is that "only" what you're trying to do

Easy peazy, no?

Well, speaking as one of "the masses," it's a beautiful job you're doing.

Shouldn't be much of a problem, we just have to be quick about it. I've heard @jaczlaz is on to world hunger starting Wed.

it's a beautiful job you're doing.

Well, let's hope it's not a big, beautiful job, eh?

OK, another version.
New numbers/text:

1 Incoming Packet
2 raw PREROUTING
3 Connection (state) tracking
4 mangle PREROUTING
5 src addr=self? (loopback)
6 mangle INPUT
7 filter INPUT
8 nat (srcnat) INPUT
9 to router's internal process
10 nat (dstnat) Prerouting
11 Routing Lookup
12 dst addr=self? (loopback)
13 mangle FORWARD
14 filter FORWARD
15 packet generated by router
16 Initial Routing Lookup
17 raw OUTPUT
18 Connection (state) tracking
19 mangle OUTPUT
20 nat (dstnat) OUTPUT
21 Final Routing Lookup
22 filter OUTPUT
23 mangle POSTROUTING
24 dst addr=self? (loopback)
25 nat (srcnat) POSTROUTING
26 Loopback interface
27 Outgoing Packet

EDIT:Attachment removed see below for newer version

It would be nice to give some colour to:
a. the "chain=" fat arrows (to differentiate them)
b. Incoming and Outgoing packet (to highlight them)
but I am afraid to make it more confusing.
What about fat arrows white and packets green?
Same goes for the background, the current one (#f4e3d7ff) is a bit too dark, maybe, anyone has a 4 byte code that is pleasant to the eye in both "normal" and "a-b-normal" (dark) mode?
Ideas?

@jaclaz: This is coming out well. (Showing yourself in the trenches in the illustration is spot on).

What points I have left are only minor and consider them nitpicking. (In no particular order):

* On the background color. I think that at least for the default png version legibility should be primary (come on, we all know that will be the one that's going to be viewed the most - people are lazy) For me the current color works in this regard, but I'm sure someone with more experience can come up with something better. For web publishing white with 50% alpha is a common choice - it ensures legibility on all backgrounds. (I know this is not the time for this coming-out, but a looong time ago I used to do publishing quality technical illustrations, so I might have to polish off my toolbox... but whether I do it depends very much on how much free time and beer I have on my hands.)

* With respect to the src-addr/dst-addr thing, especially with the "(loopback)" added, I would be inclined to just put "from self (loopback)" and "to self (loopback)" respecively. I think this is not inaccurate anymore, and with "loopback" added (in both wording and the actual path) there is no confusion anymore, even to the most casual reader.

* I understand not wanting to cross path lines, but I think "loopback" might fit tidily in the middle. Of course this is a matter of aesthetics.

* I would make it clear(er) in the top-left "Mikrotik" that it's the "Mikrotik naming". There's no shortage of space there. (I know this is paranoia, but it occurs to me that someone might think this is actually Mikrotik documentation, when it's documentation *about* Mikrotik.)

* It would be nice to put some sort of date (as a version number) in the title caption of the thing. For now, I would also add something like "beta". Having the date could make the usage of these diagrams mush nicer, should they ever be updated.

* It would also be nice if someone could offer a space in the corner of some webserver for perma-hosting this. This is of course jaclaz's diagram, but if my opinion were to count (hint: it really doesn't), I'd insist on something that is not some arm of a cloud service / non-ad supported / not tracking its users. I might offer such a space but that would actually require installing and configuring a web server...

* As a last potential step - if jaclaz really has the time - I would suggest creating a low-res (web viewing) and high-res version. Also in some situations b&w is strongly preferred. When it's completed, I'd be inclined to use this in printed documentations and there b&w and high-res still dominate.

* I sense that this is not in agreement with the majority opinion here - which is find, thats why it's called the majority opinion. But I'd use the same style box for the loopback as for the incoming/ougoing packet. However not-labeled these things are, they all represent interfaces, and in my time doing illustrations (and also teching) I observed that the "impression" that illustrations convey sometimes sick with people for a surprisingly long time, even when what exactly it is they convey is unclear to them initially. If it were totally up to me, I's actually separate the loopback into two, "to loopback" and "from loopback" places right next to each other, to convey that the packet actually exits netfiler, and then is reinjected. You wouldn't guess from the amount of text I devote to this, but this is a really minor point.

Open to comments and flames. Also, a big thank you to jaclaz for volunteering their effort to put uo with all this.

EDIT: Also, wherever this ends up being hosted, it really should be accompanied by a copyright notice. I usually just say it's fine to reproduce anywhere, but it's jaclaz's product, so obviously the decision rests there. There's also the GNU Free Documentation License (GFDL) and various CC ones.

Also, would you guys think that some sort of walk-through would be useful for the more common cases? (Of course separate from the diagram itself.) I'm thinking of some common scenarios, such as: routing between internal subnets, routing to the internet (srcnat), port forwarding (dstnat), traffic to router services... Some more obscure scenarios might be included like VPN (basically Wireguard), mult-WAN with multiple tables and marking.

Very minor, but eventually, if you use GIF with Alpha channel that might allow better support for dark-mode, to avoid the hideous sand color background.

* On the background color. I think that at least for the default png version legibility should be primary (come on, we all know that will be the one that's going to be viewed the most - people are lazy) For me the current color works in this regard, but I'm sure someone with more experience can come up with something better. For web publishing white with 50% alpha is a common choice - it ensures legibility on all backgrounds. (I know this is not the time for this coming-out, but a looong time ago I used to do publishing quality technical illustrations, so I might have to polish off my toolbox... but whether I do it depends very much on how much free time and beer I have on my hands.)

If "pure white" is OK (even with 50% alpha blend) and people using dark mode won't get a fit by looking at it, I would prefer it, it is how traditionally (after papyrus and parchment) we are used to read things.
But then we need to find a colour for the "fat" arrows at the top that doesn't distract too much from the "important" coloured process steps.

* With respect to the src-addr/dst-addr thing, especially with the "(loopback)" added, I would be inclined to just put "from self (loopback)" and "to self (loopback)" respecively. I think this is not inaccurate anymore, and with "loopback" added (in both wording and the actual path) there is no confusion anymore, even to the most casual reader.

I thought that src addr and dst addr were vital to make it adapted to Mikrotik jargon, let's wait what other people think, in any case I "need" a question mark as it is a question (to which you can answer Y or N) .

* I understand not wanting to cross path lines, but I think "loopback" might fit tidily in the middle. Of course this is a matter of aesthetics.

No, you don't , the whole point is to not cross path lines or use (stupid) on-page connectors. People should be able to use it to play a sort of goose game on it without jumping over this or that.

* I would make it clear(er) in the top-left "Mikrotik" that it's the "Mikrotik naming". There's no shortage of space there. (I know this is paranoia, but it occurs to me that someone might think this is actually Mikrotik documentation, when it's documentation *about* Mikrotik.)

Yep that is not a problem. I wonder if "Mikrotik naming" or "Mikrotik configuration naming" or something else.

* It would be nice to put some sort of date (as a version number) in the title caption of the thing. For now, I would also add something like "beta". Having the date could make the usage of these diagrams mush nicer, should they ever be updated.

Yep, also visually (with my art director hat on) I am not at all satisfied of the central (now pale yellow) box, or of the text in it. I could remove the forum address (and thus make the titles more proportionally evident and the box more adequate to two lines of text) and use the bottom left corner for the forum address, date, version, whatever in smaller characters.

* It would also be nice if someone could offer a space in the corner of some webserver for perma-hosting this. This is of course jaclaz's diagram, but if my opinion were to count (hint: it really doesn't), I'd insist on something that is not some arm of a cloud service / non-ad supported / not tracking its users. I might offer such a space but that would actually require installing and configuring a web server...

Oww, come off it, it is not such a precious resoource that will become viral, the people actually interested in this (all 42 of them) can get it from this thread just fine.

* As a last potential step - if jaclaz really has the time - I would suggest creating a low-res (web viewing) and high-res version. Also in some situations b&w is strongly preferred. When it's completed, I'd be inclined to use this in printed documentations and there b&w and high-res still dominate.

Right now what I am doing is:
1) the actual thingy in Excel
2) print it in A3 with Cutepdf writer (colour, resolution max 1200 dpi, with 2400 artifacts start showing on the right) ->.pdf
3) import the PDF in Inkscape, add on a lower layer a rectangle the same size of the imported .pdf, fill it with a given colour-> export ->.png
Now if I set the virtual printer as B/W, in Print preview the file looks nice and the rendering as shades of gray is actually readable, but the "fat" arrows on the left are coloured (go figure).
Anyway, printing to pdf from the colour Inkscape as B/W it comes out a (readable) B/W pdf. (Attached a copy, same version as in post #25)
EDIT: file removed

The .png (coloured) is around 160 Kb and I believe *any* borowser will resize it automatically to the available window, so the "low-res" version should be avoidable.
And I wouldn't probably be capable of making a hi-res version (or it won't add anything noticeable).
The png should come out around 1600x1100 pixel at 96dpi, so unless one has a 1 megazillion x 4 megazillion pixels graphic card and display it should be suitable 1:1 full screen on many monitors.

* I sense that this is not in agreement with the majority opinion here - which is find, thats why it's called the majority opinion. But I'd use the same style box for the loopback as for the incoming/ougoing packet. However not-labeled these things are, they all represent interfaces, and in my time doing illustrations (and also teching) I observed that the "impression" that illustrations convey sometimes sick with people for a surprisingly long time, even when what exactly it is they convey is unclear to them initially. If it were totally up to me, I's actually separate the loopback into two, "to loopback" and "from loopback" places right next to each other, to convey that the packet actually exits netfiler, and then is reinjected. You wouldn't guess from the amount of text I devote to this, but this is a really minor point.

I don't care about the majority, it is not democracy, but you'll have to defend your opinion in front of the Court (myself) .
https://www.quotes.net/mquote/65590

If an interface has not a RJ45, a SFP socket or an antenna, it is a "different" interface.
In any case NO interface (exception made for the "different" loopback) has been cited (nor harmed) in the making of the diagram, we have Incoming and Outgoing Packets (and that a packet has a different symbol from an interface is a self evident truth).
Now (since it is anyway "different") the idea of dividing the loopback interface in two seems to me a nice one .
Also I would like *somehow* add that this interface is exposed as (lo) in newish RoS.

EDIT: Also, wherever this ends up being hosted, it really should be accompanied by a copyright notice. I usually just say it's fine to reproduce anywhere, but it's jaclaz's product, so obviously the decision rests there. There's also the GNU Free Documentation License (GFDL) and various CC ones.

I tend to use my Careware license for this kind of stuff:
http://jaclaz.altervista.org/Projects/careware.html
(please appreciate the amount of time I spent in creating the above page and my outstanding talent as web designer )

Very minor, but eventually, if you use GIF with Alpha channel that might allow better support for dark-mode, to avoid the hideous sand color background.

I think that png is better in resizing/adapting to various resolutions, and it supports Alpha channel just fine.
The question is what colour (and later which level of Alpha - 50% was suggested but it may be too little or too much, I don't know) will be a suitable compromise for users of both normal and dark modes.

Very minor, but eventually, if you use GIF with Alpha channel that might allow better support for dark-mode, to avoid the hideous sand color background.

I think that png is better in resizing/adapting to various resolutions, and it supports Alpha channel just fine.

I saw PDF here... Not the expert here and don't know tool, but I meant the setting the transparency color, and leave alpha along. 50% look bad in both light and dark mode . Still really minor, just commentary from peanut gallery.

Why not publish plain svg?

I thought that src addr and dst addr were vital to make it adapted to Mikrotik jargon, let's wait what other people think, in any case I "need" a question mark as it is a question (to which you can answer Y or N) .

In this I recant, for it was me that led you astray. No, seriously, this was a simplification gone too far. As I have explained, for the src addr part actually the input interface is inspected, for the dst address part, the appropriate ("local") flag for the route selected is consulted. I think "from self (localhost)" is a statement that can have a question mark appended and be rightly considered to have a Y/N answer. (Or in its statement form has a property of "is this true? (in this case)")

No, you don't , the whole point is to not cross path lines or use (stupid) on-page connectors. People should be able to use it to play a sort of goose game on it without jumping over this or that.

That's exactly what I mean by preferences - we all have our own. With regard to your work you have no one to report to

* I would make it clear(er) in the top-left "Mikrotik" that it's the "Mikrotik naming". There's no shortage of space there. (I know this is paranoia, but it occurs to me that someone might think this is actually Mikrotik documentation, when it's documentation *about* Mikrotik.)

Yep that is not a problem. I wonder if "Mikrotik naming" or "Mikrotik configuration naming" or something else.

Yep. Thanks!

* It would also be nice if someone could offer a space in the corner of some webserver for perma-hosting this. This is of course jaclaz's diagram, but if my opinion were to count (hint: it really doesn't), I'd insist on something that is not some arm of a cloud service / non-ad supported / not tracking its users. I might offer such a space but that would actually require installing and configuring a web server...

Oww, come off it, it is not such a precious resoource that will become viral, the people actually interested in this (all 42 of them) can get it from this thread just fine.

Okay. Let's hope no one's interested . This is going to be a rant - so please excuse me. I hope that at least some usage of the internet will return to what it once was - people sharing sometimes peculiar interests sharing stuff without an eye to monetization. I hope some of it is preserved or some it will return.

* I sense that this is not in agreement with the majority opinion here - which is find, thats why it's called the majority opinion. But I'd use the same style box for the loopback as for the incoming/ougoing packet. However not-labeled these things are, they all represent interfaces, and in my time doing illustrations (and also teching) I observed that the "impression" that illustrations convey sometimes sick with people for a surprisingly long time, even when what exactly it is they convey is unclear to them initially. If it were totally up to me, I's actually separate the loopback into two, "to loopback" and "from loopback" places right next to each other, to convey that the packet actually exits netfiler, and then is reinjected. You wouldn't guess from the amount of text I devote to this, but this is a really minor point.

I don't care about the majority, it is not democracy, but you'll have to defend your opinion in front of the Court (myself) .
https://www.quotes.net/mquote/65590

F*ing awesome.

If an interface has not a RJ45, a SFP socket or an antenna, it is a "different" interface.
In any case NO interface (exception made for the "different" loopback) has been cited (nor harmed) in the making of the diagram, we have Incoming and Outgoing Packets (and that a packet has a different symbol from an interface is a self evident truth).
Now (since it is anyway "different") the idea of dividing the loopback interface in two seems to me a nice one .
Also I would like *somehow* add that this interface is exposed as (lo) in newish RoS.

In natural language usage, yes, interface has a meaning of something I can plug something into. In terms of the netfilter framework, interface has a specific meaning of what's in the kernel called a netdev. Loopback is such. In that it's somewhat simplistic in that it returns whatever it receives makes it no less so.

Why not publish plain svg?

Sure , that's entirely possible.

* With respect to the src-addr/dst-addr thing, especially with the "(loopback)" added, I would be inclined to just put "from self (loopback)" and "to self (loopback)" respecively. I think this is not inaccurate anymore, and with "loopback" added (in both wording and the actual path) there is no confusion anymore, even to the most casual reader.

I thought that src addr and dst addr were vital to make it adapted to Mikrotik jargon, let's wait what other people think, in any case I "need" a question mark as it is a question (to which you can answer Y or N) .

For #5 I agree with @lurker888 that "from self (loopback)" is more accurate than "src addr=self", because the source address field of the packet can be spoofed by a sender from outside, while the check here applies to the real origin of the packet.

I did some tests, by adding a log rule to mangle prerouting (#4 right above) and doing:

- /tool/ping from router to router's addresses, with or without specifying different source IP addresses and "out" interfaces
- /tool/traceroute with UDP from router to router's addresses, with or without specifying different source IP addresses and "out" interfaces
- :resolve specifying server=router IP addresses
- /tool/fetch to URL with router's IP address
- /tool/netwatch tcp-conn to router

I all case the incoming packets all have in-interface=lo, even when different outgoing interfaces were chosen for ping/traceroute. So maybe "in-interface=lo?" can be an alternative here? Or if "lo" looks confusing (like uppercase I) then maybe "in intf loopback?" (two lines). This would be compatible with "MikroTik jargon".

For #12 and #24, because the check is really performed on the destination address as @lurker888 has confirmed above, the current wording "dst addr=self?" is totally fine IMHO, and doesn't need to be change to "to self".

To be honest, I got a bit embarrassed at my error with regard to the "src addr" thing, so before writing my reply, I injected packets into
* a Mikrotik (running 7.191.)
* an Ubuntu machine modified to run iptables
* an Ubuntu, as stock, running in iptables-nftables compatibility (as has been the default for many years now)
- in all instances the route the packet took was according to the ingress interface.

Then I went and looked at the source code: lo and behold, you can guess what I found.

So it's clear that "from self" is the correct one.

The "dst addr=own addr" thing is a bit simplified but largely accurate. (I still think "to self" would be better, but the "dst addr" one is at least accurate enough.)

EDIT: Yes, I hate being wrong.

OK.
Let's see how it goes with this version (directly as svg).
Background set to 2.5% Grey (in practice a non-brilliant white) with Opacity 50% 70% (in a .zip file as the board does not allow .svg extension).
Added inline the png version.

EDIT: files removed

On my phone the gradient of the png version is a little bit too dark on the bottom and right side. The other parts a good.

The green /ip firewall filter box on the left side needs to move down. Currently it's not aligned with the other green boxes.

Yep, I'll fix the /ip firewall filter.

The fun thing is that I didn't use (AFAIK) a gradient, anyway it is far more dark *everywhere* than I would have expected.
Maybe the 50% opacity is too transparent for your darkmode
I'll check the gradient (if any) and try with 70% opacity

EDIT: files in post #37 changed. See if it is now better in dark mode.
P.S. It must be something connected to the way dark mode works, the 70% (Gray 2.5%=white) Opacity should be more light than 50%, (but it is not in a browser I have).
But if I open the image in a new tab, the colour becomes lighter (still darker than the original, but a gray light enough to be readable)

Another attempt, 70% Gray 2.5%=White

EDIT:file removed

There will always be something cosmetic left to do, but that's what I would call basically (almost) done. Thanks for the not insignificant effort!

For me at least the latest 100% opaque is shown as 100% transparent Is there this much difference between browsers? Can the page's css interact with it somehow?

Shouldn't it say "chain: postrouting" in right top corner?

Yep, I'll fix the /ip firewall filter.

The fun thing is that I didn't use (AFAIK) a gradient, anyway it is far more dark *everywhere* than I would have expected.
Maybe the 50% opacity is too transparent for your darkmode
I'll check the gradient (if any) and try with 70% opacity

EDIT: files in post #37 changed. See if it is now better in dark mode.
P.S. It must be something connected to the way dark mode works, the 70% (Gray 2.5%=white) Opacity should be more light than 50%, (but it is not in a browser I have).
But if I open the image in a new tab, the colour becomes lighter (still darker than the original, but a gray light enough to be readable)

Another attempt, 70% Gray 2.5%=White
Flowchart_beta01_W70.svg.png

This version now looks fine on my phone, also good when downloaded as PNG and open with the built-in Windows Photos app
(The one that you edited on #37 is however VERY dark)

There will always be something cosmetic left to do, but that's what I would call basically (almost) done. Thanks for the not insignificant effort!

For me at least the latest 100% opaque is shown as 100% transparent Is there this much difference between browsers? Can the page's css interact with it somehow?

Try again I re-made the background for the image in post #39.
Should be a very slightly gray white on normal mode and a (rather ugly I have to say, but at least readable) light gray in dark mode.
Still, and still in dark mode if you open the file in a new tab, it becomes much lighter (the shade of gray I actually was looking for not to flash the poor eyes of the poor users of dark mode).
I added a dark mode extension to another PC running Opera (which essentially is (or should be) Chrome to make a couple of tests and when in dark mode the diagram posted by chechito (which is pure white or nearly so) hit my eyes like a flash.

Shouldn't it say "chain: postrouting" in right top corner?

Yep, I'll fix it.

This version now looks fine on my phone (the one that you edited on #37 is however VERY dark).

Good, probably I had some wrong settings in #37, though if you open the file in #39 on another window, background should become much lighter.

EDIT: OK check these.

<placeholder post for the final version - once ready>

I am in the habit of taking pictures to document the progression of works, so here it is (9 June 2025 8:00 Zulu):


photo1.jpg

The first thing to do when encountering issues is to stop digging! ;-P
Awaiting for the 'real final product' to review, litmus test LOL, to see if a half wit can make heads or tails of it.
Really cool to see the collaboration. Imagine if mikrotik enlisted forum talents on some of their 'godawful' work.

The first thing to do when encountering issues is to stop digging! ;-P

There is still a few guys in the pic without name. You can add some comments and one will be named anav

Thanks for the offer, but I dont belong. You guys know what you are talking about from an educated networking and engineering perspective. DYI doesn't cut the mustard but I am always willing to look at stuff to see if it makes sense for the 'masses'.

The first thing to do when encountering issues is to stop digging! ;-P

There is still a few guys in the pic without name. You can add some comments and one will be named anav

anav could be the one top left, depressed/frustrated as in this thread he cannot suggest VLANs nor "drop all else" as last rule.

I don't know if others agree, but I think that the time to review this and speak up (both approvingly and in disagreement) is about now. I think the structure and naming are about settled - what's left are typos, rectangle edges that don't line up just so, background color choices (my suggestion would be already-frustrated-with-mikrotik-push-me-over-the-edge gray - does someone know the RGB for that?)

@jaclaz: The latest version looks really good! Awesome work!

Okay, I will bite.
Lets take the scenario where we mangle traffic coming to the router so it goes back out the same WAN.
Lets say WAN1 is primary and traffic is to the router via WAN2 and needs to go back out WAN2.

/ip firewall mangle
{ mangle for traffic to router }
add action=mangle chain=input connection-mark=no-mark in-interface=lt2p-4g \
new-connection-mark=incoming-ISP-B passthrough=yes
+++
add action=mark-routing chain=output connection-mark=incoming-ISP-B \
new-routing-mark=to_4gB passthrough=no

I can see via the diagram how the incoming traffic hits Mangle input, but am unable to grasp where this traffic is able to reach mangle output??
I am thinking somehow it SKIPS from step 9 to 15 and then that path?? I see no way it goes to 10,11 and so forth as its directed toward mangle forward and never gets to mangle output ???

@anav: Well then... I'll bite as well. Actually this is why I asked if it would be useful to outline some common packet flow scenarios - of course, separate from the diagram. (And why I asked that the steps remain numbered )

So let's look at the case you present. Let's look at a scenario: you want to reach your router via SSH, both from ISP-A and ISP-B - and of course you want the router to "answer" always on the appropriate WAN connection.

When the external client connects to the router, the packet flow is as follows:
1 -> 2 -> 3 -> 4 -> 5 -> 10 -> 11 -> 12 -> 6 -> 7 -> 8 -> 9

Let's say the connection comes in on ISP-B. The only interesting thing to this packet happens in (6) (mangle input) where a connection-mark of incoming-B is assigned to this connection. (If the connection if from ISP-A, no connection-mark is applied.)

When the router answers to the client, the packet flow is as follows:
15 -> 16 -> 17 -> 18 -> 19 -> 20 -> 21 -> 22 -> 23 -> 24 -> 25 -> 27

The interesting things here happen in the following steps:
(16) Initial routing lookup - this always happens according to the "main" table
(18) Connection (state) tracking - here the connection is recognized as the reciprocal connection to the one added for the incoming packet. The connection's connection-mark is available from this point on. If the connection came in in ISP-B, the connection-mark is incoming-B, in the connection came in on ISP-A, no connection-mark is present.
(19) Mangle output - here if the connection mark incoming-B is set as per (18), a routing-mark is applied
(21) Final routing lookup - a repeated routing lookup is done, if a routing mark was not applied (the connection came from ISP-A), the lookup is done in the "main" table, if a routing-mark was applied (the connection came in via ISP-B), the repeated lookup in done in the table specified

And everything works out fine. All is joyous.

I saved the short answer for last: you see correctly, no packet goes through both the input and output chains, as none should.

Okay so my guess is that step 9 skips to 15 is correct and that the numbering is not necessarily a traffic flow just a marker number............

Well, not exactly. 1->9 is the flow for the initial packet client->router; 15->27 is for the response packet router->client. They are different packets - that the ssh server (daemon) produced the second packet in direct response to the first is not a firewall question.

E.g. a DNS request may trigger a response, or the DNS server might first contact an upstream, and only upon receiving *its* answer would it respond to the client, etc. - so it's entirely dependent on what the given service decides to do.

I asked if it would be useful to outline some common packet flow scenarios

I (and I'm sure others) would indeed find it helpful to have "common" packet flow scenarios run through the flowchart. This process would be an educational one (to help better understand packet flow and the control thereof within ROS) as well as possibly a check on the the validity and accuracy of the flowchart. I was reluctant to ask/suggest because my scenarios would be of the extremely simple type.

Well, I was only planning on doing simple ones. The one anav proposed here was going to be about the most complicated one I'd go for.

I just think it's important to understand the "routing adjustment" step, as Mikrotik calls it, and its importance for mangling.

Well, not exactly. 1->9 is the flow for the initial packet client->router; 15->27 is for the response packet router->client. They are different packets - that the ssh server (daemon) produced the second packet in direct response to the first is not a firewall question.

E.g. a DNS request may trigger a response, or the DNS server might first contact an upstream, and only upon receiving *its* answer would it respond to the client, etc. - so it's entirely dependent on what the given service decides to do.

Even if the second (reply/response) packet is not the SAME one, it wouldn't exist (IF it exists) without the first (incoming) one.
So I think we need to find a graphical way to make it more evident that 9 and 15 are actually (loosely) connected by *some mechanisms* (which do not belong to firewall and thus it is not shown in detail in the flowchart).

I'll think of something.

I don't think that's necessary (something describing the "link" between #9 & #15), because for a packet destined for the router, its lifetime ended at #9. The "flow" of that packet has finished there.

Let's say we add something explaining the fact that after a packet has reached #9, some kind of new packet would be originated at #15 in response (even though that's not true in all case, when a WireGuard handshake packet using the wrong key it sent to the router for instance, absolutely no response packet will be produced), then we would also need to write something explaining that after a packet has been sent to #27, something in response might arrived at #1 (produced by remote devices), or not. But we can agree that this is completely unnecessary and doesn't need to be mentioned on the flow chart. Which means the possible "link" between #9 and #15 also doesn't need to be explained neither.

In the old version of the chart, there were the case where the same packet going out of #27 can end up going back to #1 (being the same packet), and that was the router-loopback case, but that specific flow now has its own path through #26 and requires no further footnote/explanation.

@CGGXANNX: I think you put it perfectly! The "explanation" this flow charts shows is that it was transferred to the "local process" - a service, which depending on its exact type and behavior will see to it that it's processed and will take the appropriate measures. This is full, correct and easily understood.

Actually, this why I think an accompanying "some typical flows explained" document would be nice to augment the understanding around this. But I think this should be a separate thing.

I'm not trying to disparage the efforts in the official Mikrotik wiki, because all those who attempt this sort of thing are bound to fall short in some way, but why their packet flow diagram is often linked to, but I suspect invariably not that useful to those who are referred there, is that they try to cram every case and every complexity into one giant diagram (with sub-diagrams, to boot) and it's just confusing to sort it all out. Doubly so for people who are not that familiar with the framework - which is most everyone who is referred there.

P.S. I have a faint feeling that writing these explanations will fall to me. I have a strong inclination to include some examples of encapsulations, because that's really the case where in some changed form, the packet can actually be viewed as somehow reappearing.

I don't think that's necessary (something describing the "link" between #9 & #15), because for a packet destined for the router, its lifetime ended at #9. The "flow" of that packet has finished there.

Let's say we add something explaining the fact that after a packet has reached #9, some kind of new packet would be originated at #15 in response (even though that's not true in all case, when a WireGuard handshake packet using the wrong key it sent to the router for instance, absolutely no response packet will be produced), then we would also need to write something explaining that after a packet has been sent to #27, something in response might arrived at #1 (produced by remote devices), or not. But we can agree that this is completely unnecessary and doesn't need to be mentioned on the flow chart. Which means the possible "link" between #9 and #15 also doesn't need to be explained neither.

In the old version of the chart, there were the case where the same packet going out of #27 can end up going back to #1 (being the same packet), and that was the router-loopback case, but that specific flow now has its own path through #26 and requires no further footnote/explanation.

Still, if anav, whom - while maybe not a qualified network engineer - definitely has some little familiarity with Mikrotik firewall settings had this doubt, think of what a newcomer would think/believe..

That the packet is terminated on #9 should be evident by the shape of the box (rectangle with rounded corners means start/end (with respect to the object of the flowchart, i.e. the firewall), but the packet doesn't go poof, it is actually *somehow* analyzed/manipulated/changed/transformed/whatever by some mechanism inside the router (router's internal process).

And I am not going to add an explanation of the mechanisms, only a graphical hint that some mechanism may (or may not) be involved and prompt (or not prompt) the generation of a response packet (packet generated by router).

Anyway, yours and lurker888's objections are overruled.

Find attached beta 0.2. And yes, I know that today is the 11th, but the idea came before midnight of the 10th, I swear.

Still, if anav, whom - while maybe not a qualified network engineer - definitely has some little familiarity with Mikrotik firewall settings had this doubt, think of what a newcomer would think/believe..

To me at least "qualified network engineer" carries not only no weight, but no meaning. What's the criterion anyway? They have a degree? They're paid to do it? Most people who have some relevant degree/certification and are paid to do it know *way* less than @anav. (Quite often so much less, that it's sad and horrifying.) Okay, rant over.

Anyway, yours and lurker888's objections are overruled.

*sobs quietly*

But actually your visual representation is nice. I think with the loopback having a strong and definite (thick arrows) flow, the lighter implied coupling between the "to local process" and "generated by local process" actually captures (or rather visually correctly suggests) what's actually happening. Upon viewing the result, it actually seems intuitively correct.

As a aside: this is why I'm glad to see and happy to participate in your project. We have all grown so accustomed to seeing things shown a certain way and using certain expressions over the years, that it feels natural to continue to use them. But this language (both in the design and text sense) is clearly impenetrable to many, and a set of new eyes is required - which you seem to present with success.

One way to make the traffic to and from the router more visual might be to add a symbol right in the middle of the diagram that represents the router itself and its different services.

Jinx @jaclaz. Yours was way more professional!

P.S.
Just noticed the picture in your first post - cracked me up!

One way to make the traffic to and from the router more visual might be to add a symbol right in the middle of the diagram that represents the router itself and its different services.

I actually like this. It's definitely a step away from the sterile view of presenting only the kernel subsystem. But it could very well be way easier to understand.

Maybe even go further, and have the "router's internal processes" as one entity, with packets entering and leaving it. The symbol should be something "cloudy" to suggest that various things can go on inside. I would still label the input/output arrows with the current "to router's internal process" and "generated by router", just so the diagram can be easily linked to the more conventional depictions.

Thoughts?

Are you talking about something like the gray circle (with services) in my suggestion, or are you referring to a completely different approach?

Added some semi-random graphics in the middle.

It seems to me like better representing the idea that there is some mechanism inside the router that will take some decision.

Are you talking about something like the gray circle (with services) in my suggestion, or are you referring to a completely different approach?

Yes.

I was referring to something very much like yours, with the gray circle. My suggestion was to basically just have the gray circle, and give the things that are now rounded rectangley less focus. Simply because it's pointless to write "to local process", when we have a box labeled "local processes" and an arrow pointing to it...

Upon seeing it, I like jaclaz's the best: the packet entrance/exit points are preserved (and on second thought that was not nice about my previous approach, it looked like just another processing step, which it is not). But with things grouped in the braces, all this is clear.

I would only suggest that instead of the assorted kitchen utensils, actual text could be included, like "services", and while I'm a bit "put off" by it, I think actually including some well-known examples, such as "DNS, Winbox, SSH" there would certainly help in making the idea immediately recognizable. (Maybe with small letter?) Maybe these labels don't deserve their own box? Maybe they should be in some sort of "cloud" symbol to show that they are sort of indefinite (or a loose assortment), at least from the POV of the diagram.

Just an important note: IPSec should *never* be put in there. IPSec, especially policy-based (the only one Mikrotik does) is not done there. If we want to be pedantic, the IKE service does run there, but actual encryption/decryption does not.

I was referring to something very much like yours, with the gray circle. My suggestion was to basically just have the gray circle, and give the things that are now rounded rectangley less focus. Simply because it's pointless to write "to local process", when we have a box labeled "local processes" and an arrow pointing to it...

Only little problem being that we don't have "a box labeled "local processes" and an arrow pointing to it." , nor we have written anywhere (on the flowchart) "to local process" .
We do have a box labeled "to router's internal process" with an arrow pointing to it, though .

I would only suggest that instead of the assorted kitchen utensils, actual text could be included, like "services", and while I'm a bit "put off" by it, I think actually including some well-known examples, such as "DNS, Winbox, SSH" there would certainly help in making the idea immediately recognizable. (Maybe with small letter?) Maybe these labels don't deserve their own box? Maybe they should be in some sort of "cloud" symbol to show that they are sort of indefinite (or a loose assortment), at least from the POV of the diagram.

Make an exact list of those services.
I have about six lines available in Excel that should be enough for about 6 or so (maybe a few more if three or four letters) of them in 10 points characters (they will become roughly 8 points in the final svg/png A3 version), small but still readable:
1.
2.
3.
4.
5.
6.
7.
8.
9.

Then I will find a suitable symbol to enclose them.
Loosely something *like*:

Only little problem being that we don't have "a box labeled "local processes" and an arrow pointing to it." , nor we have written anywhere (on the flowchart) "to local process" .
We do have a box labeled "to router's internal process" with an arrow pointing to it, though .

Now you're just being cruel...

Make an exact list of those services.
I have about six lines available in Excel that should be enough for about 6 or so (maybe a few more if three or four letters) of them in 10 points characters (they will become roughly 8 points in the final svg/png A3 version), small but still readable:

I think as a symbol something like this is fine.

It wasn't my intention to list all the services, because obviously we could start at OpenVPN and end at file sharing like SMB, NFS, etc. My thought was just to give a few (maybe 2-3-4?) well-known examples. Those were the first that came to my mind, but if someone has a more universally recognized selection, I'm all for it.

Thanks again for tolerating all the "little ideas".

One of the example processes should be something that actively initiate connections (such as fetch, traceroute, or netwatch, that start with #15), not only those that normally first listen for incoming connections.

Why exactly do you think that the example has three dots last? I could even change those to "etc."

Your mission, should you accept it, is to list a number (no less than 6, no more than 12) of the most commonly used *things*, those that can be considered exemplary for the concept to be easily graspable, in an order similar as much as possible as their usage in the real world.

To make an example[*] with the the three services mechanisms (as fetch, netwatch or traceroute are not services AFAICT) mentioned by CGGXANNX:
1. traceroute - used before or later by 100% of users <- RELEVANT
2. netwatch - used very often later by 45% of users <- MARGINAL
3. fetch - used only later by 17.8% of users <- fetch WHAT?


[*] I simply love to cite freshly invented statistic data

Your mission, should you accept it, ...

This post does self-destruct within 5 seconds, doesn't it ?

This post does self-destruct within 5 seconds, doesn't it ?

Naah, it uses Mikrotik v 6 date/time format, but runs on v 7 so it will self-destruct at a random instant between last week and next year.

Your mission, should you accept it, is to list a number (no less than 6, no more than 12) of the most commonly used *things*, those that can be considered exemplary for the concept to be easily graspable, in an order similar as much as possible as their usage in the real world.

Okay:
1. DNS (a usual well-known service)
2. Winbox (an example of an admin interface)
3. SSH (don't know really, I just think it's so ubiquitous that it's somehow worth mentioning)
4. traceroute (a diagnostic function)
5. OpenVPN (a well known user-space VPN)
6. detect internet

I have no idea for no. 6, actually, but by listing everyone's favorite feature, it can at least be ensured that you get plenty of suggestions

I would personally refrain from mentioning scripting functionality, and netwatch, not because it's not a perfect example, but the naming is absolutely Mikrotik-specific.

I think CGGXANNX at least deserves to be given no. 6, and also to replace SSH if he thinks there's a better example.

- DNS
- DHCP
- NTP
- Winbox
- WebFig
- Rest API
- SSH
- IPSec
- L2TP/PPTP/SSTP
- Wireguard
- ZeroTier
- OpenVPN
- SNMP
- BGP/OSPF/RIP/MPLS
- FTP
- CAPsMAN
- RoMON

@Larsa: I get your point, just please don't go overboard:
* IPSec is not handled this way, only the IKE daemon runs as an actual process, the policies are matched elsewhere
* MPLS is not handled according to this diagram at all (other than in the sense that the routing protocols that signal it do)
* RoMON also fundamentally works in a way not described in this diagram

Well, maybe they’re at different levels in the stack, but they still have to be handled by the internal services to work, so they definitely belong in the box. But those were just examples, so just throw in whatever you think fits best. Personally, I’d go with a few that are pretty well known and recognized even by people who are new to ROS.

LOL, @Larsa's list is list the "hard mode" of the MikroTik forum's password challenge (where they ask you identify routers in a list as captcha)... Except, @Larsa list is "which of the following do NOT involve the Layer3 IPv4 firewall"...

The value, I think, of @jaclaz's work is X and Y axis, configuration section vs chain. Something like IPSec is just complex, and already covered by MikroTik existing ones & full fidelity would likely make jaclaz work just as confusing.

Now WireGuard... is not covered in either case— but I'm not sure anyone could definitely describe its flow . That seems like it should have its own diagram one day — since it's even more confusing from packet flow than IPSec.

(From photo, I guess I was typing: "We have another hole to dig after this one is done")

6. detect internet

You must be joking , that is Rule #5 of the Mikrotik Club:
viewtopic.php?t=215004
no way it will be mentioned on the flowchart as people might believe that it actually does something (useful).

Not detect internet, please...

@Larsa: MPLS and RoMON do not interact with the ip firewall and are not shown; IPSec of course does, but it is explicitly excluded due to the complexity/confusion that it adds.

@Amm0: Actually Wireguard is fully covered. The only strange thing about wg regarding the firewall diagram is that it runs in kernel space, but it has a fully functional and equivalent user space implementation (written in Go no less). The peculiarities around its routing are not because it's different as a service but because of certain design decisions that were made during its development. (It may be hard to believe, but sometimes they are actually to your advantage.)

@jaclaz & @holvoetn: Read the sentence immediately following the quote. I was trolling - apparently successfully

MPLS uses Protocol 138 along with LDP/OSPF/BGP ie whatever routing protocol you’re using and needs to be managed with the firewall. Yeah, RoMON is Layer 2 but still counts as a ROS service.

Personally, I’d stick to more familiar services like DNS, FTP, etc..

@Amm0: Actually Wireguard is fully covered.

You're right actually. I've just been skared by the multiwan routing of the tunnel - the firewall is actually not hard.

IMO, the only reason to include "IPSec" is that the default firewall has "matchers" on ipsec-policy=. But again to your point, IPSec actually no different – at least from firewall POV – than say "hotspot" or PCC — all have some set of special/"weird" matchers. ".../filter add <tab>" would indicate cover of those be a lot of <> boxes...

Now I like the 15/9 "local process" cloud in latest proposal! While MikroTik flow show it... it not initially clear what that is from their diagrams - so some examples do help I think (careless which ones are shown).

@Larsa:
I don't know, maybe we are somehow talking past each other. MPLS uses ethertype 0x8847 (and 0x8848) - IP uses 0x0800, these packets aren't handled by the IP firewall - their contents may be before encapsulation or after decapsulation, but then they're just IP packets.

There is such a thing as MPLS-over-IP, and this does use IP protocol 137 (not 138). It's not especially common (but does happen). MPLS is also transported over PPP, which Mikrotik I think supports (never tried it myself.)

Anyway, MPLS is not a service. The routing protocols of course all are.

@Amm0: IPSec packets do go through the firewall (and have the appropriate flags), but they do that in a roundabout way that is not shown in this diagram. They are actually diverted after "filter input" (for incoming) or "nat postrouting" (for outgoing) and after en/decryption they are reinjected to a prior stage of the packet flow. (Here I specified the last stage after which IPSec policies are filtered that is shown, there are some other things happening in between, which are not in this diagram.)

In the next release, I will add something *like* this.
Hopefully giving the impression of "a bunch of stuff floating inside the router".

@jaclaz: I'm sorry to notice this only at this late stage, but logically reading your diagram (I mean the horizontal and vertical arrows at the left and top) it's not easy to deduce that no. 10 would be used in Mikrotik as "nat add chain=dstnat" (not chain=postrounting), and similarly with no. 25. Is this intentional?

EDIT: That graphic with the floating services actually makes a lot of sense.

@Amm0: Once the diagram is finished, it’s time to start adding different use cases. I’m thinking maybe 8–10 examples should be enough to cover most of the common scenarios. And maybe then we’ll finally have some flowcharts that everyone can actually follow for things like WG, IPsec, and all the new cloud services. Honestly, I’ll probably get a lot of use out of the diagram myself when troubleshooting or just needing a quick visual reference.

Feels like this could turn into something really useful now that we can use numbers as clear references in the packet flow.

@jaclaz; Yeah, looking good!

@jaclaz: I'm sorry to notice this only at this late stage, but logically reading your diagram (I mean the horizontal and vertical arrows at the left and top) it's not easy to deduce that no. 10 would be used in Mikrotik as "nat add chain=dstnat" (not chain=postrounting), and similarly with no. 25. Is this intentional?

I don't understand, but the idea of building something is to change it when it doesn't do what it should do.

Do I need to add a chain? Or two? at the top?

Or only change the purple fat arrows on the left?

Or both? actually one of the things that I don't like of the current diagram is the duplication of the purple /firewall nat, if there is a way to avoid that I would be happy, even if it implies adding chains, sections or whatever and complicating the path of links..

It is not difficult with the current base to provide unambiguous instructions in the form:
box#-X-Y-text
Example:
6-chain=input-/ip firewall mangle-mangle INPUT

EDIT: That graphic with the floating services actually makes a lot of sense.

Good.

@Amm0: Once the diagram is finished, it’s time to start adding different use cases. I’m thinking maybe 8–10 examples should be enough to cover most of the common scenarios. [...]

Yup, some "overlays" with connection arrows (in "Dude terms", "links") might be one future approach

Feels like this could turn into something really useful now that we can use numbers as clear references in the packet flow.

@jaclaz; Yeah, looking good!

Yup, I kinda think so. I do find the MT's packet flow useful — but it does not provide the initial overview of how it relates to actual configuration, nor provide an "overview".

Or only change the purple fat arrows on the left?

Or both?

Minor, again, the "fat arrow" things are not process. Maybe use rounded corners label boxes with the arrows, or just put the text in arrow without any box. Just so they are even more visually distinctive from the "inner" boxes.

Very minor, but you could MikroTik's official fonts. Like the /ip/firewall/... outer labels could use "JetBrains Mono" since they are commands... They also have "suggested colors" but since they cover a lot of the RGB space, you may already be good there.

I don't understand, but the idea of building something is to change it when it doesn't do what it should do.

Do I need to add a chain? Or two? at the top?

Or only change the purple fat arrows on the left?

Or both? actually one of the things that I don't like of the current diagram is the duplication of the purple /firewall nat, if there is a way to avoid that I would be happy, even if it implies adding chains, sections or whatever and complicating the path of links..

It is not difficult with the current base to provide unambiguous instructions in the form:
box#-X-Y-text
Example:
6-chain=input-/ip firewall mangle-mangle INPUT

The problem stems from the fact that Mikrotik renamed "nat PREROUTING" to "/ip firewall nat add chain=dstnat" and "nat POSTROUTING" to "/ip firewall nat add chain=srcnat". This is not terrible naming, btw. And yes, they renamed just these two, in the other tables (mangle, raw) the chains were left as pre/postrouting.

The issue is that if - after licking off the Cheetos dust* from my fingers - I finger-trace "nat PREROUTING" from the left and top, I come up with "/ip firewall nat" from the left, which is perfect. But tracing from the top, I finish it with "chain=postrouting", which should be "chain=dstnat".

And I get this by following labels that are proclaimed to be "Mikrotik configuration naming", which is not very becoming.

What to do about this? I currently have no idea. Maybe after a few hours... I'll be sure to post it, if I've got something.

If we can't come up with something better, as a last resort this exception could just be added to the boxes themselves, e.g. instead of "nat (dstnat) PREROUTING", "nat POSTROUTING; chain=dstnat". I agree that this is ugly and inconsistent, we really should come up with something nicer.

I actually understand why this renaming was done, but it's really irritating for this project. I mean your diagram is the illustration for why it was originally named that way.

* Relax, I don't actually eat that stuff.

@jaclaz, just a minor detail: shouldn’t the text in the purple "nat" boxes to the left be something like “/ip firewall srcnat” and “/ip firewall dstnat” instead of just “/ip firewall nat”?

@jaclaz, just a minor detail: shouldn’t the text in the purple "nat" boxes to the left be something like “/ip firewall srcnat” and “/ip firewall dstnat” instead of just “/ip firewall nat”?

or the full/partial "real" syntax (or "MikroTtik configuration naming") like "nat action=dstnat"

In the next release, I will add something *like* this.
Hopefully giving the impression of "a bunch of stuff floating inside the router".

Mt_services.JPG

I think to be safe we should maybe leave "DHCP" out of this because DHCPv4 uses special sockets and for a large part isn't affected by the firewall. IIRC you won't see the DHCP packets on the output chain at all (try logging with raw output and mangle output for example). And even with explicit drop rules on the filter input chain of the router, clients are still able to obtain DHCP leases.

DHCPv6 does behave normally with regard to the firewall and can be blocked with the normal filter rules though.

I think CGGXANNX at least deserves to be given no. 6, and also to replace SSH if he thinks there's a better example.

Thanks, but my traceroute suggestion is already included

Yep. DHCPv4 shouldn't be mentioned.

Yep. DHCPv4 shouldn't be mentioned.

Not shown, but "ping" / ICMP be in same category since the kernel does some work there.

Probably should drop traceroute for the same reason.

I would consider both ping and traceroute to be fine.

A possible issue is that especially ping can refer to the user space diagnostic tool, in which case it's clearly fine. Or it can refer to the answering of possible incoming ping requests - which is done in the kernel. I don't really think the "done in the kernel" bit should be a huge differentiator, we accept it everywhere else: for example, Wireguard as used on Mikrotiks is obviously the in-kernel implementation, but you couldn't really tell if it was the user space wireguard-go under the hood (apart from the CPU load) - and the difficulties around its routing behavior are exactly the same regardless of whether the in-kernel or user space version is used.

ICMP connections are fully handled by the firewall (netfilter) in that the usual filter/mangle/nat apply to them in exactly the same way, they are even tracked and have their usual conntrack entries. Discussions on connection tracking don't often deal with how exactly ICMP is tracked, but there's a while lot of code inside netfilter to do so, so as an example of non-TCP/UDP traffic that's firewalled the same as everything else it's totally appropriate.

If you'd prefer other more characteristic examples, that's another matter. In that case go right ahead

This obviously applies to all IP protocol types, so in this context ICMP isn’t really a special case. If you’re going to keep any ICMP tools, I’d say ping is short and to the point. WireGuard and IPsec are also protocols that get a lot of questions. Same goes for Winbox, NTP, DNS and probably a few others too.

n/a…

I'm probably explaining this is a too convoluted manner, but IPSec (at least the policy based variant) *is* handled in a very special manner, different from basically everything else firewall-related.

Let's look at an encrypted packet arriving, and let's look at what happens with IPSec, and compare the same for Wireguard:

For IPSec: (Let's assume tunnel mode, and no NAT traversal.)
* the encrypted packet comes in through the WAN interface
* the packet is addressed to the router, proceeds through input, it can be filtered/allowed, in-interface is wan, protocol=47 (esp) everything fine
now here come the differences:
* after input, the policy match occurs, packet is decrypted, the decrypted packet is injected back into the packet flow
* the decrypted packet has in-interface WAN
* the decrypted packet has the ipsec-policy special packet marking - actually this is the only way we can tell that this packet didn't just come in unencrypted

For Wireguard:
* the encrypted packet comes in through the WAN interface
* the packet is addressed to the router, proceeds through input, we can filter it, in-interface is wan, protocol=udp, dst-port=13231
* the packet disappears into the "local process" cloudy thing
now come the differences:
* the packet is decrypted, and is reinjected via the wg (virtual) interface as an incoming packet
* the decrypted packet has in-interface wg
* the decrypted packet has no special marking, it's simply differentiated by its in-interface

Just as a bonus, if you apply a packet mark to an IPSec encrypted packet, it can be successfully matched when handling the decrypted version of it. If a Wireguard encrypted packet is marked, the decrypted version doesn't carry the mark.

Wireguard behaves in the expected way, IPSec (especially policy based) is just f*cking weird.

Well, a bit OT, but IPSec is no weirder than WG, just comes with a lot more bells and whistles. WG does spoof checking on the initial handshake where the egress interface gets messed up.

But back to packet flow; both are common denominators for the same reason ie when using “loopback” packet scenarios for the encryption/decryption phase, which needs special clarification.

The problem stems from the fact that Mikrotik renamed "nat PREROUTING" to "/ip firewall nat add chain=dstnat" and "nat POSTROUTING" to "/ip firewall nat add chain=srcnat". This is not terrible naming, btw. And yes, they renamed just these two, in the other tables (mangle, raw) the chains were left as pre/postrouting.

We have 4 (four) purple items.
#8
#10
#20
#25

They are currently (and wrongly) placed (#-X-Y-text) as follows:
8-chain=input-/ip firewall nat - nat (srcnat) INPUT
10-chain=prerouting-/ip firewall nat-nat (dstnat) PREROUTING
20-chain=output-/ip firewall nat - nat (dstnat) OUTPUT
25-chain=postrouting-/ip firewall nat-nat (srcnat) POSTROUTING

How should they be placed (in theory)?

@jaclaz, just a minor detail: shouldn’t the text in the purple "nat" boxes to the left be something like “/ip firewall srcnat” and “/ip firewall dstnat” instead of just “/ip firewall nat”?

I am not following you, in terminal do you have:
a. /ip firewall nat chain=srcnat
or
b.. /ip firewall srcnat
?

If #a, then we need to *somehow* add a "chain=srcnat" and a "chain=dstnat" to place these 4 boxes into.

An alternative, that however, will break the whole meaning of the neatly placed "Mikrotik Configuration Naming" at the top left is:

* The top row (the "headers" with the yellow background) are changed to PREROUTING / INPUT / FORWARD / OUTPUT / POSTROUTING
* Then the yellow/cyan/purple/green rectangles will have chain=xxx on the 2nd line, for example:

2. raw \n chain=prerouting
4. mangle \n chain=prerouting
...
8. srcnat \n chain=input
...
10. dstnat \n chain=dstnat
...
13. mangle \n chain=forward
...
20. dstnat \n chain=output
...
25. srcnat \n chain=srcnat

Strictly speaking, the current heading, for example "chain=prerouting" has no meaningful concatenation with "Connection (state) tracking". Or "chain=output" cannot be put together with "Final Routing Lookup" to form any meaningful phrase. Those headers only "work" when being concatenated on the rows with the colored boxes. But even then, as we have seen, it doesn't work for #10 and #25.

We have 4 (four) purple items.
#8
#10
#20
#25

They are currently (and wrongly) placed (#-X-Y-text) as follows:
8-chain=input-/ip firewall nat - nat (srcnat) INPUT
10-chain=prerouting-/ip firewall nat-nat (dstnat) PREROUTING
20-chain=output-/ip firewall nat - nat (dstnat) OUTPUT
25-chain=postrouting-/ip firewall nat-nat (srcnat) POSTROUTING

How should they be placed (in theory)?

The Mikrotik syntax in the row/column headings definitely suggests that a valid command can be assembled when reading them in the Y-X direction (the reverse of what you listed.)

And this works! Also for the other boxes (normal non-conntrack ones) as well, including the mustard, arctic blue and mint colored ones. They don't work only for two of them: #10 and #25.

Something must be done, but I don't really like either of these:
1. Abandon the "chain=" in the columns, and put the iptables naming there: "PREROUTING", "INPUT", etc., and specify in every box the "chain=prerouting", "chain=input" syntax. In this way, assembling a Mikrotik command would work along these lines: Read the row label, and append the "chain=" text from the box. Clear enough. (If I understand correctly, this is the solution suggested by CGGXANNX)
2. Add additional columns for "chain=dstnat" and "chain=srcnat" with the first only having #10 and the second only #25. This isn't really nice either. Maybe it could be made (at least visually) acceptable by somewhat overlapping "chain=prerouting" and "chain=dstnat", and offsetting the boxes and labels accordingly, with the same done for postrouting and srcnat. (In this case obviously dstnat would be slightly to the right of prerouting and srcnat slightly to the right of postrouting.)

Maybe the offset chains one (#2) is the less bad? Really don't know.

An illustration (sorry for the quality)

(If I understand correctly, this is the solution suggested by CGGXANNX)

Yes, it is (and the "assembling" is "left column" + "2nd line"). I've also edited my post to add the labels of all the NAT boxes.

I will try again.
1. In which chain= should 8 go?
2. In which chain= should 10 go?
3. In which chain= should 20 go?
4. In which chain= should 25 go?

I am asking 4 (four) questions, numbered 1 to 4.

I expect 4 (four) answers, numbered 1 to 4.

Any other answer - particularly if partial - only confuses me.

I will try again.
1. In which chain= should 8 go?
2. In which chain= should 10 go?
3. In which chain= should 20 go?
4. In which chain= should 25 go?

I am asking 4 (four) questions, numbered 1 to 4.

I expect 4 (four) answers, numbered 1 to 4.

Any other answer - particularly if partial - only confuses me.

As requested:
1. #8 chain=input
2. #10 chain=dstnat
3. #20 chain=output
4. #25 chain=srcnat

For all the boxes:
#2 chain=prerouting
#4 chain=prerouting
#6 chain=input
#7 chain=input
#8 chain=input
#10 chain=dstnat (*)
#13 chain=forward
#14 chain=forward
#17 chain=output
#19 chain=output
#20 chain=output
#22 chain=output
#23 chain=postrouting
#25 chain=srcnat (*)

(*) - these two are the only ones named different than iptables

As requested:
1. #8 chain=input
2. #10 chain=dstnat
3. #20 chain=output
4. #25 chain=srcnat


For all the boxes:
#2 chain=prerouting
#4 chain=prerouting
#6 chain=input
#7 chain=input
#8 chain=input
#10 chain=dstnat (*)
#13 chain=forward
#14 chain=forward
#17 chain=output
#19 chain=output
#20 chain=output
#22 chain=output
#23 chain=postrouting
#25 chain=srcnat (*)

(*) - these two are the only ones named different than iptables

Good.
So #10 and #25 are set, they "belong" to /ip firewall nat (and they are purple) and respectively to dstnat and srcnat chains. OK.

Then #8 and #20 ( which right now are purple, indicating that they are in /ip firewall nat, and hold very similar text to #10 and #25) cannot actually "belong" to "/ip firewall nat", as "/ip firewall nat" has only two chains, srcnat and dstnat.

So, to which section do #8 and #20 "belong"?

Not to /ip firewall nat (per above)

Not to /ip firewall raw, as:
/ip firewall raw has NOT a chain=input
/ip firewall raw has NOT a chain=output

Not to /ip firewall filter.(as just above #8 there is #7 which is actually /ip firewall filter and under #20 there is #22 which is actually /ip firewall filter)

Not to /ip firewall mangle (as above #8 there is #6 which is actually /ip firewall mangle and above #20 there is #19 which is actually /ip firewall mangle)

So, do they actually exist?

And if yes where do we put them?
(and somehow we need to differentiate the text which right now is too similar to #8 and #25)

Quick table of chains vs. sections:

Haha, now you're getting the actual depth of the rabbit hole.

The /firewall nat table has chains dstnat, srcnat AND input AND output. And the last two is exactly where #8 and #20 belong.

It's true that Mikrotik omits the mention of these in its documentation. (I don't know if that's absolutely universal, but where I thought to look, it was not there.)

However... if you take a pristine 7.18.2 and go they're there. I sometimes (very-very rarely) use these chains, and I have verified that they are fully functional and correctly available.

However... if you take a pristine 7.18.2 and go

Code: Select all

[admin@xxx] > /ip firewall nat add chain= <<TAB>>
dstnat     input     output     srcnat

they're there. I sometimes (very-very rarely) use these chains, and I have verified that they are fully functional and correctly available.

Very good ..
The quick table I posted I extracted from terminal command line of v6.49.17, so *something* must have been changed in *some version* of 7.
It will be important to find out which one as the flowchart will apply from that version onwards (and we can make a footnote about chains input and output not being visible in v6 in /ip firewall nat)

Very good ..
The quick table I posted I extracted from terminal command line of v6.49.17, so *something* must have been changed in *some version* of 7.
It will be important to find out which one as the flowchart will apply from that version onwards (and we can make a footnote about chains input and output not being visible in v6 in /ip firewall nat)

Well, I really wasn't aware that it was ever not available. Again, I use it only on special occasions.

My first guess would have been that if they were added at some point, it would have been when the "raw" table was added, but I think the version you're referring to already has that...

If no one knows, I'm willing do downgrade one of my spare routers to some previous versions (the one I usually use for testing stuff can be downgraded to 6.40.5). I don't promise the locate some exact version, but I'm at least willing to take a look at the v7 series.

I think NAT input/output chains are pretty much edge cases, but they definitely have their uses. You might include them in the main diagram, or if you prefer, group them with other, more complex use cases like IPSec and WireGuard encryption loopback in a separate diagram.

It Is v7.
31 March 2022 being the First mention I could find:
viewtopic.php?p=922954#p922954