I have a hex RB750Gr3 with version 6.49.18 OS. Currently running the default firewall rules.
I used to have, and was familiar with, a Zyxel USG40 router that had my own custom rules (that Anav helped me write a long long time ago in place far far away). So I know a bit about basic firewall rules and how they work, although since they were pretty good and my needs are minimal I had no need to edit them for a long time, so I probably have forgotten a bit.
So I'll start with a few questions to make sure I understand how the mikrotik does firewall rules.

Question 1. input rules.
As I understand it these rules/chain is for traffic that originates on the WAN (outside) and is directed to the WAN facing side of the router itself. An example might be if I wanted to make a rule that allowed me to admin the router from the internet, like my office or something.

Forward chain/rules are for traffic on my LAN (intranet traffic) and/or for traffic coming from the WAN to and devices on my LAN.

Do I have that right so far before I even start asking real questions?

Input - Traffic to the router itself - can be from the LAN or WAN or any interface on the router.
Forward - Traffic passing through the router from one network to another. Can be LAN to WAN, VLAN to VLAN etc.

You should consider that everything IN from WAN should be dropped. That is to say traffic to the router itself. Unless you expressly want to open a port.

If you want to admin your router from external you should use a VPN or if you upgrade your router to the latest v7 release you could use Mikrotik's BTH feature or roll your own wireguard connection.

Thank you. That's what I thought. I don't want to admin my router from outside, I was just using that as an example of something that would use that kind of rule.

Question 2.
So traffic coming in goes though the rules as they are laid out in order on my screen right? Regardless of "chain"? In other words since my input rules are listed first then traffic would go through input rules first and then to the forward chain rules next right? And so on until it reaches the end of all rules, and if no rule applies to it then it would be accepted, correct?

So lets say I have the input rule I was using as an example, which would allow traffic from say my office IP address to the device itself. So traffic coming in that is from that src address would pertain to that rule so it wold then forward that traffic to the device (accept) and that would be the end of processing because the traffic was accepted. Traffic that does not pertain to that rule, I assume, would then go to the next rule in order, regardless of chain, until it goes through all rules. That traffic, reaching the end, if no rule applied to it, would then be accepted, correct?

No traffic doesnt go from input to forward,
Traffic to the router ( using router services) only goes thru input and is either matched or not matched
Traffic through the router ( LAN to LAN, LAN to WAN, WAN to LAN) never sees the input chain.

Get familiar with:
https://help.mikrotik.com/docs/spaces/R ... n+RouterOS

This is a nice starting jpeg, to print and look at while looking at the specific diagrams and discussion on the link.
viewtopic.php?p=1144680&hilit=packet+flow#p1144680

Very little customization is needed from default......
Basically the change most make is change from drop some accept everything else TO: identify known traffic needs drop everything else.

So traffic coming in goes though the rules as they are laid out in order on my screen right? Regardless of "chain"? In other words since my input rules are listed first then traffic would go through input rules first and then to the forward chain rules next right? And so on until it reaches the end of all rules, and if no rule applies to it then it would be accepted, correct?

Not exactly, from what I understand traffic is categorized, then it goes only through the appropriate chain rules.

Traffic belongs EITHER to chain=input OR to something else.
Traffic belongs EITHER to chain=forward OR to something else.
Traffic belongs EITHER to chain=x OR to something else ...

There is not a predetermined order among different chains, but the order of rules is strictly respected within a SAME chain.

It is good practice to group (for readability) all rules belonging to a same chain together (and traditionally the input chain is the first one), but a packet that needs to go through the device (forward) will never hit any input rule and viceversa traffic targeted to the device (input) will never hit a forward rule.

Ah, OK got it. So traffic comes in and the router sends the traffic to the appropriate chain. That traffic then gets processed in that chain and is either accepted or dropped by that chains rules and that's the end of it for that particular traffic. So traffic coming that is designated for a device on the LAN like a PC goes to the forward chain and is processed and never goes through the input chain.

Yes Anav. Since you were my mentor all those years ago my default is to allow what I want and drop everything else. It appears that this is not set that way by default, but I'm looking at the topic you posted where you're default rules are and I think I'll get there. But first a few more things so I get a more complete grasp...

Question 3.
What is untracked?
I know what established and related are but I don't know what untracked traffic is.

I will leave that to experts, but dont be concerned having that in the rules.

Only as a side note the (nicely looking and colourful) flowchart posted by chechito and linked to by anav is seemingly wrong/incomplete.

The rhombus/diamond shape (purple in the mentioned diagram) is a "decision" so it MUST have two exits.

In the diagram the top left "Routing decision" (with input coming from pre-routing) is correct (choice between input and forward) but the other two have only one exit:

The one with input coming from Local Process leads to EITHER Output connection tracking OR to a suffusion of yellow.

As well the "Routing adjustment" one leads to EITHER Mangle postrouting OR to a (same or different) suffusion of yellow.

What is untracked?
I know what established and related are but I don't know what untracked traffic is.

Packets that are not tracked by connection tracking machinery. ROS supports tracking IPv4 and IPv6, in theory there could be other protocols routed ... but not in practice as ROS doesn't support any other L3 protocols for routing either.
So these days it's more probable that certain traffic is explicitly excluded from connection tracking by setting appropriate rule in /ip/firewall/raw section. There's at least one, slightly rarely happening, scenario where "untracking" certain traffic makes sense because one traffic direction bypasses firewall and for TCP traffic this upsets firewall to the point it considers such traffic invalid.

The "WHY" is important... For example, maybe using the "interface-list" (which is what default one does) is too limiting... but perhaps modifying defaults to use "address-list" might be all that's needed. Another example be that @anav/others often suggest allowing what traffic you need, and having a drop all at end (while default use the !LAN to do it one line) – but this really just a few changed lines from default FW.

My recommendation to try to understand EVERYTHING in the default firewall BEFORE trying to create your own. There is a LOT of subtle things going on there...

And, if you want to "play" around with default first... you can use log=yes on some of the default rules as this shows WHAT "matched" what rules. This might give you a better sense of how it works since logs would show the IPs involved and what happened.

Most of your questions on input can be answered by MikroTik excellent "Packet Flow" diagrams: https://help.mikrotik.com/docs/spaces/R ... n+RouterOS
But... some tacit understanding of those packet flows should be a prerequisite to "custom" rules — since it VERY easy to leave the routing unprotected as many rules depend on other rules.

My recommendation to try to understand EVERYTHING in the default firewall BEFORE trying to create your own. There is a LOT of subtle things going on there...

And it is also Rule #8 of the Mikrotik Club:
viewtopic.php?t=215004

Thank you mkx. I don't understand but it would seem that what we're saying here is that there is certain traffic that is not tracked by connection tracking (which is what I assume we're talking about here) and that that traffic is generally not a threat. I will defer to the engineers here and say good enough for me. So untracked traffic is not specifically something to worry about. I hate not knowing things but to stay on topic I'll leave that question for another day since it doesn't seem important to the topic of my general firewall rules.
That said onto the next question...

Question 4
I think default rule #4 for CAPsMAN is not needed for me since I don't use that?
And, for that matter, rules # 6 & 7 for ipsec policy since I don't believe I use them either?

Correct if just starting out IPSEC is advanced and capsman only if using MT wifi, which is a recipe for hair graying or hair loss and wasted time.

Amm0,
yes, when I say that I want to make "my rules" I don't mean trash everything and create my own rules. I would like to stay as close to default as possible and adjust to what I need. But as I said before I'm not completely new to firewall rules, just how mikrotik implements them. I just want to make sure that I am as secure as possible with the configuration that I have created. Default rules seem almost there but I do think I would like a few changes. For example getting rid of the ipsec and CAPsMAN. Not important probably but would make things easier to see and keep track of. And , after all, trying to understand before I screw things up is exactly what I'm doing now by asking all these questions. So far I have not changed anything, but I think I'm starting to get close.
So ...
Question 5
There is an input rule that allows traffic that is established/related. I assume this means that by default it allows traffic that originated from the router/device and goes out to either the WAN or LAN. I assume that this is necessary for LAN so that it can do it's job as a server. I also assume that this is needed on the WAN side for the same thing but as a client to my ISP?

established related and fastrack are ways the router handles following packets after dealing with the original packets, for efficiency purposes.
Again details best left to experts.

Fair enough. The reason for the question was that, at first thought, I was thinking why would the device itself have to initiate any communication? But after thinking about it I thought that it is probably what I said above; in order to it's routing job and on the WAN side to do its client job.
Last question before I start propose a few rules.

Question 6
There is a rule on the input chain that drops everything NOT coming from the LAN. So I assume that this would block any traffic (not already dealt with by a previous rule) that comes from the WAN then? So it would block anyone trying to access the device itself from the internet?
And, as I think about it, it should also allow any traffic from the LAN to the router itself, right?

Dear OP.

you've been given sound advice by the Esteemed Forumers. This is just my take on answering your questions; it might be easier to follow, or not

When you want to do firewalling, there are certain things you have to be aware of. In no particular order.

In the networking stack, the packets follow a path described by the packet flow diagram. There are many versions of it, my favorite is this one
https://stuffphilwrites.com/2014/09/ipt ... flowchart/
The only difficulty you may have with this, is that it's labeled based on iptables (so general linux) terminology, but it's actually accurate and useful. Mikrotik exposes this system through it's configuration almost exactly, so it's only a matter of translating some names. (You should just disregard the boxes labeled "security" - these are not available and were thought up for a quite specific purpose. These not existing doesn't in any way imply any security risk.)

The firewall is consulted at many different points during a packet's journey. These involve the execution o a specific chain. So to answer one part of your series of questions: the order in which the rules from *different chains* are placed or interspersed have no bearing on their execution. It is customary to keep the rules for a given chain together, but that's just for us humans.

In a given chain, the rules are evaluated in strict order. This means that *within* a given chain, the order of the rules matters, and is actually very important. The rules always have a "match" part, that is: for what packets should this rule be triggered. And the rules have an "action" part, that is, when a match occurs, what should be done. The fate of the packet is decided by the first rule that contains a "final" action; that action is then taken and no further rules (in that chain) are executed, nor even consulted. What exact actions are "final" is documented in the Mikrotik help pages, but it's kind of obvious based on what they do: "accept", "deny" - the ones most routinely used in filter rules are final. Some actions (such as "add source address to address list", do what they say, but basically only as a side effect - the packet's fate yet undecided, processing continues.

One of the major features of the firewall is connection tracking. IP is - by its design - a connectionless protocol. However we find it *extremely* useful to associate packets with a connection they "seem" to be part of. "Seem" if written, because this connection and its state only exist in the "mind" of the router, and are based on observation of the headers of packets passing through it, and therefore might not match what the actual endpoints of the connection think of the connection.

Connection tracking (very roughly) enabled two major things, which we like very much:
* Allowing connections based on where (on which side, network, etc.) they were *initiated* from. A typical example is that we want to allow internal (LAN) devices to be able to initiate connections to the outside world (WAN), however we want to deny initiating connections in the opposite direction. The key word I keep using here is "initiated", because of course WAN->LAN traffic should be allow if (and only if) it is a response to something initiated from the LAN side - this is where connection tracking comes in: we have to remember that there was an outgoing packet, and be able to associate the reply with that connection.
* Allowing the usual NAT. WAN-side outgoing messages have to have their source address altered to (the usually single) routable IP address provided by the ISP. Response traffic will then be addressed to the external address, and so has to be translated to the address of the device who sent the outgoing packet - thus again we have tot make note of these connections to be able to do this correctly.

Mikrotik allows you to turn of connection tracking altogether. This is done only is special cases. The firewall also allows you to specifically instruct it not to apply connection tracking to certain packets - this is done in the "prerouting" chain, with the not so creatively names "notrack" action. Again, this is special configuration. I am only writing these things down because you ask; I've known people who have configured firewalls for decades (and did so in an appropriate and secure way,) who didn't have to deal with any of this. I suggest that you leave these for later.

A packet that has gone though connection tracking has a "connection state" assigned. It is assigned *exactly one* of these: new, established, related, untracked. In order:
* new: we tried looking up this packet, but see no connection we can associate it with; if this packet is accepted, a new conntrack entry will be created
* established: we have a conntrack entry for this packet (so basically it isn't the first packet of the connection)
* related: this is special one; sometimes there are packets that can be associated with a connection, but don't match the signature; a typical example is that one of the routers forwarding your packet sends an ICMP error or advisory, such as: Destination unreachable, No route to host, Fragmentation required, Lifetime exceeded, etc. Generally these are treated the same as established.
* invalid: we have a conntrack entry, but something is off with the flow of packets (this is the assigned state e.g. when one side has sent a message closing a TCP connection, and there is further sent from either side.) - these packets are usually dropped
* untracked: the firewall was explicitly instructed not to engage the conntrack machinery either for lookup or possibly to introduce a new entry

Regarding Mikrotik's default firewall ruleset. These are well written and provide the recommended basic level of protection that's considered adequate. (Most consumer type routers apply a very similar set of rules, just most don't expose the configuration.)

However, I think that Mikrotik's rules are written a bit too cleverly. I must state again that the rules are absolutely correct as written, the following is just a bit of philosophical nit-pickink:
* Some of the rules do "too much" in one go. For example the fasttrack rule has an exception for ipsec. This is fine and correct, because you want to exempt ipsec traffic from fasttrack, however this can be more clearly written in two rules. The same goes for others.
* The firewall system allows you to "program it" in many different ways to achieve the exact same behavior. I think that the rules generally reflect the thinking of the one creating them. I generally like organized thought. This is why I usually filter based *not* on what to block, but describe/list specifically what I want to *allow*, and drop all else. I think this is the correct way of thinking about things.

As to your last remark, filtering basically involves three chains:
* input - traffic addressing the router *itself*
* forward - traffic forwarded by the router (generally between two networks)
* output - traffic that is generated by the router itself

So what you are referring to in your last post (if I understand correctly) is traffic initiated by the router itself, let's say for example a DNS request. The outgoing packet traverses the output chain. (The output chain is usually left empty, and by default it is therefore accepted.) Together with accepting the packet, a conntrack entry is created. The reply packets traverse the input chain and because they have an associated valid onntrack entry, their connection state is established.

Regarding your question 6: You understand correctly, this rules blocks all connection not from the LAN, so it block connection from WAN, etc.

You are also correct that this allows all types of connections from any device in the LAN. Whether this is correct is a matter of perspective: Is this what you want?

I generally like to list any sort of access to the router and specifically allow it, and drop all others. This means that I usually only enable access to the admin interfaces that I actually intend on using. However the "allow everything from inside" is a usual base configuration, and would probably not get you into (much) trouble. Ultimately you decide: having finer grained control is always better, but it also requires that you think about your exact needs and implement the solution.

I think I understand enough now. Below is a pic of the way I set up my rules. Everything seems to be working fine so as long as no one sees anything wrong with it I think I'm good.
Thank you all very much for your help. Very much appreciated. Now on to my less important but more interesting questions

It's much easier on all of us if you post your configs in text form from
/ip/firewall/filter export

(and there are parameters that are not shown in the GUI by default.)

Please use code tags (the button resembling </>)

Your firewall rules look roughly good. I would *really* suggest the allow-what-I-want-and-drop-everything-else mindset. It's much easier to do correctly and later maintain it.

Gee, I thought I was doing the "allow-what-I-want-and-drop-everything-else". What am I missing?

Thanks for the text export.

You're *almost* doing the suggested approach. Except where you're not By this I refer to the two drop rules denying cross-network traffic between what I assume to be two internal networks 192.168.88.0/24 and 192.168.2.0/24.

While every principle is there to be disregarded sometimes (and what you are doing is not in any way terrible) - I would formulate the rules in a qay that focuses on what is allowed, instead of what is disallowed.

I only guess at your intent here, and if I guess wrong, either correct my proposed solution to suit your use case, or just state it clearly, and I'm happy to help. I assume you mean that each subnet is allowed to access external addresses (i.e. the internet), but they're not allowed to access each other.

In this case my usual solution is to have an address list for internal networks,
/ip/firewall/address-list add list=internal address=192.168.88.0/24
/ip/firewall/address-list add list=internal address=192.168.2.0/24

And then simply allow traffic that is going to the outside (i.e. dst-address is not in the internal list):
/ip/firewall/filter add chain=forward action=accept src-address=192.168.88.0/24 dst-address-list=!internal
/ip/firewall/filter add chain=forward action=accept src-address=192.168.2.0/24 dst-address-list=!internal

In this particular case they can be contracted to:
/ip/firewall/filter add chain=forward action=accept src-address-list=internal dst-address-list=!internal

Whether you want to do certain contractions or not depends on how your network is structured in general. It is not always best to have the lowest possible number of rules, what is important is that they make sense to you. (And will do so even if you revisit the config months from now.)

@lurker888
You are complicating my view on firewalling factions, I thought one had to decide which gang to join, the rextenders or the anavites, it seems like there is a third one now, the lurkerans, right in the middle of the two.
It Is difficult to define that position, it seems like they could be called either tolerant rextenders or respectful anavites, each one clearly being an oximoron.

Not a lurkerite......... its a false option ;-PP

General rule of thumb for firewall rules is that
--> Interface lists are better designed to handle whole subnets.
--> Address lists are great when anything less than a whole subnet is involved with or without whole subnets ( could be users in one subnet or across many subnets)
--> For a single subnet simply use subnet address.
--> One exception to the above is that single subnet maybe the only subnet constituting an interface list (ex vlan99 interface-list=MGMT )

In the OPS example he has is not using a bridge or maybe one subnet is on the bridge servering ports 2,3,4 and one is off the bridge using ether5.
Could be two different vlans.
The whole point of the last rule block all else, means anything with the chance of connecting at layer 3 will not connect.
Thus the two rules are NOT required and should be removed. The router has no L2 connection path for these two separate subnets.

add action=drop chain=forward comment="drop LAN1 to LAN2" dst-address=\
192.168.2.0/24 src-address=192.168.88.0/24
add action=drop chain=forward comment="drop LAN2 to LAN1" dst-address=\
192.168.88.0/24 log=yes src-address=192.168.2.0/24

This rule blocks connectivity between them....
add action=drop chain=forward comment="drop all else"

Furthermore you have redundancy by keeping default rule and instituting new good rules.
Namely get rid of this rule.
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN

If you can note, its designed to allow lan to wan traffic, and block Wan to Lan traffic except if port forwarded traffic, all to cute. Also hidden besides lan to wan allowing,
is that this rule also allows LAN to LAN traffic.........which we want to control not allow unknowingly!!
Much better is what you already added:
add action=accept chain=forward comment="LAN to WAN internet traffic" \
in-interface-list=LAN out-interface-list=WAN

what is missing is the port forward stuff covered by adding.
add action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat enabled=no { enable if required or remove.}

Done..........

+++++++++++++++++++++++++++++++++++
As for Lurkers lists............ an excellent idea if one wants to identify local connected networks on the router for mangling purposes and mangling rules.

And, as I think about it, it should also allow any traffic from the LAN to the router itself, right?

Yes but the fact that you have to double check yourself speaks to the lack of clarity of rules.
Much better to state cleanly
add chain=input action=accept comment="Lan users to router" in-interface-list=LAN
add chain=input action=drop comment="drop all else"

Great for one user aka only the admin, but no one other than the admin requires access to the router for config purposes, so we carve out the users.
add chain=input action=accept comment="admin access" ****************************************
add chain=input action=accept comment="Lan users to dns/ntp services" in-interface-list=LAN dst-port=53,123 protocol=udp
add chain=input action=accept comment="Lan users to dns services" in-interface-list=LAN dst-port=53 protocol=tcp
add chain=input action=drop comment="drop all else"

***************************** many options here.
in-interface-list=MGMT
src-address-list=TRUSTED
in-interface-list=MGMT src-address-list=TRUSTED

to name a few..................

@jaclaz: You're too kind to assign me my own faction. I was under the impression that there are no factions and the usual posters around here (including me) are saying the same thing:
* the default firewall is actually a good... well... default - so if you don't have a good idea of what you're doing leave it in place
* well configured firewall good - misconfigured or no firewall bad
* allow what you want, block everything else
+1: don't create a collection of overly complex rules worthy of a magpie from too clever but often not very well informed Youtube videos

@anav: Blocking by source IP or ingress interface is basically the same. (For most home/office uses a proper network design usually has a single subnet per interface.)

What I was not going to discuss initially, because it never came up in these discussions organically, and I didn't want to go off on a total tangent, but... either filtering by source address or in interface actually allows source address spoofing. (They do so in the opposite "directions", and of course source spoofing is generally useless for TCP, and custom TCP-functionality-over-UDP protocols, such as QUIC.) With both approaches proper source address validation should be done in some way: the easiest for simple networks is setting RPF mode to strict.

Speaking of @tangent, there is also his excellent guide that walks through the firewall in more detail:
https://tangentsoft.com/mikrotik/wiki?n ... figuration

And I put @Kentzo postings as a "firewall faction", with philosophy of let's all be good citizens (e.g. using action=tcp-reset/icmp, instead of "Anav-ism's" action=drop), see viewtopic.php?p=1140557

With both approaches proper source address validation should be done in some way: the easiest for simple networks is setting RPF mode to strict.

That a good point. To be clear, "RPF mode" is:
While agree that rp-filter=loose is a good idea (and should be - but is not - the default). And if possible rp-filter=strict be a good idea — but that has side-effects if do anything more complex with routing (i.e. multiwan, VPNs, etc.) and so "strict" can break things.

With both approaches proper source address validation should be done in some way: the easiest for simple networks is setting RPF mode to strict.

That a good point. To be clear, "RPF mode" is:

Code: Select all

/ip/setting rp-filter=<off | strict | loose>

While agree that rp-filter=loose is a good idea (and should be - but is not - the default). And if possible rp-filter=strict be a good idea — but that has side-effects if do anything more complex with routing (i.e. multiwan, VPNs, etc.) and so "strict" can break things.

Unless you do not have a default route (0.0.0.0/0) in your FIB for the table that handles the interface in question, then rp-filter=loose is essentially rp-filter=off. From my point of view, rp-filter in general is only really useful when you are defining all of your routes and are not using a default route otherwise you might as well turn it off because it isn't doing anything. For the typical user, whether homelab, SOHO, university, and medium enterprise you will have some kind of default route for general WAN access and in this situation rp-filer=loose is not doing anything for you. Additionally, a properly designed firewall will drop packets coming from the WAN interface(s) that are not whitelisted or dNat'd to some specific service. Of course that leaves internal LAN clients to perform spoofing attacks which is always possible but if this is your threat model then you again should design your firewall to be more restrictive and not forward everything by default. TLDR, don't look at rp-filter as some kind of security feature, it's use cases are limited and really only beneficial when rp-filter=strict.

@Amm0 and @blacksnow: both your comments about RPF are appreciated. "Loose" mode only checks that there is a reverse path (through *any* interface), and therefore in this scenario it's pretty useless. "strict" checks that the reverse path - when looked up - not only exists but leads through the ingress interface. It may be useful against source IP spoofing - and this is explicitly mentioned in several RFCs for best practices for network operators, including ISPs.

The state of RPF is not ideal in RouterOS, because it is not a per-interface setting. (The kernel has the capability of configuring this in a per-interface manner, so this would only require a ui change.)

The firewall can be used to filter these sorts of packets, and it actually takes very little to integrate this into any firewall design I've seen. I do it as a matter of routine. I intentionally don't make recommendations like this in response to questions that are seeking some initial understanding of firewall fundamentals, because even though it may be simple and straightforward for someone used to reading firewall rules, any added intricacy may in fact detract the poster from their original goal and cause them to abandon establishing a better firewall: and in this sense I'm afraid that pursuing the perfect may be at odds with achieving "good enough". I try to pick my battles.

As to the argument that if "anything internal is doing the spoofing, then you have bigger problems"... In terms of IT security we're living a strange world. I've seen examples where if basically *any* public/guest type usage of your network is permitted, you will encounter devices that are somehow acting under the control of malware, possibly as part of botnets, and do their things accordingly. In my region it's basically expected for any sort of business, coffee shop, hostel, etc. to provide internet access to their clients - it's assumed to be most simple curtesy. By public/guest access I don't mean that e.g. WiFi access is not password protected, but that (almost) anyone can ask for the password, and the devices they connect are not scanned, validated, preapproved, etc.

@jaclaz: You're too kind to assign me my own faction. I was under the impression that there are no factions and the usual posters around here (including me) are saying the same thing:
* the default firewall is actually a good... well... default - so if you don't have a good idea of what you're doing leave it in place
* well configured firewall good - misconfigured or no firewall bad
* allow what you want, block everything else
+1: don't create a collection of overly complex rules worthy of a magpie from too clever but often not very well informed Youtube videos

Yep , that is exactly the mid-way position I was talking about, between the two existing absolute positions:
1) Leave the default firewall as is! Don't touch it! (whatever you change in it will almost invariably be wrong, dumb or dangerous)
vs.
2) Immediately change the firewall! identify wanted traffic and specifically allow that! Drop all else! Now! (whatever else will almost invariably be wrong, dumb or dangerous)

I think that there is wide agreement on the default input rules, that are actually made with the philosophy of a "drop all else" (limited to "from WAN") rule at the end.

The debate (if any) is about the forward rules.

Noone seemingly wants to actually risk their setup with the simple (maybe too simple or stupid? ) experiment I proposed some time ago.
1) have the default firewall UNCHANGED
2) add AFTER the "defconf: drop all from WAN not DSTNATed" rule:
a) some (the needed/intended ones) explicit "accept" rules
b) as last rule the "drop all else" catchall one

If the default firewall is actually good, rules 2a) and 2b) should never be hit.
If *something* arrives past #2 (and is caught by either 2a) or 2b) then going through the trouble of changing the default firewall has some merits.

Of course there may be particular setups where you need anywyay to modify the default firewall, and if you do the "drop all else" at the end of the forward looks simpler and probably it is safer against possible mistakes in the earlier modified rules, but those should be exceptions in particularly complex (or complicated) setups.

About the (very nice ) iptables diagram you posted a link about:
https://stuffphilwrites.com/2014/09/ipt ... flowchart/
do you think we can derive from it an "ultimate flowchart" specifically applicable to Mikrotik RoS by removing the "security" blocks and correcting the (as I see it) inconsistencies?[1]
If you are game for it, I could try doing my best re-creating an editable version, but I am not knowledgeable enough in either general Linux iptables or specific Mikrotik's behaviour to actually validate the result, and need your review and corrections.




[1] just like the mentioned vagueness on the flowchart posted by chechito mentioned earlier, this one has ambiguous "Routing decision" blocks, in this case the routing decision is represented in three instances as a rectangle with side bars (Predefined process) and so it is NOT a decision, that MUST be a rhombus/diamond and have two exits.

Yep , that is exactly the mid-way position I was talking about, between the two existing absolute positions:
1) Leave the default firewall as is! Don't touch it! (whatever you change in it will almost invariably be wrong, dumb or dangerous)
vs.
2) Immediately change the firewall! identify wanted traffic and specifically allow that! Drop all else! Now! (whatever else will almost invariably be wrong, dumb or dangerous)

As I put a little more thought into it, you might actually be more right about my position than I hastily was.

Just to clarify:
1) I agree with, with the clarification: only break this rule if you know what you're doing. and
2) the big danger of allowing traffic to "fall through" a chain where you intend to do filtering, is that - while initially the setup may be totally correct - if you later modify your network without adjusting the firewall related settings (which would include interface list and address list memberships), you're quite likely to let though more traffic than you intend. The "drop all else" part handles this well - if you haven't modified your ruleset to allow what you want, things won't work and you will be forced to investigate. In the case of allowing too much, no such investigation is "forced" and the error is only highlighted after possibly something bad has happened. In this sense the "drop all" is a form of self-imposed discipline.

[...]
Noone seemingly wants to actually risk their setup with the simple (maybe too simple or stupid? ) experiment I proposed some time ago.
1) have the default firewall UNCHANGED
2) add AFTER the "defconf: drop all from WAN not DSTNATed" rule:
a) some (the needed/intended ones) explicit "accept" rules
b) as last rule the "drop all else" catchall one

If the default firewall is actually good, rules 2a) and 2b) should never be hit.
If *something* arrives past #2 (and is caught by either 2a) or 2b) then going through the trouble of changing

I'm willing to do any such experiment (within reasonable bounds of effort involved.)

I actually construct my firewall rules like this, and have for a long time done so. I can confirm that they work absolutely fine. And as you propose, the last "drop all" rule is very rarely hit. The rare hits are because some devices with built-in firmwares (yes, from the usual suspects) have networking stacks that become - let's say - confused. I have actually logged these packets, and they are invariably malformed.

I'm actually planning on putting up on this forum a "defconf script with vlan filtering" script, which employs such a firewall setup. An excerpt from the forward chain:
(I tend to use address lists instead of interface lists, as you might have guessed from the above.)

About the (very nice ) iptables diagram you posted a link about:
https://stuffphilwrites.com/2014/09/ipt ... flowchart/
do you think we can derive from it an "ultimate flowchart" specifically applicable to Mikrotik RoS by removing the "security" blocks and correcting the (as I see it) inconsistencies?[1]
If you are game for it, I could try doing my best re-creating an editable version, but I am not knowledgeable enough in either general Linux iptables or specific Mikrotik's behaviour to actually validate the result, and need your review and corrections.

[1] just like the mentioned vagueness on the flowchart posted by chechito mentioned earlier, this one has ambiguous "Routing decision" blocks, in this case the routing decision is represented in three instances as a rectangle with side bars (Predefined process) and so it is NOT a decision, that MUST be a rhombus/diamond and have two exits.

It would be absolutely nice to create a Mikrotik-specific version of it. The good thing about this particular diagram is that it was actually created by a long standing contributor to netfilter, and is actually correct and unambiguous. Most of the other versions have some parts that are either unclear or when applied to certain edge cases, simply wrong.

What would need to happen for it to become Mikrotik-specific is two simple things:
* remove or cross out the security chains - these are only applicable to installs using SELinux
* Mikrotik has a slightly different naming scheme for the firewall tables/chains, and while it can be figured out with a minimal effort, I think it would be helpful to actually have the Mikrotik naming right there (I would actually prefer if the original iptables name was also present in small print, but that's just my preference)

If you are willing to do that work, I think many would be grateful. I'm willing to provide the translations.

About your [1]: The routing decision is a "decision" in that the packet is handed off to the fib_* calls in the kernel that deal with selection of ("deciding on") the route to be used and the nexthop. It is not a "decision" in the flowchart sense of the word. Depending on the result of this decision the packet quite often proceeds in different ways, but the "routing decision" step only annotates the packet (with e.g. its expected egress interface) and the actual points where what happens to the packet diverges are specified as firewall rules matching on these additional annotations. So again, the divergence in path is *related to* the routing decision, but it's not actually performed *in that step*.

...

@lurker888
Attached a re-working of the IP tables diagram (only removed the yellow security-related boxes).
In .png and .svg (inkscape) formats.
Boxes are numbered from 1 to 27.
Tell me, with a list 1 to 27, which text should go in each box (and please find a synonym for the "Decision" in process boxes) to make it more Mikrotikish (and what text in Linuxese/iptablian should be put in smaller characters in the same box if different).
Then I will try to make it a little more pleasant to the eye (I might need to resize some boxes to fit the text in it), re-aliogn the boxes chack the connection arrows, etc.

In the OPS example he has is not using a bridge or maybe one subnet is on the bridge servering ports 2,3,4 and one is off the bridge using ether5.
Could be two different vlans.

Kinda, remember from the other topic that I created a separate "guest" LAN2 and so I (against your advice) created a second bridge (and second everything else needed) for my LAN2. 2 ports on LAN1 and the other 2 are on LAN2.

The whole point of the last rule block all else, means anything with the chance of connecting at layer 3 will not connect.
Thus the two rules are NOT required and should be removed. The router has no L2 connection path for these two separate subnets.

add action=drop chain=forward comment="drop LAN1 to LAN2" dst-address=\
192.168.2.0/24 src-address=192.168.88.0/24
add action=drop chain=forward comment="drop LAN2 to LAN1" dst-address=\
192.168.88.0/24 log=yes src-address=192.168.2.0/24

This rule blocks connectivity between them....
add action=drop chain=forward comment="drop all else"

So if I understand you correctly, traffic between my LAN1 (192.168.88.0) and my LAN2 (192.168.2.0) is already blocked by the last "drop everyting else" rule, thus the 2 rules I created to block that traffic are not needed? You are pretty clear but I just want to make sure that I am understanding you right.

Furthermore you have redundancy by keeping default rule and instituting new good rules.
Namely get rid of this rule.
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN

If you can note, its designed to allow lan to wan traffic, and block Wan to Lan traffic except if port forwarded traffic, all to cute. Also hidden besides lan to wan allowing,
is that this rule also allows LAN to LAN traffic.........which we want to control not allow unknowingly!!
Much better is what you already added:
add action=accept chain=forward comment="LAN to WAN internet traffic" \
in-interface-list=LAN out-interface-list=WAN

This I'm not as clear on. I don't need the DSTNATed rule at all anymore because I created the LAN to WAN rule and drop all else rule? (I'm not doing any port forwarding that I know of)

what is missing is the port forward stuff covered by adding.
add action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat enabled=no { enable if required or remove.}

Done..........

@jaclaz: Nice work.

Obligatory nitpick: you missed the outgoing arrow for NAT postrouting.

Regarding the "routing decision" thing: I tend to agree with you that an alternative wording would better convey what's going on. The actual function (if I recall correctly) is called fib_lookup_in_table(), so "FIB lookup" would be most accurate. I also think that's kind of opaque and hard to understand, so I suggest "routing lookup". I also would like to make it clear that for locally originated packets there is an "inital" and a "final" lookup.

Please bear in mind that I'm used to seeing the in-kernel terminology, but however precise that might be, that in itself is not a guarantee that it's useful to the intended audience. What I'm saying in so many words is: if you see a more natural way of saying things, I'm all for it!

Also, I'm a bit conflicted on whether the actual iptables names aren't more confusing than actually useful. Anyway, while I'm at it, I'll put it here, and you can decide whether to include it or not.

I think that given that we're talking about Mikrotik products, instead of "local", "localhost", "local process", we can be simply refer to the router as "router". That it's actually a host that is also a router, etc. is just a pointless distinction.

Here goes: (Mikrotik names normally, iptables names in parentheses)
1. incoming packet
2. raw/prerouting (raw PREROUTING)
3. connection (state) tracking
4. mangle/prerouting (mangle PREROUTING)
5. src addr is router's addr
6. NAT/dstnat (nat prerouting)
7. routing lookup
8. dst addr is router's addr
9. mangle/input (mangle INPUT)
10. filter/input (filter INPUT)
11. NAT/input (nat INPUT)
12. packet delivered to router's internal process
13. mangle/forward (mangle FORWARD)
14. filter/forward (filter FORWARD)
15. from around kernel version 5.3 (if I recall correctly) this means absolutely nothing; in the 3.x days it used to have *some* meaning, but even that's fairly obscure
16. mangle/postrouting (mangle POSTROUTING)
17. dst addr is router's addr
18. outgoing packet
19. packet generated by router's internal process
20. initial routing lookup
21. raw/output (raw OUTPUT)
22. connection (state) tracking
23. NAT/output (nat OUTPUT)
24. mangle/output (mangle OUTPUT)
25. final routing lookup
26. filter/output (filter OUTPUT)
27. NAT/srcnat (nat POSTROUTING)

Looking over the list, only 6 and 27 have different names in Mikrotik and iptables. (At least I went through all of them methodically...) Maybe it would be worth showing the iptables chain names only for these? - the rest are fairly easy to guess

@jaclaz: Nice work.

another nit... is it does miss the case of encapsulated protocols like IPSec – which the default firewall does subtly handle in filter and NAT rules.

Yep, forgot last arrow.
I like the initial and final routing lookup (#20 and #25), it makes sense to the reader and keeps the distinction between the two otherwise identical boxes.
Do we need an attribute for #7? Like "preliminary"?

So #15 can be simply removed, right? Or maybe visually more pleasing use instead of a box an empty triangle pointing downwards (Merge symbol)?

I think it makes sense to have PREROUTING, RAW, INPUT, etc. *somehow* differentiated from "normal" text like "incoming packet" or "routing lookup", I'll think if I can come out with something visually easy to interpreter (CAPITAL/Bold/Italic/*something*).

To somehow "lower" the level of abstraction, since there is in practice no distinction between Iptablian and Mikrotikish exception made for #6 and #27, instead of repeating the same things twice in every box, I would like to add where appropriate the path where the settings are in Mikrotik settings, *like*:
/ip firewall raw
/ip firewall mangle
/ip firewall filter chain=input
/ip firewall fiter chain=forward
etc.
...

What do you think?

@Amm0
I would gladly accept the nitpick, if only you could explain how it works (though I am afraid that if we include *something special* for IPSEC; next will be wireguard or BTH or whatever else, making an easy readable flowchart a nightmare to read).

To show how I personally understand how IPSEC works BOTH in Iptables and in Mikrotik, here is a separate (simple) diagram :

With all do respect to the help you have all given me, which is tremendously appreciated, can I have a little bit for anav to respond to my previous post about the firewall rules before we go on about this table thing?

This must be readed:
viewtopic.php?p=1126975&hilit=default+firewall#p1126789
and this:
viewtopic.php?p=1126975&hilit=default+firewall#p1126843
and this:
viewtopic.php?p=1126975&hilit=default+firewall#p1126890

Yep, forgot last arrow.
I like the initial and final routing lookup (#20 and #25), it makes sense to the reader and keeps the distinction between the two otherwise identical boxes.
Do we need an attribute for #7? Like "preliminary"?

I think not This is the point. The repeated lookup is only done for locally originated packets. For packets that are not locally originated only a single lookup happens.

So #15 can be simply removed, right?

Yep.

I think it makes sense to have PREROUTING, RAW, INPUT, etc. *somehow* differentiated from "normal" text like "incoming packet" or "routing lookup", I'll think if I can come out with something visually easy to interpreter (CAPITAL/Bold/Italic/*something*).

To somehow "lower" the level of abstraction, since there is in practice no distinction between Iptablian and Mikrotikish exception made for #6 and #27, instead of repeating the same things twice in every box, I would like to add where appropriate the path where the settings are in Mikrotik settings, *like*:
/ip firewall raw
/ip firewall mangle
/ip firewall filter chain=input
/ip firewall fiter chain=forward
etc.
...

What do you think?

Everything you say makes sense.

@Amm0
I would gladly accept the nitpick, if only you could explain how it works (though I am afraid that if we include *something special* for IPSEC; next will be wireguard or BTH or whatever else, making an easy readable flowchart a nightmare to read).

To show how I personally understand how IPSEC works BOTH in Iptables and in Mikrotik, here is a separate (simple) diagram :
Mikrotik_Amm0_flowchart.svg.png

The normal IP level encapsulations, such as GRE, Wireguard, OpenVPN (in ip mode), etc. fit nicely: the underlay packet is routed normally to/from "router's local process" side. The overlay package is ingested and injected through the (virtual) interface of the tunnel.

L2 encapsulations, such as EoIP, L2TP, OpenVPN (ethernet mode), ZeroTier are handled similarly, but additionally bridging is involved.

IPSec (policy based) is special and nasty. That's why it's usually not incorporated into these diagrams. I would suggest that we avoid it as well. (BTW this is why there's the ongoing universal request for VTI support )

@xsentinel: I know that I've hijacked your thread. Apologies, and I really hope @anav is paying attention and will answer your questions.

hahaha , no problem as long as I eventually get my rules right.
If I understand anav correctly then I think this is what I have...

This config actually looks fine.

What I would do next is to restrict the accepted traffic from LAN (in input) to only DNS (53/udp and 53/tcp), ssh (22/tcp), webfig (80/tcp and 443/tcp) and winbox (8291/tcp). You're also fine if you don't - just a suggestion.

@xsentinel
Yep, sorry for the hijacking .

@lurker888
Let's move the discussion here :
viewtopic.php?t=217270

Nothing to apologize for. I appreciate very much all of you helping so much. I do believe at this point that I have a pretty good simple effective rule set for my purposes and I understand what each rule does and why.
At this point I believe that my mikrotik is set up and secure and it is all thanks to you all. I still want to learn more and I have more questions, but, since I feel this thing is properly set up and secured, they are not mission critical so I'll be posting them separately.

Once again thank you all. Very much appreciated.