input chain rule NOT-LAN

RouterOS General
1

When either of the following rules are active, the LAN computer (Win10) can not access internet websites, but the ping command to the internet still works. Through trial and error found either one of these two rules (currently disabled) are the culprit:

add action=drop chain=input comment=“drop all coming from WAN” disabled=yes
in-interface-list=WAN
add action=drop chain=input comment=“drop input not from lan” disabled=yes
in-interface-list=!LAN
This happens on two different routers (both use mpisbe). These rules after creation, cause no problem until the
router is rebooted or power cycled.

Could this dual network configuration be involved?

add address=192.168.88.1/24 comment=defconf interface=bridge network=
192.168.88.0
add address=192.168.75.1/24 comment=“new network for wlan1” interface=
bridge1-wifi network=192.168.75.0

Is this an OS bug or am I missing something?
rules-lynn88.rsc (6.26 KB)

2

All I can point out is what I see as NOT usual…

(1) Rarely see such a rule, Is there a reason why you stuck it here ??
/interface bridge nat
add action=accept chain=srcnat
lets stick to normal Sourcenat location in source nat rules to ensure this is not the problem. I see you at least have the standard source nat rule in place.

(2) Again this is a rare find and should only be used by advanced users who know what they are doing.
If you are in this category all the power to you, if you copied it off you tube, not so much and delete it and stick to firewall rules within the normal filter rules location!
/interface bridge settings
set use-ip-firewall=yes

(3) Duplicate forward rules and some redundancy too. The second drop invalid rule (orange) is a duplicate and besides would never have been used because the drop rule before it would match everything else. The green indicates you block all WAN traffic and then later drop everything not yet matched so its redundant!
Even worse all that rule does is BLOCK WAN traffic the DST NAT part of the rule is MISSING.

add action=drop chain=forward comment=
“defconf: drop all from WAN not DSTNATed” in-interface-list=WAN { Where is dst-nat**??** }
add action=drop chain=forward comment=“defconf: drop invalid”
connection-state=invalid
add action=drop chain=forward comment=“drop all forward not considered”
add action=drop chain=input comment=“defconf: drop invalid” connection-state=
invalid

REPLACE THE WAN DST NAT RULE WITH A CLEARER SIMPLER RULE to fix the above mess.

add action=accept chain=forward connection-nat-state=dstnat comment=“allow port forwarding”

(4) This is a most strange rule, care to explain its purpose???
add action=drop chain=input comment=“drop not MAC to router”
dst-address-list=router src-mac-address=!1C:69:7A:1B:B0:E5

(5) PROBLEM RULES.
DELETE BOTH and use this instead.
but put it AFTER the default rules AND FIX ORDER SO IT LOOKS LIKE (aka untracked, then drop invalid, then accept ICMP, THEN PUT THIS RULE)

add chain=input action=accept in-interface-list=LAN

(6) If you dont want all users to have full access to the ROUTER and in truth they dont need access, except usually for DNS and sometimes NTP etc…
Then do something like
add chain=input action=accept in-interface=YOUR_CHOICE src-address-list=authorized dst-port=actualwinboxport protocol=tcp

Where src address list is a firewall address list of admin devices (desktop, laptop, ipad, smartphone etc…)
Where you wish to be able to access the config from would determine your in-interface choice,
If there was no wifi access required then in-interface=bridge, if wifi access required then in-interface-list=LAN

Then to ensure LAN users still had access for services…
add chain=input action=accept dst-port=53 in-interface-list=LAN protocol=tcp
add chain=input action=accept dst=port=53 in-interface-list=LAN protocol=udp

CAUTION: Before making any input rule changes DISABLE the block all rule at the end or you will LOCK yourself out!!

(7) THis rule is too funny, its a good rule but better placed after the established related default rule.
add action=accept chain=input comment=“drop all ICMP” protocol=icmp
Its funny because its an ALLOW ICMP rule as it should be, thus change the wording of the comment text!!

(8) Why is winbox disabled? How are you configuring your router???

3

Probably the easiest is to reset the router to defaults, then make the changes you require (from your export), but not touch the firewall until you completely understand how this works.
The default firewall is OK.

4

Concur pe1chl, it depends if the abomination I am looking at is a well thought out masterplan by an experienced admin,
or a complete cluster phuck by copying too many youtube videos :slight_smile:

5

I want to thank “nava” for taking the time to provide 8 responses to my question. I do not wish to argue with nava (to much of that today) but to simply answer his responses. I was target hacked 2 years ago (lasted about 3 months), therefore I am very very security conscience.

I use an https-security-certificate to keep Webfig access secure. I use Linux with Webfig & secure ssh w/keys (public key on the router & private key on the client computer) as substitution for the webfig-terminal (which has serious limitations). No Winbox is used here. Using secure ssh allows turning off all ip-services except ssh for security reasons. To make router config changes I enable www-ssl service using secure ssh. When the changes are completed, I disable www-ssl service for security reasons.

After making this post I found a solution replacement for those problem rules:

add action=drop chain=forward comment=“drop all wifi users to clients”
dst-address-list=clients src-address-list=“wifi user”

Now all my rules behave properly even after a reboot or power cycle. However this requires that all WIFI users be on a seperate DHCP server from the LAN users.

I have seen other comments about my filter rules sequence. I am following top-down rule sequencing for rule match OS speed. The greatest amount of packet match rules should be at the top. Since “forward” packets are far more numerous than “input” packets, then the “forward rules” are at the top. There are some “input” drop rules at the top due to their importance.

Response to “nava” items:

  1. This /interface bridge nat is not located in the firewall filter rules. Instead it is the interface rules where I thought it belongs.

  2. /interface bridge settings (use firewall) I was just ensuring that all packets go through the firewall. Once again not located in the filter rules.

  3. (drop forward and input invalid packets) The dst-nat is a default configuration rule, not mine. The other two rules prevent invalid packets for both forward and input chains. I intended both situations. I also don’t want port forwarding for security reasons.

  4. !MAC rule is to ensure no attempt is allowed for clients (other than me on my desktop), from attempting to access router config. This also makes some of the filter rules redundent but what is the harm?

  5. Problem rules fix was answered at the top of this post.

  6. My answer in item 4. I also can’t use Winbox on Linux.

  7. (allow ICMP) I agree with your comment. I was changing rules trying to find the problem-rules problem and this is simply an edit problem. I do in-service with ICMP packets dropped because a home user doesn’t need that.

  8. (no winbox?) Using Linux replaces Winbox use with wine, etc… which may break with the next updates. I prefer secure Webfig & secure ssh for simplicity.

I will gladly go back and review items 1 & 2 so that I can maybe understand those items better.

Perhaps “pe1chl” made a rash judgement not knowing that security is my main theme. So are my rules well thought out or just a cluster phuck? Once again thanks for the comments which gave me an opportunity to express a differing viewpoint about router config. Attached are my new and final filter rules that have been thoroughly tested.
lynn88-rules.rsc (1.71 KB)

6

Thanks lynn88 makes much sense to me… I call it as I see it and admit not having the background info, assumptions can and will be wrong.
One has to recognize that my perceptions are based on seeing many many posts so I typically expect the worst LOL.

7

I think you should not touch the default firewall when you do not understand the matter well enough to debug your changes.
The default firewall is good for home users. Any “improvement” that breaks it is probably not really an improvement.
When you want to drop some traffic between networks, that should be safe to do and not cause issues with your internet connectivity. When you start doing things like “block ICMP because it is not needed”, well you are on your own.

8

FORWARD FILTER RULES FIXED

/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment=\
    " accept established,related,untracked,new" connection-state=\
    established,related,new,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN    
add action=accept chain=forward connection-nat-state=dstnat
add action=drop chain=forward comment="drop all forward not considered"

COMMENTS
(1) This rule is NOT required, as you have the drop all rule at the end of the forward chain which prevents any L3 connectivity!!
add action=drop chain=forward comment=“drop all wifi users to clients”
dst-address-list=clients src-address-list=“wifi user”

(2) This is redundant and not clear and with a simple change is easier to understand (and single purposed) THUS RULE MODIFIED/improved.
Blocking all WAN to LAN is already accomplished by the drop all rule at the end of the forward chain (efficient!!)
add action=drop chain=forward comment=
“defconf: drop all from WAN not DSTNATed” in-interface-list=WAN

(3) This good rule you had in your previous config but forgot to put it in this time… was added back in!
add action=drop chain=forward comment=“defconf: drop invalid”
connection-state=invalid

(4) Finally I am assuming you wish to have internet access for your users, so I added this rule, if not applicable remove or if only applicable to one bridge then state that as the interface!!!
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN

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

INPUT CHAIN FIXED

/ip firewall filter
add action=accept chain=input comment=\
    "accept established,related,untracked,new" connection-state=\
    established,related,new,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="allow ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input in-interface=bridge src-address=MyDesktopIP  src-mac-address=C:69:7A:1B:B0:E5
add action=accept chain=input dst-port=53 protocol=tcp in-interface-list=LAN
add action=accept chain=input dst-port=53 protocol=udp in-interface-list=LAN
add action=drop chain=input comment="drop all input not considered"

COMMENTS
(1) Order fixed
(2) Put back in missing invalid rule which you did have previously and is a good rule to keep!
(3) modified the ICMP rule back to allow, any advice you have gotten to the contrary is very poor!

Discussion: IT IS A GOOD THING to limit access to the router. The default rules for the beginner are setup to allow all LAN users to the router. This works!
However its better to, as you have done, reduce this just to the admin BUT BUT, we have to be careful.
All the users do need to access services on the router namely DNS, so therefore:

(4) DNS access added for all the LAN users.
(5) Modified your Access rule to very clearly and pointedly ONLY Allow your IP and mac address to the router. Much better!!
If you were using winbox I would put in the dst-port=winbox port.

++++++++++++++++++++++++++++++++
I hope you are better understanding the concept and power/efficiency/simplicity of the drop all rules at the end of the input and forward chain.
A. it allows you to better tailor the default rules so that they are more precise.
B. it allows one to only have to consider the specific traffic one wants to allow, everything else is blocked then by default EASY PEASY!!!

9

Thanks for responding with more suggestions.

  1. - My third rule listed below has “new” connections added because I don’t want packets not considered to fall out the bottom. So that makes this rule (drop wifi users to clients) necessary. I consider this better security. I can see how you may have over-looked that rule’s “new” addition.

add action=accept chain=forward comment=
" accept established,related,untracked,new" connection-state=
established,related,new,untracked

  1. - Again, my “new” addition to the above rule applies.

  2. - I don’t need this because my “drop all forward” at the end does this.

  3. I use 4 computers to test my final rule changes. Two on WIFI and two on the LAN (cabled). These rules have been tested using pings, ssh connectivity, and internet connectivity. They work properly as I have listed them.

All my users use the DOH secure DNS server on router network 88, even the wifi users on router network 75 (the 75 network references 88 as it’s DNS server and Time server). As you may know there is a DOH test page https://1.1.1.1 /help, which confirms that the DOH is working properly for all my users.

As for the top to bottom rule sequence listing, I guess we will just have to both agree to disagree.

+++++++++++++++++++++++++++++++++
I understand what you are saying about drop all rules at the end. It is my understanding that the “new” connection (factory default) only happens because previous rules did not match for “new”. Same would be for other packets that I had not expected. This is why I added “new” in my 3rd rule and drop anything else that was not expected (for both forward and input chains).

I feel that this discussion helps me to clarify my out-of-the-box approach to this router. And I thank you for all your responses.

10

To anav

I did some more testing and anav was right about not needing the /bridge settings use-ip-firewall configuration that I used. I tested with use-ip-firewall both checked and unchecked and it made no difference with my (drop wifi user to client) rule.

So I have removed that configuration change as anav has suggested.

My mistake was in thinking that ip-firewall referred to the /ip/firewall filter rules and that was wrong. I researched this deeper (thanks to anav) and now understand that the reference to ip-firewall was in fact referencing the rules listed under the /bridge rules tab which is a different colored horse.

11

I wish to thank anav for responding enough to get my head screwed on right. He had mentioned a couple of times that it is more efficient to allow than exclude. For some reason, I heard it but did not get it. Now I get it.

My philosophy of excluding what I don’t want was over complicated and created the not so obvious original question in this post. Remember, fix the obvious and the not so obvious usually goes away!

I have now complied with anav’s philosophy (fixed the obvious) and now my filter rules are “accept” rules similar to his recommendations. There was only one exception. I had to add one “reject” rule to keep wifi users from “new” connections with clients (on the LAN).

The attached “forum forward.txt” file has this reject rule highlighted.
The attached “forum input.txt” file is inline with anav’s suggestions.

Everything now works as desired with limited admin access, and wifi users can not connect with LAN clients. But clients can still connect with wifi users if desired.

“forum input.txt” shows how the wifi users on network (..75.0) can still use the DOH secure DNS server on network (..88.0).

Once again I wish to thank anav for patiently responding to my post and helping me to write much better filter rules.
forum input.txt (1.17 KB)
forum forward.txt (1.07 KB)

12

My two cents… yes, drop all at the end is very efficient.

MIKROTIK STATEFUL FIREWALL APPROACH

If you want to know what its really doing, the last drop rule is TAKING EVERY NEW PACKET (first packet of any new session) that reaches the rule and dropping it.
If you go through the rule sets, they are there to take a look at the first packet (new packet) of any session initiated from an external source (unsolicited) and either match the packet to the rule or move it to the next rule. Any external return packet from traffic initiated within the router, is considered established and related and never sees anymore rules and just get moved to where it needs to go, its not a new packet but a known packet from an ongoing session.

What does this mean in practical terms?
It means that WE WANT EVERY NEW PACKET TO GO THROUGH THE RULESET until matched. In this way the ADMIN controls where the packets go and which are allowed. What we do NOT want is to accept every new packet as being valid. This is a security nightmare!

(1) Hence my first point is that your first rule s fundamentally WRONG!!
/ip firewall filter
add action=accept chain=input comment= “accept established,related,untracked,new” connection-state=
established,related,**new,**untracked

This would the last thing anyone should do in their security confg. This in practice means that any external traffic is accepted at this point and NEVER SEES any of the other rules.
Also it is not required to add connection-state=new to any other rules on the input or forward chain because as discussed above it is implied and known that every packet being tested in the firewall rules is the FIRST PACKET (new packet) of any session.

Once you understand that, and the purpose of the drop all rule, you can finish the configuration appropriately.

(2) The rest of the INPUT RULES look good, the only one I dont quite get is: Please explain how this works, my lack of DNS acument and not an error I dont think.
add action=accept chain=output comment=“allow router to answer DNS request”
dst-address-list=“wifi user”

FORWARD…
(3) Same comment error as in the First Rule of the input Chain.
add action=accept chain=forward comment=" accept established,related,untracked,new" connection-state=
established,related**,new**,untracked

(4) Covered in the discussion for the input chain, this FORWARD CHAIN RULE contains “connection-state=new” which is redundant and not required but causes no harm. Just for info purposes.
add action=drop chain=forward comment=“prevent wifi user fron connecting to client” connection-state=new
dst-address-list=clients src-address-list=“wifi user”

(5) I would put back in the drop invalid rule in the forward chain after the established related rule…

(6) I personally would improve the one rule thats rather loose in that there is no bound or clarity on what is being allowed…
Such a rule forces me to look at the config more closely and now I have to make assumptions which the concept of block all is supposed to address and remove!! The concept is that I dont have to know what I am blocking because I am only really concerned with what I allow. However in the rule below, do you realize that the rule means the clients have access to anything WAN and anything LAN and anything else we dont know about???
Did you really want clients to have full access to wifi clients?
Did you really want to exclude wifi clients from internet access?
This is one case where if it takes two or three rules to make it clear what is SPECIFICALLY allowed, it is worth it.
add action=accept chain=forward comment=“forward all source=clients”
src-address-list=clients

13

I appreciate that last post of anav which provided me with much insight. Thanks for anav taking the time to write that lengthy response. I couldn’t ask for more! I will now attempt to paraphrase that info to see if I understand it.

You can never have “new” in your accept chain (forward or input) because that would allow “new” unsolicited packets to never get tested by the other rules. The drop all at the end will drop any first time “new” packet that was not matched by the rule set. This will keep all unsolicited “new” packets from being treated the same as an established packet.

No connection-state “new” rule is required because the rule set will find a matching rule on the first rule pass if it is a packet to be accepted. There is no need for a “new” rule connection-state, it is always implied when you have the drop-all at the end of the rules.

Since you didn’t like my “output” rule, I guess a DNS reply across networks isn’t treated like an output by the filter rules? This is truely a question not an argument. My secure DNS query from network (.75.0/24) to the secure DNS server on .88.1 didn’t work for WIFI users on (.75.0/24). So I got to thinking that there are no “output” rules so all “outputs” would get dropped. It seems to work with my “output” rule but didn’t work without it. There may be some other factor involved, I just don’t know.

Acknowledge put back the drop “invalid” rules.

And your last comment about “forward all source=clients”, I do want the clients to have access to the WIFI users. But maybe this is bad because the clients may pick up a virus from WIFI users. So I think I will drop that rule. If it wasn’t dropped, and taking your advice about the looseness, I think I would write:

add action=accept chain=forward src-address-list=clients dest-address-list=
WIFI users

I will be fixing some of my rules and reposting my new rules with these new (to me) concepts in mind.

Thanks, you have really helped me a lot.

14

Concur, if you wanted them to access the wifi users it would be a clear separate statement as you have put it.

As to the DNS, I too am asking as I dont know LOL. If tis working thats probably the answer.

Since you didn’t like my “output” rule, I guess a DNS reply across networks isn’t treated like an output by the filter rules? This is truely a question not an argument. My secure DNS query from network (.75.0/24) to the secure DNS server on .88.1 didn’t work for WIFI users on (.75.0/24). So I got to thinking that there are no “output” rules so all “outputs” would get dropped. It seems to work with my “output” rule but didn’t work without it. There may be some other factor involved, I just don’t know.

15

When we added another bridge (bridge1-wifi), this caused issues while bridge1-wifi users are trying to use a secure DNS server located on the default bridge. Therefore “simplistic” negative rules strategy is no longer acceptable. Also, the out-interface-list becomes another filter factor, because by accepting only the out-interface-list in the rules, you exclude any in-interface-list matches.

With these rules we have isolated “wifi-user” from “clients”. With these rules, we don’t have to worry about unexpected packets getting in because we only accept what we ask for. These rules have been thoroughly tested using the system shown in the attached drawing. Not sure why this drawing is in-line, I did not select that option. I also attached this rule set file.

So the bottom line is that all these rules are tailored to allow those desired “new” packets which then become “tracked” and now that connection’s future packets only get to (Rule 2) before being “forwarded”. This prevents future packets from having to go through all the other rules again. This same strategy applies to both “forward” & “input” packet chains.

(Rule 1) Forward all “established” & “related” packets (defconf:=Mikrotik default rule).

(Rule 2) You can never have “new” in your (Rule 2) because that would allow “new” unsolicited packets to be treated the same as established and related packets. The drop all at the end will drop any first time “new” packet (not desired) that was not matched by the rule set. So if some rule other than (Rule 2) is a match, then the “new” packet gets accepted and that connection is now established and tracked in the “forward” chain. (defconf:)

(Rule 3) Dropping any rule that has a connection state of “invalid”. This means that the packet has something wrong with the packet structure. So it does nothing for a “new” packet. (defconf:)

(Rules 4&5) “Forward” “new” in/out Ipsec packets, now tracked.

(Rule 6) “Forward” “client” “new” packets going out the LAN interface, now tracked.

(Rule 7) Because of (Rule 8) below, this rule will drop any “new” “wifi user” packets going out the WAN to “clients” before this “new” packets gets to (Rule 8). This is an exception rule. Don’t know why but this rules works with both LAN and WAN. I think it is possible that LAN has access to all router functions and WAN does not?

(Rule 8) “Forward” “WIFI users” “new” packets to the LAN interface, now tracked.

(Rule 9) Same as (Rule 2) accepting “new” “input” chain to router-admin.

(Rule 10) Same as (Rule 3) dropping “new” “input” chain “invalid” packet.

(Rule 11) Drop “WIFI user” “new” “input” chain to router-admin. This rule will not work using in-interface-list=LAN but works with in-interface-list=WAN. I suspect this is because the in-interface-list for bridge1-wifi is set to WAN.

(Rule 12) Accept all “new” ICMP “input” chain packets to router-admin.

(Rule 13) Accept all “new” local loopback “input” chain packets to router-admin.

(Rule 14) Disabled, no longer needed using accept strategy. Fix the obvious and the not so obvious often goes away.
Accept all “new” “output” chain packets to “wifi user”. This is required for the router to answer secure DNS queries from the “wifi user” since they are on a different network.

(Rule 15) Accept all “new” (tcp) “input” chain packets to Port 53 (DNS) using bridge in-interface for “clients” to query secure DNS (in-interface-list=LAN doesn’t work probably due to 2 separate bridges pointing to LAN.

(Rule 16) Same as (Rule 15) except for “wifi users” on bridge1-wifi.

(Rule 17) Accept all “new” (udp) “input” chain packets to Port 53 (DNS) using bridge1-wifi in-interface for “clients” to query secure DNS (using the LAN approach did not work)

(Rule 18) Same as (Rule 17) except for “wifi-users” on bridge1-wifi.

(Rule 19) Allow all “new” “client” to “router” packets to access router-admin.

(Rule 20) Drop all packets not expected.


Rules 7 & 11 are trying to tell us something about in-interface-list capabilities. I just don’t fully understand it yet.
system.GIF
rules-lynn88.rsc (2.71 KB)

16

I don’t know how to mark this post as solved.

17

Getting there but not YET!

ALSO MISSING DROP ALL RULE AT END OF FORWARD CHAIN!!!

add action=accept chain=forward comment=\
    "forward all \"new\" packets from \"clients\" to LAN" out-interface-list=\
    LAN src-address-list=clients

What is the purpose of this rule… firewall rules deal with the first packet in a session, the new packet, the rest of the session and packets are captured by the established related rule!
If this rule is for clients to access the guests then state so. Its pointless to say clients can reach clients at layer3, when they already have that connectivity at layer2! There is no need to state they have access to the LAN!!

add action=drop chain=forward comment="prevent wifi users from connecting with\
    \_LAN clients; also blocks client to wifi user because they can't answer b\
    ack." connection-state="" dst-address-list=clients src-address-list=\
    "wifi user"

WHY, individual drop rules are not needed!! That is why we have the DROP all rule at the end of the forward chain. To match any first packets (new packet) not matched to other rules and they are then dropped and so no session occurs!! Also to clarify, being on differnt subnets/vlans prevents traffic between client and wifi users at layer2, using the DROP rule ensures the router cannot route between in either direction. Finally just because wifi users are blocked by the last DROP rule to reach the clients, this does not mean clients are blocked, since there is no traffic reaching there is nothing to block your logic is faulty. In addition if clients were allowed to access wifi users through an allow rule, the return traffic from clients would be permitted. However traffic/sessions ORIGINATIN on the client side would still be dropped by the last DROP ALL rule.

add action=accept chain=forward comment=\
    "forward all \"new\" wifi user packets to LAN" out-interface-list=LAN \
    src-address-list="wifi user"

I dont even know where to begin to know what this means. WHY ARE you making rules to allow users access the LAN??
That is not anything that resembles a requirement. Do you mean they need to access the clients? if so SAY SO.

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

add action=accept chain=output comment="allow router to answer DNS request" \
    dst-address-list="wifi user"

Get rid of this rule it serves no purpose!. The following two rules you have that allow all clients and guest to access ROUTER Services for DNS is correct.
although you say they do not. That only means your config is wrong somewhere else!!

add action=accept chain=input comment=“accept tcp on router port 53 (DNS)”
in-interface-list=LAN dst-port=53 protocol=tcp

add action=accept chain=input comment=“accept tcp on router port 53 (DNS)”
in-interface-list=LAN dst=port=53i protocol=tcp

add action=accept chain=input comment="allow clients to access the router" \
    dst-address-list=router in-interface-list=LAN src-address-list=clients

I am assuming this rule is ONLY to allow admin access to the config??? Or did you have something else in mind. Dont understand why you dst address = router, that is redundant!! The input chain is TO the router!!!
I would narrow down access by src-address-list (make a list of admin IP addresses that would be used, desktop, laptop, ipad, smartphone… something like

add action=accept chain=input comment=“allow admin to access the router”
in-interface=clients src-address-list=authorized dst-port=XX,YY where XX and YY could be ssh or winbox for example.

Since you dont show the complete config its hard to guess what else is screwed up but you should at least have something like

/interface
add name=WAN
add name=LAN

/interface list members
add ether1 list=WAN
add clients list=LAN
add wifi-guests list=LAN

The best thing is to actually publish the FULL CONFIG
/export hide-sensitive file=anynameyouwish

18

Thank you the Great @anav for details and simplicity.

19

Apparently during testing the interum rules export was sent by mistake.

ALSO MISSING DROP ALL RULE AT END OF FORWARD CHAIN!!!

I purposely removed the drop rule for “forward” to reduce rules redundancy. The last drop rule would do this also. However I now reckonise this would force the unwanted packet to traverse all the “input” rules, so I can now see how this is inefficient. Rule added.

  1. add action=accept chain=forward comment=
    “forward all "new" packets from "clients" to LAN” out-interface-list=
    LAN src-address-list=clients

point taken, it is removed.

  1. add action=drop chain=forward comment=“prevent wifi users from connecting with
    _LAN clients; also blocks client to wifi user because they can’t answer b
    ack.” connection-state=“” dst-address-list=clients src-address-list=
    “wifi user”

This needs repeat testing by me to confirm my intention.

  1. add action=accept chain=forward comment=
    “forward all "new" wifi user packets to LAN” out-interface-list=LAN
    src-address-list=“wifi user”

point taken, changed comment “access to clients”

  1. add action=accept chain=output comment=“allow router to answer DNS request”
    dst-address-list=“wifi user”

I agree this rule is not needed. It was removed after testing was completed.

  1. add action=accept chain=input comment=“accept tcp on router port 53 (DNS)”
    in-interface-list=LAN dst-port=53 protocol=tcp

I agree, once again mixed up export.

  1. add action=accept chain=input comment=“accept tcp on router port 53 (DNS)”
    in-interface-list=LAN dst=port=53 protocol=tcp
    Code: Select all

I agree, that was a typo after testing was completed.

  1. add action=accept chain=input comment=“allow clients to access the router”
    dst-address-list=router in-interface-list=LAN src-address-list=clients

point taken about input chain being router by default, will change this rule as you have suggested. Those big stupid trees prevented my seeing the forest.

“your added rule” add action=accept chain=input comment=“allow admin to access the router”
in-interface=clients src-address-list=authorized dst-port=XX,YY where XX and YY could be ssh or winbox for example.

Will do. As for interface list members, the only difference is that my wifi-user list=WAN. I am still struggling to understand the purpose of this interface-list concept.

Ok, I will provide this post as my intentions before making more rule changes. This way, if you have additional feed-back, that too will be incorporated in my next rule changes.

I once heard a quote "If you want to get really good at something, you have to accept that you will be really bad at it at first. I am still in the bad phase here, but less bad than before.

20

I too am still learning and like you need to see the logic since the background IT knowledge is lacking.

Interface lists are a very useful tool and construct within MT RoS.
You can do without it but its very useful and comes into play on various rules…

First and foremost firewall rules.
VALUE OF INTERFACE LIST
a. allows one to group interfaces for whatever reason, usually firewall rules.
b. where firewall address lists are best is for individual IPs or any combination of individual IP with subnets .
c. one neither needs interface lists or firewall address lists for single subnets, just use src or dst-address=subnet. (one exception see d.)
d. there is case for one subnet matched to one interface list BS AND THAT IS THE managment/base SUBNET could be the HOME Trusted subnet etc for the following
i. ip neighbours discovery interface-list=Trusted
ii. tools mac server WINMAC SERVER interface-list=Trusted.

An example.
Lets say you have 10 VLANS, of which 3 cannot reach the internet.
I always assume that there will be WAN interface list to catch all WAN members
I always assume that there will be a LAN interface to list ALL internal SUBNETS, vlans etc…

Thus the question is how best to handle something as simple as allow ALL subnets or vlans, to internet.
The usual easy efficient rule is

/ip firewall
add chain=forward action=accept in-interface-list=LAN  out-interface-list=WAN

…
But we have three that cannot!
TWO approaches.
u Make a list of the seven allowed vlans[/u]

/interface list
add name=allowINT
/interface list members
add interface=vlan21 list=allowINT
add interface=vlan22 list=allowINT
....
add interface=vlan27 list=allowINT
/ip firewall
add chain=forward action=accept in-interface-list=allowINT out-interface-list=WAN

…
Method TWo which I am more likely to use is make a shorter list of those NOT ALLOWED internet plus I probably already have the LAN to WAN rule in place.

/interface list
add name=noINT
/interface list members
add interface=vlan28 list=noINT
add interface=vlan29 list=noINT
add interface=vlan30 list=noINT
/ip firewall
add chain=forward action=drop in-interface-list=noINT out-interface-list=WAN
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN

Hopefully that gives you some idea on the use of interface lists and you should NOTE that ORDER COUNTS, and thus we block the three vlans prior to allowing all of the vlans access for matching purposes. The three vlans 28,29,30 first packet (new packet) match the top rule and it and all subsequent packets from that session attempt are dropped and never see the next rule.
.
Rules of Thumb:
2 or more whole subnets needed, use interface lists
IPs or IPs+subnets use firewall addresses
one subnet just use src or dst address etc.


…