Whats the point of this default FW rule?

Hi all,
I’m having a clean out of unused Firewall rules and I can’t for the life of me figure out the purpose of this default rule.

add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"

As far as i’m aware, it have never been triggered, so I put a replica counter rule at the top of the forward chain and it’s been there for a month and it’s never triggered.
my logic is that, surely if any connection is established “from WAN not DSTNATed” would run through the input chain not the forward chain, so why is this there???

Please inform me that I’m a blind illogical idiot and explain to me it’s purpose? as I’m sure that there would be a purpose given it by people much smarter than I.

Thanks much

There is input chain: into your router.
There is also forward chain: THROUGH your router into your LAN.

You need to protect both. You don’t want traffic from outside coming in or passing through unless you know about it or when it is not a response to something coming from your environment.

See here for a lot more detailed info (see section on forward chain)
https://help.mikrotik.com/docs/display/ROS/Building+Advanced+Firewall

The default firewall rules are for the sole purpose of an individual connecting to his ISP and using the internet.
Once you start changing the network it is advised to revisit the firewall rules and modify accordingly.
As you have found out, the default rules are not all that clear for the beginner.

The rules if you are able to discern are set up with two concepts.
ALLOW ALL TRAFFIC as the starting point.
BLOCK certain traffic that is known to be not secure.

The problem is this relies on the user knowing in detail what may or may not be insecure, and this gets more difficult as the config gains in complexity.
Thus most users, as a first step, change the concept of the firewall rules with the following approach:
BLOCK ALL TRAFFIC as the starting point]
ALLOW only needed traffic.

In this way the user doesnt have to know whats potentially insecure, as all traffic is blocked and only user/device traffic needed is permitted.

++++++++++++++++++++++++++++++++++++++++++

The way to make this change is by putting at the end of the input chain and forward chain the basic rule
add chain=input/forward action=drop comment=“drop all else”

Thus if any of the rules above this rule, are not matched, then any other traffic is dropped cold.
One must be careful of implementing this in the input chain as one needs to allow ADMIN access to the input chain in a prior rule or you will lock yourself out of the router.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The rule in question:
add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment=“defconf: drop all from WAN not DSTNATed”

Basically is two rules. I prefer separating rules and having clear rules so that to the reader its not ambiguous.
The first embedded rule, is to allow traffic going to normally a server ( port forwarding ) as that traffic comes in from the WAN usually.
The second embedd rule, is to block all other WAN to LAN traffic.

From the above, you now know that this second rule will not be required as we will have a last rule in the forward chain that drops all such traffic anyway.
The first rule will be stated in a much clearer new firewall rule!!
add chain=forward action=accept comment=“port forwarding” connection-nat-state=dstnat

However we are not DONE.

The default rules have an IMPLIED Third rule you were probably not even aware of.
It permits LAN to WAN traffic as well. Remember the approach is to allow all traffic and only block bad traffic.
Since we are not changing that to block all traffic at the end, we must ensure needed traffic is permitted, so typically we also add

add chain=forward action=accept comment=“internet traffic” in-interface-list=LAN out-interface-list=WAN

So now you have the new approach setup for firewall rules ready to be expanded to receive more rules for any needed traffic (allow).
/ip firewall filter
{forward chain}
_**add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid
add action=accept chain=forward comment=“internet traffic” in-interface-list=LAN out-interface-list=WAN


add action=accept chain=forward comment=“port forwarding” connection-nat-state=dstnat { disable or remove if not required }
add action=drop chain=forward comment=“Drop all else”**_

*********** Where one puts any more rules to allow traffic

As noted you are confused about the chains.
WAN TO the ROUTER is input chain, think of
a. vpn connection to the router
b. Configuring the router

WAN to LAN ( through the router)
a. port forwarding normally from the www.
b. upstream router subnets to NATTED mikrotik router ( aka subnets on upstream router need access to subnets on NATTED router ) using static routes etc…

Thanks for putting the effort in with so much info.
Yeah, I’m with you and I do get how the chains work. But a connection can’t go THROUGH the forward chain of your router unless it is NATed otherwise all connections to ports on the router IP from the WAN are specifically Input chain connections destined to the routers own services. Because they aren’t DEST-NATed they are processed as Input chain connections. So unless the connections are DEST-NATed they won’t run through the Forward chain. So whats the point of a drop rule that would seemingly never have anything to drop?


But I think with “b”, if there was traffic going “through” the forward chain that was specifically not part of the WAN, like say, a neighboring trusted router, the rule still won’t drop traffic because it is still not part of the WAN.

Has anybody ever seen this rule with a Non-zero connection count? if so whats the situation that triggered it? I would like to say “under normal home ISP circumstances” but I just cant see it happening and I would like to know any example of when it would trigger? That may help me understand the logic behind it.

To be honest: no.
I’m in the “DROP ALL at the end and only allow before what’s needed” part of the spectrum.

it is there for any port-forwardings you configure in the NAT tab (dst-nat) for forwardings from WAN to LAN
if that rule is NOT there/active, you would have to add another firewall filter rule additional to the DST-NAT (port forward) rule to allow it.
so this rule ensures, your dst-nat rules in ip > firwall > NAT are allowed and you do not have the need to add a filter-rule additionally to every dst-nat rule

As I tried to explain your concept of forward chain and traffic is flawed.
There is such a beast as WAN to LAN traffic. All traffic is not destined necessarily for the input chain.

The dstnat rule, the default rule EVEN Tells you there is…
It says block all WAN to LAN traffic EXCEPT FOR port forwarded traffic, or more bluntly any traffic heading to the router with a specific port identified.

In the case of lets say an upstream ISP Router with LAN subnet of 192.168.20./0/24, and we manually assign 192.168.20.10 to the MT Router on the ISP router LAN.
So the WANIP of the MT router is also 192.168.20.10 as we put that in the IP address field ( no need for IP DHCP client).

Lets say there is another subnet on the ISP router 192.168.5.0/24 and we have a subnet on the MT router 192.168.88.0.
I want to enable traffic from both subnets on the ISP router to the subnet behind the MT router and vice versa.

Well on the ISP router I have to tell it where to send such traffic.
add dst-address=192.168.88.0/24 gateway=192.168.20.10

On the MT router same same for the unknown subnet, since the router has an address on the .10 subnet a route for that subnet is not required as it already exists!!
add dst-address=192.168.5.0/24 gateway=192.168.20.1

Now users in all subnets have a path to reach across the MT router.
Whats next is firewall rules to allow such traffic.

On the MT router
add chain=forward action=accept src-address=192.168.5.0/24 dst-address=192.168.88.0/24
add chain=forward action=accept src-address=192.168.10.0/24 dst-address=192.168.88.0/24

The users on the ISP router have no desire to visit the MT router itself, as stated they are going THROUGH the router and no input chain is involved.

This rule does get hit if you use it as intended, yes.

Any NAT rule that you have dst-nat to an internal computer will be on the forward chain.

You can use this default rule instead of a default drop-all so that anything dst-natted will be allowed instead of creating both a nat rule and a filter rule for every port forward, for example.

as in #7

Sorry for the delay in my reply (I have been away),

I understand what you are saying and agree. I do understand also understand chains, (It isn’t rocket science (It’s worse than that, it’s IPtables) however. I also follow the school of “DROP ALL at the end and only allow before what’s needed”.

Hear me out though. Lets say on our MT router with a WAN IP of x.x.x.x, we have a DST-NAT for a web server at 192.168.0.2:443. It’s the only DST-NAT on the router.

chain=dstnat action=dst-nat to-addresses=192.168.0.2 to-ports=443 protocol=tcp in-interface-list=WAN dst-port=443

If a packet from the WAN, comes into the WAN port on the MT router for x.x.x.x:443, it get forwarded to the web server through the FORWARD chain, as the packet is traversing the router. And because it is DSTNNATed it isn’t hitting the “defconf: drop all from WAN not DSTNATed” rule. why would it right, it’s DSTNATed. We know that, that’s how it works.

HOWEVER, If a packet from the WAN comes into the WAN port on the MT router for x.x.x.x:80. It will not have a DSTNAT rule, and will not be NATed, it will not traverse the FORWARD chain, it will run through the MT router WAN IP into the INPUT chain, (because it sure as sugar isn’t getting forwarded). Because the connection is in the INPUT chain it also isn’t hitting the “defconf: drop all from WAN not DSTNATed” rule.

So the “defconf: drop all from WAN not DSTNATed” rule can never be hit. Right?

Yup, if you have DST NAT rule defined with in-interface-list and all packets, arriving at WAN port, are destined to router’s WAN IP address, then there’s a very small chance for WAN-originating packet not being either DST-NATed or “consumed” by chain=input.

But what about this DST-NAT rule instead:

/ip firewall nat
add chain=dstnat action=dst-nat to-addresses=192.168.0.2 protocol=tcp dst-address=x.x.x.x dst-port=443

It’ll only trigger on packets, arriving at router and targeting router’s public IP address (and port 443). For packets, arriving via WAN port, it would behave the same as your rule. It would also trigger the rule even if packet arrives via any other interface … which is important for hairpin NAT to work.

BUT: if a packet arrives via WAN interface and is targeting a LAN IP address[*] (e.g. dst-address=192.168.0.2 dst-port=443), it won’t get DST NATed when using “my rule” (but will be DST NATed when using “your rule”) … but router will still route it towards LAN and firewall filter would pass it without the drop rule you’re questioning. Well, there are a few members of this forum (including myself) who think that replacing that single ultimate rule from default config with a pair of “accept DST-NATed via WAN” and “drop all” is a great idea … and it would take care of “my” packet.
However, even “your nat rule” doesn’t cover all packets targeting LAN IP address (e.g. what if somebody tries to connect to port 22 or 3389 or any other port not NATed) … those will hit chain=forward as well …

[*] Normally there wouldn’t be such packets “knocking” on your WAN interface. But an attacker might come up with such attempt and depending on ISP network topology it may even successfully communicate with your server if he’s able to bypass your firewall. Or in case when bi-directional communication is not possible due to some reason, atracker could still flood your LAN devices with unidirectional stream of UDP packets or even TCP packets with crafted flags section, e.g. RST).
And we all know that good firewall setup protects also against unexpected attack attempts.

Mind that default config doesn’t have any DST-NAT rule and it’s only too easy to construct a rule which will miss some internet-originated ingress packets due to lack of a good example.

Is there a possibility that topic starter is just behind ISP NAT that’s why no one hitting him? Because normally there’s a lot stuff hitting router outside in input chain, but if your ISP doesn’t care about security, you can be unprotected from L2 neighbors, so they can just route to private range through your public IP and here goes forward drop.

I see it differently,
Lets make the scenario that both the Router on port 443 is listening on a router service and the OP also has a SERVER on the LAN waiting for incoming 443 traffic.

ONLY A DST NAT RULE:
Traffic comes to the router, first in PREROUTING CHAIN and the last function in prerouting chain ( after prerouting/mangle ) is Destination NAT.
If there is a valid port in NAT rules, and there is a valid allow rule in the forward chain, then the traffic will reach the LAN server.
If the router does NOT have a valid forward chain rule the incoming traffic is dropped as there is no viable route to the LANIP of the server.

ONLY AN INPUT FILTER RULE:
The traffic heading for the ROUTER hits the PREROUTING chain as above first, but nothing matches (including dstnat).
The traffic next hits the INPUT CHAIN and after mangling functionality hits the Filter Input function. IF the router has an input chain rule for a router service, aka “Listening” on that port, the traffic Traffic is matched and executed. IF not the traffic is then dropped. So any traffic with a non-recognizable port never makes it pass the input chain (ding ding)

BOTH RULES IN PLACE:

  1. The input chain rule ( router service ) will never be seen/utilized/matched. The logic here is that when the traffic hits the dstnat rule, TWO things happen:
    a. the destination address is changed from WANIP of the router to LANIP of the server, and
    b. the traffic goes directly to the third chain, the FORWARD CHAIN, and never sees the INPUT CHAIN altogether.

This also explains, in the situation where there is a dstnat rule but there is no forward chain rule, why the traffic is still dropped dropped even though the router is listening on the same port (via the input chain). Because the input chain is for traffic to the router, to the WANIP of the router and that has been modified plus the traffic has bypassed the input chain and gone directly to the FORWARD chain, looking for associated forward chain filter forward functionality.

The moral of the story is that the dstnat rule trumps the input chain rule if both are entered. In any case a config containing the same ports for both input chain and dstnat demonstrates an admin who is confused.
pprocessing.jpg
++++++++++++++++++++++++++++++++++++++++++++++++

To answer your question directly, the default rule, we are discussing, states two things very clearly in the FORWARD CHAIN PROCESS:
a. allow any traffic from external, which has a dst port that has a corresponding dstnat rule.
b. block any other traffic heading to the LAN.

Now any traffic from external sources with dst address of the Router WANIP, and a port not on any dstnat rules, will go to the input chain.
Since the input chain contains no rules for this port, the traffic will be dropped.
So any traffic with destination address of the WANIP of the router, with a non-recognizable port never makes it pass the input chain.

So what is the purpose of the drop all rule or the default DSTNAT RULE…–> what traffic are we concerned with!!!

—> mac address of router is compromised
i. ISP does not block clients from each other
ii. hacked ISP
iii. internal network PC is hacked and they access mac address of router
iv .probably 5 or more other ways…

The mechanism is that an evil source sends traffic to the mac address of your router with dst-address of a LAN IP address existing on the router and it will go through.
That is the second purpose of the default rule!
There may be other ways evil doers manage to access the LAN but I am not aware of them.

Hi MKX ( edit, sorry Sob I should have known you wouldn’t make such a basic error!!) , good idea to confuse with a non WAN entering dstnat rule example, had to scratch my head on that one…
Still not sure what the point was…

However do disagree with this statement: “However, even “your nat rule” doesn’t cover all packets targeting LAN IP address (e.g. what if somebody tries to connect to port 22 or 3389 or any other port not NATed) … those will hit chain=forward as well …”

My understanding is that External traffic hitting one of the routers own addresses (WANIP) with a port NOT delineated in either nat rules (Lan service ) or input chain rules (router service) will first be processed through the PREROUTING CHAIN and will not be matched. Hence, having dst IP of the router itself, will next move to the INPUT CHAIN rule.
Since the traffic is not matched, the traffic will be dropped regardless. Such traffic will never see the FORWARD CHAIN.

Not Sob … but I’m flattered.


I started the paragraph with

BUT: if a packet arrives via WAN interface and is targeting a LAN IP address[*] (e.g. dst-address=192.168.0.2 dst-port=443)

and the whole paragraph is about that (twisted) case.

OTOH, one has to read both firewall filter rules and NAT rules together:

/ip/firewall/nat
add chain=dstnat action=dst-nat to-addresses=192.168.0.2 protocol=tcp dst-address=x.x.x.x dst-port=443
/ip/firewall/filter
add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"

These two rules have one non-overlapping possibility: hairpin-NATed packets (packets targeting router’s WAN IP address but ingressing via one of LAN interfaces). However, without having the later rule with “connection-nat-state=!dstnat in-interface-list=WAN”, the packets targeting LAN IP address and ingressing through WAN interface would be passed. Another possibility would be packets with an unrelated WAN IP set as destination, router would try to route those towards destination as well … unless some rule in chain=forward drops them (as they should be).

The point of my posts in this thread being: not all packets ingressing via WAN interface have to have dst-address set to router’s WAN IP address (as it normally would) and hence don’t necessarily hit either DST NAT rule or chain=input.


This statement is not true with regard of hitting forward chain (as I described above). Alas @OP was questioning the drop rule which takes care of cases where IP addressing used on ingress packets is not what normally should be … and I was arguing that we need rules which deal with unexpected packets.

I will start with the last part of your sentence … where we are in 100% FULL agreement, or more accurately, I have learned from the best, you and sob included.

What I was saying is that when the routers IP is the destination address from EXTERNAL traffic, with a dst port NOT identified in any dstnat rule, the traffic goes from the PREROUTING CHAIN to the INPUT CHAIN. If that dst port is not identified on any input chain rules ( no router services are “listening” ), then the traffic is DROPPED, full stop, do not pass go, do not go to forward chain etc…

I understand you included traffic coming from LAN hitting the WANIP, but this was not the main thrust of the thread and may cause more confusion. Also it was confusing because we were discussing blocking unwanted traffic while you were trying to stuff in, but what about this dstnat traffic I want to successfully execute. Yes, I was focused on external incoming only.

Note one of the first things I do in my rule changes are to remove the limitation of dstnat to WAN incoming on the forward chain and make the generic rule for accepting dstnat (so either LAN or WAN).
This along with hairpin nat rules ( if not using DNS method ) ensures both external and internal users can reach the LAN server.
But we still need the part that says block all coming from WAN ( evil doers using mac address of router no matter how obtained ) and that is why we ensure we have the block all else rule at the end of the forward chain ( and input chain for other reasons )…

And what I’m saying is that when a packet with dst-address= enters router via WAN interface it may not be DST-NATed but will hit chain=forward regardless.

Okay if you want to split c-hairs!!
Hey, curly hairs, friggin readers with minds in the gutter!!

Lets make the distinction more plain instead of your amusing but confusing obfuscations…

MKX → And what I’m saying is that when a packet with dst-address= enters router via WAN interface it may not be DST-NATed but will hit chain=forward regardless.

anav -->And what I’m saying is that when a packet with dst-address=WANIP enters router via WAN interface if not matching a DST-NAT rule, will hit chain=input and never the forward chain.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

What mkx should have said :slight_smile: :slight_smile:
And what I’m saying is that when a packet with dst-address= enters router via WAN interface - and this is ONLY possible if via the mac address of the router it may not be DST-NATed but will hit chain=forward regardless.

Of course, think about it… The router sees a private LANIP address and it recognizes it as an existing local interface, of course it will sent it to the FORWARD CHAIN block. Stating the obvious LOL.

What we are saying is that such traffic is neither expected nor wanted and we need to ensure its blocked, which the default WAN dstnat forward chain rule does, or what the drop all else rule also accomplishes.

Thanks team,
I do think that I have more insight on it now, I have made a point to read all your words, and I now have a lot to mull over. I understand that it is there to defend against the unknown and probably more likely where there are multiple external routes.

The reason I started looking at this was that I was cleaning out rules that have had a 0 count for the last 6 months (as they are obviously unused) as to improve efficiency in the firewall by cutting down the rule count and this particular default rule just triggered me as it was zero count and I logically couldn’t see a situation where it would be used so I thought it was pointless.

It may still be pointless for my purposes, as I don’t have multiple neighboring routers and all of my DSTNATs and hairpins are specified and policed.

But you have given me more pause for thought.

Thanks again.