Hi there!

Wondering if I could get some feedback as to if the following Firewall Filter Rules are proper for a normal household network?
(screenshot included)
I've followed a couple tutorials and did everything to the best of my limited beginner understanding.

The only service I have left active is WinBox & I have changed the default port, username & password for it. Feel free to ask me questions if I should add more info.

Thanks in advance. Kind regards //madeupname

If it works for you, then yes, settings should be fine. As long as you make sure that interface list memberships are maintained properly (no, LAN on WAN interface lists aren't anything magical, it's up to device admin to maintain lists).

I wonder though why you decided to ditch default setup and go with your own?

If it works for you, then yes, settings should be fine. As long as you make sure that interface list memberships are maintained properly (no, LAN on WAN interface lists aren't anything magical, it's up to device admin to maintain lists).

I wonder though why you decided to ditch default setup and go with your own?

Thank you for feedback.

I initially ditched the default setup in order to problem solve and get my internet working, turned out my ISP (Virgin Media) wouldn't hand out an IP to my DHCP client since it required the Max-DHCP-Message-Size to be 576, as someone else had figured out at this post in this thread:
viewtopic.php?t=187055#p988321

Also, I enjoy learning and understanding the things I use, and one good way to do so is to start from scratch I guess and build your way up, possibly with some mistakes along the way but that's why I asked here for feedback, just to make sure I haven't made any massive blunders.

Again, thank you for feedback and yes, I will keep those interface lists properly maintained. For now they just contain 4 interfaces for my 4 desktop computers in LAN, and 1 interface in the list for WAN since those are the only 5 ports I have on my Mikrotik device.

//pahittatnamn

Yo!

A few things:

• Consider moving the "established and related" rules above the other rules, both for input and forward.
• Your forward chain would likely need a fasttrack rule.
• Consider adding a "drop invalid" rule in both chains.

Happy learning!

But WHY Vingjfg

Yo!

A few things:

• Consider moving the "established and related" rules above the other rules, both for input and forward.
• Your forward chain would likely need a fasttrack rule.
• Consider adding a "drop invalid" rule in both chains.

Happy learning!

Okay interesting and thank you for feedback!
The reason for putting it above the other rules (established and related), is that to speed up the traffic? To let it pass through quicker if it ends up being allowed, not having to check other rules first?

About drop invalid, wouldn't my "Drop everything else" rules take care of that? Hmm, I guess something could happen that would be allowed by something else but that would be of state invalid, shouldn't invalid then be above fasttrack & established/related, just to make sure keeping those out?

I made an example including what you mentioned + IPsec policy forwards & !DSTNAT, I saw those included in Mikrotik's default setup but so far I haven't had any traffic trigger them (0 bytes).
Thoughts?

But WHY Vingjfg

But WHY such a strong reaction?
Not helping much without sharing your thoughts

Daft a tad............... nice to make suggestions, but without reasons what will the OP learn....

Okay interesting and thank you for feedback!
The reason for putting it above the other rules (established and related), is that to speed up the traffic? To let it pass through quicker if it ends up being allowed, not having to check other rules first?

Correct: established is a state in the conntrack table, and the lookup is very efficient. A lot more efficient than the matching of a packet. related is slightly different and requires a lookup + matching. Conceptually, the related packet is part of the same session, for example ICMP UNREACHABLE in response to an UDP datagram, or the FTP data connection part of an FTP session. There is another reason though: the way you had it ordered before meant that any packet coming from the LAN to the internet was accepted, connection or no connection.

About drop invalid, wouldn't my "Drop everything else" rules take care of that? Hmm, I guess something could happen that would be allowed by something else but that would be of state invalid, shouldn't invalid then be above fasttrack & established/related, just to make sure keeping those out?

In the context of conntrack, invalid means "anything that violates the state transition of the connection": for example receiving an ACK before having completed SYN-SYNACK-ACK, another example is receiving an "ECHO REPLY" without having seen an "ECHO REQUEST".

Dropping them after the established+related means that you will eliminate all the packets that are not part of a connection. If you had a rule that matched the traffic (for example "permit ip any any"), you would accept the traffic. Consider the following ruleset:

1. permit established, related
2. permit tcp A -> B
3. drop ip any any

The following traffic would go through the rules: The last packet is clearly a state transition violation: the connection is torn down as soon as FIN ACK is received, the extra "PSH ACK" is not part of anything, but the rule let it out anyway. There are two ways of solving this: either adding a rule to drop the invalid packets before the rule that accepts the packet or require rule 2 to match only on new connections (i.e. SYN in this case).

Note that there is a weird point of detail: conntrack has the concept of "loose tracking": this means that if you have a rule that accepts a non-initiating packet, conntrack will consider the session as having been established anyway. For example, if an internal machine sends an "ACK" without having properly gone through the three-way handshake, the packet would be considered as "invalid" (and dropped if you have a rule to drop invalid transitions) but let's assume you don't have a rule to drop invalid transitions and that you have another one that says "permit tcp any any" on the way out:

• conntrack loose: pass the packet and create the state established in the conntrack table.
• conntrack strict: pass the packet without creating an entry in the conntrack table.

On Mikrotik, you can check whether the tracking is loose or strict with:

I made an example including what you mentioned + IPsec policy forwards & !DSTNAT, I saw those included in Mikrotik's default setup but so far I haven't had any traffic trigger them (0 bytes).
Thoughts?

Likely normal: the one with IPSEC is to permit the packets exiting an IPSEC tunnel to get in the network. If you don't have an IPSEC tunnel, then that rule is not going to match.

The one with !DSTNAT drops all traffic trying to cross the firewall without having matched a destination translation: as the default action in Mikrotik is to allow the traffic, this rule simply prevents all traffic coming from the WAN to be forwarded to anything unless you have a NAT rule in place (destination NAT to be precise). If you don't have any destination translation, this is not going to match either.