Trying to understand defconf firewall

RouterOS Beginner Basics
1

Ok, so there is a default firewall config that works fine and all, but I’m trying to understand what it actually does. It seems that all tutorials explain that it does PRECISELY, like in the exact way the rule is written, which doesn’t really explain anything.

/ip firewall filter
1 - add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
2 - add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
3 - add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
4 - add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN

5 - add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
6 - add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
7 - add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

(I have removed CAPsMAN and ipsec rules as I don’t use these features, and I have numbered the rules)

At the same time, I’m looking at The ultimate Mikrotik iptables flowchart as reference.

Question 1) Not related to defconf yet, but looking at the flowchart - if I send an UDP packet from a completely different network into my network and if I have a dstnat with the UDP port, does the packet go through steps 1, 2, 3, 4, 5, 10, 11, 12, 13 (because IP was overriden to 192.168.x.x IP that is not the router itself, so step 12 results in N (assuming “dst addr=self” is the public WAN IP???)), etc. completely bypassing INPUT chain? How can a completely unrelated external incoming packet bypass a chain named “INPUT”?

Question 2) Not related to defconf yet, but what is “localhost” in step 5 in the flowchart? Is it only the router itself? “self” is used two times in the flowchart, but it doesn’t seem that they mean the same thing (local router IP vs WAN IP)

Question 3) What is an “untracked” connection state? Connection tracking - RouterOS - MikroTik Documentation mentions it, but doesn’t explain it. Or is the name confused “notrack” in that page?

Question 4) Why would we need an ICMP accept rule 3, but not a TCP/UDP accept rule? If we remove the ICMP rule, does that mean that pings won’t work from outside? Why would then TCP/UDP work?

Question 5) Looking at packet count of rule 4 and looking at logs with log=yes, it seems that this rule rejects internet noise (probes, etc.), but the description of the rule is a bit confusing. Does this rule work this way only because non-DSTNATed traffic goes through INPUT and “all not coming from LAN” is actually just “all coming from WAN”?

Question 6) I have internet detection feature enabled, which sends DNS queries for cloud.mikrotik.com every second. Enabling logs for rule 4, I see logs for UDP [dns server]:53→[WAN IP]:5678, which I assume is the DNS answer. This actually makes sense because DNS answers are coming from WAN, and are routed through INPUT chain. If the rule is to drop, how can internet detection feature work?

Question 7) Do we need an additional rule 6 (compared to rule 2) because DSTNATed traffic doesn’t touch INPUT chain? Any other reasons?

Question 8) I have been running my router for a some time. Rule 7 has never been triggered (packet count is 0). Why is this rule needed? If an incoming connecting is DSTNATed, then the rule doesn’t apply (actually I don’t see how anything would reach FORWARD chain if traffic isn’t DSTNATed). If incoming connection is not DSTNATed, then only INPUT chain applies and it’s dropped by rule 4. It is theoretically possible to send traffic to the router with dst ip of 1.2.3.4, so maybe then it would reach the FORWARD chain and wouldn’t be DSTNATed?

Thanks. I would actually prefer a firewall that DROPs by default, so if anyone has a copypaste config I could learn from, that would be great.

I know that the design of the firewall is very much influenced by linux iptables, but holy hell it’s confusing.

2

Well, the first thing you should do is disable that “detect internet” misfeature. It only causes confusion and serves no useful purpose, especially when you (want to) understand how things work!

The default firewall is an attempt to be the perfect firewall for users with a NAT router that may want to have CAPsMAN and may also want to forward some ports to an internal host. To do that they would only add a DSTNAT entry on the NAT page, and the filters are already OK.

In general you need to understand that FORWARD and INPUT are two different things. FORWARDed traffic is not INPUT traffic, except in the special case of “tunnels” where the traffic to the tunnel endpoint address is INPUT while the traffic through the tunnel can be INPUT or FORWARD.

You also need to understand that a chain that just ends, is an implicit ACCEPT. I would recommend to add an explicit accept rule at the end of both INPUT and FORWARD chains to see what ends up there.

3

Why would a feature that is essentially a perioding ping break understanding of the firewall? I would like to have logs in case of a WAN malfunction, so it serves a purpose for me.

Do you think my assumptions about which traffic gets routed through FORWARD and INPUT chains are correct?

I’m mostly interested in my question 8, I remember even when I had very much stock defconf the packet counter for that rule was still 0, so it doesn’t make sense why mikrotik would include a rule that never triggers.

4

You probably have connected your MikroTik router behind some ISP-provided router that already drops incoming traffic, or your ISP uses CGNAT.

Another option could be that you configured PPPoE but did not use the quickset to do that. In that case add the PPPoE interface to the WAN interface list!

When you want to fight with “detect internet”, your choice.

5

What kind of traffic are you talking about when you say “already drops incoming traffic”? How are fw rules 7 and 4 different? I do not use PPPoE and I’m not under CGNAT.

6

Some answers (hopefully):

Input means (in this context) that the destination is the device itself.
As opposed to forward that means that packet has a different destination and "passes through" the device.

If you prefer the check in #12 differentiates the traffic between what is destined to the router from what is destined to other addresses (hopefully reachable through the router).

This should also answer your question #5, input chain only applies to packets that have "dst-address=self" (destined to the router itself)

"self" means always the same "thing" the router itself, and it is used THREE times,:
5 from self (localhost)? <- try reading it as “Is src-address router's own?”
12 dst addr=self? <- try reading it as “Is dst-address router's own?”
24 dst addr=self? <- try reading it as “Is dst-address router's own?”

First thing you shouldn't, that is Rule #5:
The twelve Rules of Mikrotik Club

Post the actual log entries you see, but check also logs for firewall rule #1, maybe the DNS answers are in the latter.

Yes, because firewall rule #2 applies to chain INPUT only, whilst firewall rule #6 applies to chain FORWARD only.

There are mainly two schools of thought on Mikrotik forum about firewall rules, the rextendeders and the anavites, the former believe that the default firewall from Mikrotik is cleverly designed AS IS and should be NOT modified (if not to drill small holes in it to allow some specific service/connection), the latter believe that it is ALMOST fine but you need to replace the last rule with a "drop all else" one and EXPLICITLY ADD just before it what you actually want to allow.
The debate is essentially around how the default last rule is too clever and complex to understand, see these thread:
Ready to start my custom firewall rules journey
Review of PPPoE and Firewall rules for improvements
Firewall rules analysis

If you use the final "drop all else" rule in the forward chain, you essentially have your "Drop by default" setting, but anything that you don't explicitly allow before it won't pass through.

AND do check the firewall part in the excellent article by tangent here:
https://tangentsoft.com/mikrotik/wiki?name=Default%20Router%20Configuration

7

Well, when you have no traffic that is FORWARDed from outside to inside, i.e. no DSTNAT, no tunnel, no routable traffic, that rule will match nothing.

I usually have more complicated configs so I am not used to that situation.

8

I think minimal "anavite a.k.a. drop-default" version is more or less this

Required accept rules need to be added before "Drop all the rest" in the appropriate chain.

(you can add output chain as well but usually most are concerned about input and forward, less about output)

/ip firewall filter
add action=accept chain=input comment="accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=input comment="accept ICMP" protocol=icmp
add action=drop chain=input comment="Drop all the rest"
add action=accept chain=forward comment="Allow Estab & Related & Untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="Drop Invalid" connection-state=invalid
add action=drop chain=forward comment="Drop all the rest"
9

"self" here is not only the public WAN IP but every IP addresses that assigned to the interfaces of the router (seen under /ip address and /ipv6 address). If your bridge has the entry address=192.168.88.1/24 under /ip address then 192.168.88.1 is part of the list of "self" IP addresses.

Because one of the major roles of a router, is to forward packets generated by other hosts (sources that are not the router) to other hosts (destinations that are not the router)? The packets being forwarded go through the FORWARD chain.

The INPUT chain is only for packets that are destined for the router (the destination address, after having been manipulated by DSTNAT, is one of the router's IP addresses, see #12 in the chart).

At #5 a decision is made based on whether the packet has been generated by the router itself (normally the in-interface is lo). If you look at the chart, at #2 there two possible incoming arrows.

Packets generated by the router for the router itself (for example, you run :ping 192.168.88.1 from the WinBox Terminal and 192.168.88.1 is the address of the router on bridge; or when your router has User Manager and under RADIUS settings you have an entry pointing to one of the router's local addresses) are generated at #15, travel through #16, #17, #18, #19. #20, #21, #22, #23, #24, #26 (loop back to) #2, #3, #4, #5, #6, #7, #8, #9.

In the default settings of RouterOS, if you have firewall rules then connection tracking will be enabled. The router will try to assign/associate packets to/with connection tracking (conntrack) entries (that you can see under IP/IPv6 -> Firewall -> Connections). The conntrack entries consume resources (RAM) and trying to match packets to existing conntrack entries also consumes CPU resources.

For some traffic packets, like when you are dealing with (D)DoS, you don't want the router to create connection tracking entries or try to associate packets to connection entries to save RAM and CPU. For such cases your can write RAW firewall rules with the action=notrack with conditions. Packets matching the conditions will bypass connection tracking and have no associated conntrack entries.

Packets having associated conntrack entries will have values like new, established, invalid, related for the connection-state property. Packets having no conntrack entries have connection-state=untracked.

ICMP is not only used for ping (ping only uses the "echo" feature of ICMP). ICMP is very important for reporting errors and is essential for Path MTU Discovery (PMTUD) to work.

Especially for IPv6 it's even more important. Vital parts of IPv6 (NDP, MLD for example) need ICMPv6, and because routers cannot automatically fragment packets, PMTUD is crucial.

You should not block ICMP. If you don't want the router to answer pings, only block the "echo"-related part of ICMP/ICMPv6, while letting the rest through. Blocking ICMP is not a security measure!

So normally you always want ICMP packets to be able to reach the router, hence this explicit accept rule. TCP and UDP connections are handled (dropped or accepted) by other rules.

10

If you use your router as gateway to the internet, and your ISP is doing their job properly, then normally you won't see the counter of rule 7 ever increase.

But if for example, your ISP uses DHCP and does not properly isolate their clients (like when they plug all residences of an apartment building in the same switch without port isolation, or when you have your servers co-hosted in the same rack with other customers and the hosting provider is sloppy), then the neighboring clients might be able to send ethernet frames to your router (they just need to know/sniff the destination MAC address), they can then put in those ethernet frames IP packets with arbitrary (of their choice) destination IP/IPv6 addresses in the header.

Without rule 7, your router will happily perform its duty as forwarder and will try to forward the packets. Let's says the attackers put 192.168.88.15 in the destination address field, they can send packet from the outside to your LAN (assuming you have a defconf bridge with 192.168.88.1/24 and a printer at 192.168.88.15 for example).

The evil guys can even fake both source and destination addresses, with destination set to some victim on the internet, and your router will even forward the packet to the victim, while masquerading (SRCNAT) the source IP address to be your address, performing the attack with your IP address as source.

If the ISP is decent and not run by amateurs, then normally they will only allow packets that really have your address in the destination to arrive at your router. In that case you'll never see the counter of this rule have any value other than 0.

Because it can make hidden changes to your configuration. See this warning at the top of the documentation:

image

And also because it manipulates interface lists, lists that you might use in your firewall rules. The function does not work reliably and can be wrong, which causes interface lists to have wrong members. If you use the lists in your firewall rules, you might break your FW rules.

12

Thanks everyone for comments and links to further documentation. I think I got my questions answered.

Oh, I didn’t know that I get a club membership with a purchase of my router..

I don’t see any DNS related logs for #1, the log for #4 looks like this: DROP input: in:ether1 [Internet] out:(unknown 0), connection-state:new src-mac xx:xx:xx:xx:xx:xx, proto UDP, <dns>:53-><wan>:5678, len 524

thanks, i’ll use this as base

so does that mean that implicit ACCEPT rules are only for TCP and UDP?

If you use your router as gateway to the internet, and your ISP is doing their job properly, then normally you won't see the counter of rule 7 ever increase.

<…>

yes, finally! so it is the last thing i thought about, I will try to maybe trigger this rule locally by faking addresses.

Because it can make hidden changes to your configuration

aw shit

First video - ok let me get this right because I don’t add this rule often, set this, this, this, and we’re done. what’s that rule for? why are we adding it? nobody knows

Second video - chain explanation, flowchart is clearer

Third video - no firewall rules with NAT state are created or talked about

Fourth video - general explanation about firewall

Fifth video:

(about fw rule 4 in the video) “this rule will block all the other stuff that is not coming from your local network so this means that it basically protects your device from the internet side because it uh drops everything that is not <…> from your local network” - ok but that is not entirely correct, it doesn’t drop any DSTNATed traffic

(about fw rule 10 in the video) “then we drop everything else so it means everything that you did not accept before will now be dropped except connections that are coming from the when when means wide area network so this rule will drop everything except connections that are used for port forwarding for example you may have a web server in your local network and this rule will allow those but it will drop everything else” - mentioned in messages earlier, but no, if you’re in FORWARD then you are already forwarding traffic to some host in the network so the rule would be useless as it is described in the video. Like I said, very straight forward explanations of what these rules do, but not what they are for or what kind of effect they have overall.

13

No, the implicit ACCEPT rule at the bottom of the firewall chain are for everything, including ICMP. But it only takes effect if your can reach the bottom of the chain.

Don't forget that any rule with action=accept or action=drop, if all their conditions are satisfied, will stop further processing of the FW chain. All the other rules below it will be skipped (that's why the order of the rules within the same chain is so important).

Assuming you don't have rule 3. Then an ICMP packet coming from the outside (WAN) not matching rule 1 will reach rule 4 and be dropped. When rule 4 triggers action=drop (because the condition in-interface-list=!LAN is true), no other rules are processed for this packet on the forward chain of the filter table anymore, the implicit ACCEPT rule will not apply.

Which means the ICMP packet is dropped.

That's why the "accept ICMP" packet rule is placed relatively high, higher than "drop all not coming from LAN", so that ICMP packets coming from the outside internet will be accepted and processed, and for them rule 4 are skipped (because already accepted at rule 3).

14

yeah thanks.. i forgot that ICMP packet is meant for the router and TCP/UDP is for other clients…

15

If you use IPv6, then in the IPv6 firewall you should have rule that accept ICMPv6 on the forward chain too (not only on the input chain). And the defconf IPv6 firewall rules do have that.

16

here we are both fortunate to have enough ipv4 addresses for our citizens and unfortunate that there is no need for development of ipv6 infrastructure for private persons

17

You cannot rely on your local situation… at some point, providers of services on the internet (like websites, cloud services) will consider it too expensive to buy IPv4 addresses and offer their service only over IPv6.

At that point you will not be able to use their service unless you have IPv6 yourself.

Ok, the IPv6 designers have predicted that for 20 years already and it still (mostly) hasn’t happened, but it CAN happen.

18

i’m not saying i don’t want ipv6, it’s just that I don’t have it

19

IPV6 designers didn't read Asterix, the only fear is that the sky will fall on our heads

https://pbs.twimg.com/media/Gqj9oLbWAAAb0Gz.jpg

tomorrow, but tomorrow never comes.

20

Tomorrow becomes today so there is always a tomorrow.