Thank you but I’m not seeking that can of guidance. I don’t want a specific analysis. I am interested in just this one aspect of FORWARD chain rules in general.
Even more specifically, my interest is in understanding the last couple/few of the FORWARS chain rules.
If it’s too much of a PITA, I understand.
Not really, your questions border on nonsensical without context.
All I can reply to most of them is it depends.
I am not about to give all the possibilities depending if you have this or that etc…
Suggest go back to basic videos etc.
I bought this book when I started and although not ver7 specific it does cover much stuff well.
Thanks. Please give me a day and I will try to make my confusion more easily understood.
The tyler hart one can be found at many places for ex… I know the tyler hart one can be found at multiple places such as ==>https://oceanofpdf.com/category/authors/tyler-hart/
In other words, you need to do some reading maybe network fundamentals, in conjuction with the discher book recommended. Will make more sense.
A little investment in time/education will a long way. There is one chap here who has an excellent network set of resources…
I havent looked at these, but he is well respected.
https://gregsowell.com/?page_id=951
Found it, buckeyes list.
http://forum.mikrotik.com/t/vlan-on-a-single-port/181354/5
Maybe my questions are irrational – wouldn’t be the first time they are.
Let me try one more time:
These are the recommend (by rextended) default FORWARD chain firewall rules:
/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related hw-offload=yes comment="defconf: fasttrack"
add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=forward action=drop in-interface-list=WAN connection-nat-state=!dstnat connection-state=new comment="defconf: drop all from WAN not DSTNATed"
The following rules are the subject of my curiousity. I did not create or craft these rules. I have seen them recommended repeatedly online here (I believe).
The following rule allows all frames that are dstnat. My understanding is that this rule is not necessary if the only other FORWARD rules in place are the 4 default rules above because the only rule that affects frames that are DSTNAT’ed in rule #4 above and that rule will allow all DSTNAT’ed frames. But, if we add some of the other rules below, then this rule might become necessary.
add chain=forward action=accept connection-nat-state=dstnat comment="allow port forwarding"
The following rule specifically allows all LAN to WAN frames. Here also this rule is not necessary if the only other FORWARD rules in place are the 4 default rules above.
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="allow all LAN to WAN forwarding"
The following rule drops all FORWARD chain frames. I understand that this rule in the last position is debated.
add chain=forward action=drop
The default forward rules represent, in short, this:
/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established comment="defconf: fasttrack estabilished"
add chain=forward action=fasttrack-connection connection-state=related comment="defconf: fasttrack related"
add chain=forward action=accept connection-state=established comment="defconf: accept established"
add chain=forward action=accept connection-state=related comment="defconf: accept related"
add chain=forward action=accept connection-state=untracked comment="defconf: accept untracked"
add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=forward action=accept in-interface-list=WAN connection-nat-state=dstnat comment="defconf: accept all connection from WAN DSTNATed"
add chain=forward action=drop in-interface-list=WAN out-interface-list=LAN comment="defconf: drop unsolicited connections from WAN to LAN"
add chain=forward action=drop in-interface-list=WAN out-interface-list=WAN comment="defconf: drop all coming from WAN to WAN"
add chain=forward action=accept in-interface-list=LAN out-interface-list=LAN comment="defconf: accept all connection from LAN to LAN"
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="defconf: accept all connection from LAN to WAN"
add chain=forward action=drop comment="defconf: drop all not coming from LAN or WAN"
Any consideration must be made in the default context.
If you start saying "but if the user changes"... then everything changes, obviously.
The same is for input:
/ip firewall filter
add chain=input action=accept connection-state=established comment="defconf: accept established"
add chain=input action=accept connection-state=related comment="defconf: accept related"
add chain=input action=accept connection-state=untracked comment="defconf: accept untracked"
add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"
add chain=input action=accept in-interface-list=LAN comment="defconf: accept all coming from LAN"
add chain=input action=drop in-interface-list=WAN comment="defconf: drop all coming from WAN"
add chain=input action=drop comment="defconf: drop all coming from unexpected sources"
And this is default output (no rule = allow all):
/ip firewall filter
add chain=output action=accept comment="defconf: accept anything, anywhere"
So with the default rules, a RouterBOARD can be a source of attack in various ways, not necessarily with a compromised filesystem.
Attacks towards both the LAN and the WAN indifferently.
If it is the RouterBOARD that initiates the connection,
then the rules that accept the packets related to the connections already established and those related do the rest...
Without thinking about all the nice things that can be done at level 2...
Here then the bridge firewall intervenes,
it also by default allows everything indifferently incoming on input / forward / output and it also has its NAT...
I took the default FORWARD chain firewall rules for 7.18beta5 from:
http://forum.mikrotik.com/t/buying-rb1100ahx4-dude-edition-questions-about-firewall/148996/25
Where you write:
/ip firewall filter
add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
add chain=forward action=fasttrack-connection connection-state=established,related hw-offload=yes comment="defconf: fasttrack"
add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=forward action=drop in-interface-list=WAN connection-nat-state=!dstnat connection-state=new comment="defconf: drop all from WAN not DSTNATed"
Above you write that the following is the expanded FORWARD chain rules:
/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established comment="defconf: fasttrack estabilished"
add chain=forward action=fasttrack-connection connection-state=related comment="defconf: fasttrack related"
add chain=forward action=accept connection-state=established comment="defconf: accept established"
add chain=forward action=accept connection-state=related comment="defconf: accept related"
add chain=forward action=accept connection-state=untracked comment="defconf: accept untracked"
add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=forward action=accept in-interface-list=WAN connection-nat-state=dstnat comment="defconf: accept all connection from WAN DSTNATed"
add chain=forward action=drop in-interface-list=WAN out-interface-list=LAN comment="defconf: drop unsolicited connections from WAN to LAN"
add chain=forward action=drop in-interface-list=WAN out-interface-list=WAN comment="defconf: drop all coming from WAN to WAN"
add chain=forward action=accept in-interface-list=LAN out-interface-list=LAN comment="defconf: accept all connection from LAN to LAN"
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="defconf: accept all connection from LAN to WAN"
Leaving aside the IPSEC rules, and the fasttrack, established, related, untracked, and invalid rules (that is, the first 5 default (non-expanded) rules (which I can readily see how they expand as you stated immediately above), we are left with the default rule #6:
add chain=forward action=drop in-interface-list=WAN connection-nat-state=!dstnat connection-state=new comment="defconf: drop all from WAN not DSTNATed"
I see now that this rule (#6) expands to 5 separate rules, some of them drop and some accept.
And, some of those rules are the rules that I am asking about. This clear up things up nicely.
Your one rule (#6):
accepts in-interface-list=WAN and connection-nat-state=dstnat and connection-state=new
drops in-interface-list=WAN out-interface-list=LAN
drops in-interface=list=WAN out-interface-list=WAN
accepts in-interface-list=LAN out-interface-list=LAN
accepts in-interface-list=LAN out-interface-list=WAN
And the following rule should simply not exist at the end of the chain?
add chain=forward action=drop comment="defconf: drop all not coming from LAN or WAN"
Is what I wrote correct?
Rextended is simply quoting the stock default rules that MT installs, he didnt make them up. Are they correct, is a meaningless question.
Correct for what?
No, it doesn’t … it expands into 1 explicit rule and 1 implicit rule if the quoted rule is the last in chain=forward … because implicit action of a chain (one of the default ones: input, output and forward that is) is to accept packet which does descend to the bottom of it.
explicit rule:
drops in-interface-list=WAN and connection-nat-state != dstnat and connection-state=new
which drops anything from WAN->LAN if not DST-NATed.
implicit rule:
accepts the rest
(which includes LAN->WAN and LAN->LAN connections … also anything else which does not involve WAN interface list). Your interpretation might be fine is you did set interface list membership correctly … which is what many inexperienced users forget to do properly … and immediately firewall consistency goes through the window (but without playing with firewall filters, it mostly means that some or all LAN subnets don’t have internet access).
The point of “explicitly drop the rest” rule is to explicitly expand the one rule above into multiple, at least two:
add chain=forward action=accept in-interface-list=WAN connection-nat-state=dstnat connection-state=new comment="defconf: accept DSTNATed from WAN"
add chain=forward action=drop comment="explicitly drop everything not accepted so far"
And the above changes the “implicit” behaviour of default rule so that not everything else is accepted, it has to be explicitly accepted. Including explicitly accepting LAN->WAN and LAN->LAN (which comes handy if one doesn’t want indiscriminate access between all of LAN subnets).
The problem with MT’s firewall is that MT is extremely flexible. So the default firewall works very well with otherwise default config. As soon as one starts to deviate from defaults (e.g. by adding a few LAN subnets which are not all equal … e.g. guest, IoT, etc.), one has to know how to adjust firewall as well. And whenever one deviates from defaults, one has to know what he’s doing. With firewall rules that’s extremely important due to security reasons.
IMO discussion about merits of default firewall config is not the one to be had with a newbie … even if the newbie might have impression that default firewall is not optimal. It should be discussion about what the whole set of rules does (because each individual rule is nothing without all the rest).
I've been writing this since the beginning...
The rule is one, and only one.
If the user does not understand it can be expanded, but why should they become only 2, since the second is implicit?
If we want to explicit the implicit ones the list must be expanded...
add chain=forward action=drop in-interface-list=WAN connection-nat-state=!dstnat connection-state=new comment="defconf: drop all from WAN not DSTNATed"
add chain=forward action=accept comment="defconf: accept anything forwarded from any source to any destination"
add chain=forward action=accept in-interface-list=WAN connection-nat-state=dstnat comment="defconf: accept all connection from WAN DSTNATed"
add chain=forward action=drop in-interface-list=WAN out-interface-list=WAN comment="defconf: drop unsolicited connections from WAN to WAN"
add chain=forward action=drop in-interface-list=WAN out-interface-list=LAN comment="defconf: drop unsolicited connections from WAN to LAN"
add chain=forward action=drop in-interface-list=WAN comment="defconf: drop unsolicited connections from WAN to anything"
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="defconf: accept all connection from LAN to WAN"
add chain=forward action=accept in-interface-list=LAN out-interface-list=LAN comment="defconf: accept all connection from LAN to LAN"
add chain=forward action=accept in-interface-list=LAN comment="defconf: accept all connection from LAN to anything"
add chain=forward action=accept out-interface-list=WAN comment="defconf: accept all connection from anything to WAN"
add chain=forward action=accept out-interface-list=LAN comment="defconf: accept all connection from anything to LAN"
add chain=forward action=accept comment="defconf: accept all connection from anything to anything"
In short, if one rule is enough, why should I write more than one unnecessarily?
If the problem is that the user does not understand the rule, then it also means that the user is better off not touching anything...
And then, even if the user does understand it, it is not a given that he will then modify it correctly.
I think the word “meaningless” is meaningless! 
I understand that the context (i.e., the environment and it’s needs and uses) dictates what the correct rules are.
Nonetheless, the set of default rules is correct both as a starting point and for the most basic (and often, common) use case. No?
I understand that using a specific set of rules, then, either individually or collectively, there are explicit rules (allowing or dropping matching frames) and the implicit rule of allowing what is not explicitly dropped. I understand that idea of explicit and implicit rules is important to understand in the context of the overall approach to rules (specify (or be explicity about ) what is allowed or specificy what is dropped).
I ran a little experiment and added a DROP ALL rule at the end of my existing set of FORWARD rules, as follows:
/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward comment="Allow WG to subnet" disabled=yes dst-address=192.168.1.0/24 in-interface=wireguard1
add action=accept chain=forward comment="allow port forwarding connect state dstnat" connection-nat-state=dstnat
add action=accept chain=forward comment="Allow wireguard to subnet" in-interface=wireguard1
add action=accept chain=forward comment="Allow subnet to enter WG" out-interface=wireguard1
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="drop all" log=yes
The result after about 12 hours is the DROP ALL at the end caught a lot of frames, for example:
My (likely incorrect) analysis of this is that the DROP ALL rule caught these frames because there was no explicit ALLOW rules from LAN to WAN before it.
But, I (clearly mistakenly) thought that the following rule would allow forwarding of all LAN to WAN traffic, but my guess is that DSTNAT does not include all NAT’ed traffic, but rather only inbound (DST?) NAT’ed traffic.
Nonetheless, would using only the 4 default FORWARD rules (and including the wireguard rules) be the better solution? Or should I simply remove the DROP ALL at the end, thereby making the “defconf: drop all from WAN not DSTNATed” rule implicitly allow all other frames?
Beyond understanding them, the basic rules are perfect until something is changed,
like adding wireguard,
but this is what I say from the beginning: "Find me a flaw, without touching anything",
but everyone responds "there are none, but then if you do this..."
\
You have done that:
add chain=forward action=accept in-interface-list=WAN connection-nat-state=dstnat comment="defconf: accept all connection from WAN DSTNATed"
add chain=forward action=drop in-interface-list=WAN out-interface-list=WAN comment="defconf: drop unsolicited connections from WAN to WAN"
add chain=forward action=drop in-interface-list=WAN out-interface-list=LAN comment="defconf: drop unsolicited connections from WAN to LAN"
add chain=forward action=drop in-interface-list=WAN comment="defconf: drop unsolicited connections from WAN to anything"
add chain=forward action=drop
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN comment="defconf: accept all connection from LAN to WAN"
add chain=forward action=accept in-interface-list=LAN out-interface-list=LAN comment="defconf: accept all connection from LAN to LAN"
add chain=forward action=accept in-interface-list=LAN comment="defconf: accept all connection from LAN to anything"
add chain=forward action=accept out-interface-list=WAN comment="defconf: accept all connection from anything to WAN"
add chain=forward action=accept out-interface-list=LAN comment="defconf: accept all connection from anything to LAN"
add chain=forward action=accept comment="defconf: accept all connection from anything to anything"
So, your MQTT device can not reach anymore the Amazon servers.
LOL -- I also looked up the IP and see it is Amazon.
That is a perfect explanation! And a very elegant approach.
I think that internally (to me, not to the router), I was fearful of omitting the DROP ALL because doing so implicitly allows all those you listed under "# so this is no longer allowed" as well as unwanted or unnecessary or dangerous frames to be forwarded.
In forward you can’t know if a LAN device will send unwanted or unnecessary or dangerous packets or not.
This is not the purpose of the firewall.
And no matter what happens from the WAN nothing will ever pass,
except for the dst-nat made in the firewall’s NAT,
which obviously is your good sense to accept the dst-nat only from safe sources,
but if it is open to the world… there is no firewall that help…
If we want to talk CONSTRUCTIVELY about something that is missing from the default configuration, it is something like:
/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment=“defconf: accept established,related,untracked”
add chain=input action=drop connection-state=invalid comment=“defconf: drop invalid”
add chain=input action=drop in-interface-list=WAN src-addlist= comment=“rex: antispoofing rule #1: do not receive from WAN unexpected IPs”
add chain=input action=drop in-interface-list=LAN src-addlist= comment=“rex: antispoofing rule #2: do not receive from LAN unexpected IPs”
add chain=input action=accept protocol=icmp comment=“defconf: accept ICMP”
add chain=input action=accept dst-address=127.0.0.1 comment=“defconf: accept to local loopback (for CAPsMAN)”
add chain=input action=drop in-interface-list=!LAN comment=“defconf: drop all not coming from LAN”
add chain=forward action=accept ipsec-policy=in,ipsec comment=“defconf: accept in ipsec policy”
add chain=forward action=accept ipsec-policy=out,ipsec comment=“defconf: accept out ipsec policy”
add chain=forward action=fasttrack-connection connection-state=established,related comment=“defconf: fasttrack”
add chain=forward action=accept connection-state=established,related,untracked comment=“defconf: accept established,related, untracked”
add chain=forward action=drop connection-state=invalid comment=“defconf: drop invalid”
add chain=forward action=drop in-interface-list=WAN src-addlist= comment=“rex: antispoofing rule #3: do not forward from WAN unexpected IPs”
add chain=forward action=drop out-interface-list=WAN dst-addlist= comment=“rex: antispoofing rule #4: do not forward to WAN unexpected IPs”
add chain=forward action=drop in-interface-list=LAN src-addlist= comment=“rex: antispoofing rule #5: do not forward from LAN unexpected IPs”
add chain=forward action=drop out-interface-list=LAN dst-addlist= comment=“rex: antispoofing rule #6: do not forward to LAN unexpected IPs”
add chain=forward action=drop in-interface-list=WAN connection-nat-state=!dstnat connection-state=new comment=“defconf: drop all from WAN not DSTNATed”
I leave the defconf rules for see the place where must be put the rules.
In reality, most of the WAN rules that should be inserted should be placed on the ISP side,
such as checking that the TCP headers are valid, and other various checks, but that the user should then have in forward LAN->WAN and on output…
This discussion has turned into meaninglessness 
a. Wow, so we have determined that rextended has pointed out that MTs default set of config rules actually work for the default config. The gods are happy.
b. We agree that once one starts monkeying with the config, the default rules need to be modified.
c. We agree that until one understands how the firewall rules work etc, they shouldnt be modified.
Conclusion: Joseph, dont change the default rules. 
Are we done yet??
By the way, dont config out of fear…
If your approach to firewall rules is fear and not knowledge, this is the clue to follow rule c. above!!!
I think this discussion was very useful.
I’m sure we would all agree that communicating technical concepts is a very challenging endeavor.
I think that, despite herculean efforts to date, communicating firewall concepts has not evolved to the point where a complete newbie, or even someone with years of basic computer technology (including networking) understanding can readily understand more advanced concept by using the existing explanation/teaching methods.
I’m sticking with the belief that this discussion contributed, perhaps ever so slightly, to the progress towards effective communication about firewall rules.
Thank you all!
@rextended Concur on both points.
In terms of adding additional rules, I have found it optimal to first transition a new user off the default rules, as they typically come here adding some functionality be it vlans, or wireguard or more to the mix. Then if the config is stable and they wish additional security, we ensure the admin is locked in with good security access to the config. Then if more is required the rules we discussed many years ago, to ensure unwanted traffic does not creep in unexpectedly as you stated.
There is one case, not sure if the rules cover it (or maybe designed for this very hole), when an ISP is very sloppy in their implementation to clients, allowing other clients (or others) perhaps to enter your router.
Can you expound on this threat and what users can do to ensure they protect themselves from insecure ISP implementations??? I believe this may be a credible threat, enough so to at least discuss and for the homeuser to best be prepared for it, especially since we dont have edge routers.
Yeah, especially since there still isn’t a good user guide that clearly explains the packet flow in a simple, easy-to-understand way.
Another thing that can be confusing is that WinBox mixes both the Forward and Input chains in the same window. Plus, several fields in the firewall actually work like if-then filters when enabled, but there’s no visual cue to indicate which ones. These fields aren’t even marked in the reference documentation, so you just have to figure it out over time—which is kind of a pain in the..
But once you learn to visualize the packet flow and have that classic “it clicked” moment, you realize it’s actually pretty simple. Or, honestly, extremely simple, IMO. So, the real issue is the lack of proper guidelines explaining how to connect the dots. Simple as that!
P.S.:
Even the books I bought when I first started learning ROS weren’t particularly helpful in that regard.