Sanity check on firewall drop filter rule

RouterOS General
1

I am sure this is operator error but need a new look at rules, have not been able to fix the issue myself. Implementing a simple drop of all traffic from a specific IP address on the LAN side of router to the Internet. Have created three test rules, all with drop action and three different chains, input, forward and output. Per the traffic count and log entry’s, some traffic is being dropped but am still able to access any part of the internet from the test IP. I placed the rules towards the top of the rules list to ensure that one of the rules was not accepting prior to the test rules. Sure the mistake is stupid but am missing the issue, Here is the code block.

# sep/13/2022 15:11:55 by RouterOS 7.5
# software id = MDM4-MYMH
#
# model = RBD52G-5HacD2HnD
# serial number = 
/ip firewall address-list
add address=XXXXX.sn.mynetname.net comment=\
    "FDQN for Mkrotik Cloud DDNS for .2" list=CloudDDNS
add address=192.168.145.129 comment="Aiden Total Wireless Phone" list=\
    "Block Internet List"
add address=192.168.145.153-192.168.145.169 list="Block Camera to Internet"
/ip firewall filter
add action=drop chain=input comment=DropInternetTrafficTest1 log=yes \
    log-prefix=DropInternetTrafficTest1 src-address=192.168.145.129
add action=drop chain=forward comment=DropInternetTrafficTest2 log=yes \
    log-prefix=DropInternetTrafficTest2 src-address=192.168.145.129
add action=drop chain=output comment="DropInternetTrafficTest3\
    \n" log=yes log-prefix=DropInternetTrafficTest3 src-address=\
    192.168.145.129
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
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=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=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 Camera from Internet Access" \
    disabled=yes src-address-list="Block Camera to Internet"
/ip firewall nat
add action=masquerade chain=srcnat comment=defconf out-interface-list=WAN
add action=dst-nat chain=dstnat comment=\
    "Blue Iris Port Forward - Uses Address List for FDQN DDNS" \
    dst-address-list=CloudDDNS dst-port=40000 in-interface=WAN-ether1 \
    protocol=tcp to-addresses=192.168.145.150 to-ports=40000
/ip firewall raw
add action=drop chain=prerouting comment=\
    "Nuclear Option to drop traffic to internet." disabled=yes src-address=\
    192.168.145.61
2

Your use of firewall rules indicates you dont have a clue how they work.
My suggestion is that you start with the defaults.

Second, your stated requirements are not clear at all.
Detail what you want users to be able to do and what they shouldnt be able to do, without speaking about it in config speak.

Third, the mikrtok config cannot be parsed out for any issue, you need to supply the full config /export minus the serial number and any public WANIP information.

For the default rules start here…

/ip firewall filter
{Input Chain}
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="drop all else" *****
{forward chain}
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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 internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=drop chain=forward
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface-list=WAN

***** add this rule last so you dont lock yourself out of the router.

Then you only need to ADD any other traffic that should be allowed. By default (the drop rules), all other traffic is already blocked.

3

To add what @anav said (in his kind manner): when you add a firewall filter rule, it only affects connections created after the addition. Already established connections may be affected in certain conditions. You have the “fast-track” rule which makes connections matching the rule execute a “firewall shortcut” and thus avoid any new rules you may add. Mind that TCP connections, created by e.g. internet browser, are long lived even though you as user perceive browser as idle. So if you add a rule to firewall, you have to make sure you’re testing if it works by creating entirely new connection (e.g. opening web page which you didn’t visit in last half an hour or so).