I don’t know, but if a set a mange rule with action is “accept” according the manual the packet is accepted and is not passed to the next rule. So I understand it leaves the mangle process for that chain. ("accept - accept the packet. Packet is not passed to next firewall rule. ")
But even in the same chain the next rules still ´see´ that package and perform their ´action´ on the packet.
Is this an error in the manual?
A couple things first:
what RouterOS version?
what rule(s) are having issue?
post
/ip firewall mangle export
so we may verify and test if needed
should not. e.g., for me 
the behaviour you described is for action=passthrough, not action=accept
Sorry not to reply earlier. Several topics that I reply to and subscribe, or even some I started myself, are not sending me any replies to my mail box.
Some only for a couple of weeks and then never anymore. I miss a lot of replies this way.
Complained about it at Mt but all they could come up with is “subscribe to the topic”…
Anyway, in the Wiki manual it is written: "accept - accept the packet. Packet is not passed to next firewall rule. " (http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Mangle)
It applies to ROS 3 and 4 according this Wiki and I use both of these.
On this moment am not using it on any of my routers. I made some test rule in my ´live´rb600 working in bridge mode as QoS.
Made this rule for traffic coming from my Pc (public Ip given by previous router):
chain=forward action=accept protocol=tcp src-address=84.232.92.4 dst-port=80
Accoring manual the traffic flow ´catched´by this filter is not passed to next rule(s) any more, so packaches leave the mangle without further processing.
Last filter in mangle tis suppose to ´catch´ all traffic not catched by all previous rules (“left over traffic”) and markes it then with conn mark “low”.:
chain=forward action=mark-connection new-connection-mark=low passthrough=yes
If I now start a port 80 download test the first ´accept´ rule jumps up in speed while that last rule that marks all also jumps up in speed.
I would expect that last filter would not see that traffic at all anymore since the action=accept from the first rule told package to leave the mangle process without further processing…
src-address=84.232.92.4
What is that address? Before or after NAT? Source NAT happens AFTER the ‘forward’ chain.
This is the public address of my PC. Given by my border router that does do the Nat from private to public.
The router I wrote this filter in is in between this border router and the Cisco of the ISP and is in bridged mode.
The mangle runs on the bridge and does do the QoS.
I rewritten the complete mangle anyway and added ´bridge-port` as classifier on all filters that creates conn. marks (before I had no incoming or outgoing port set nor src address. I presumed ´forward´ means traffic running ´through´ router so the mangle then filters this traffic. I realize now it was probably filtering all traffic twice. Going out and when it came back.)
I have the feeling the QoS works now good and I don’t have the problem anymore that some traffic was given low priority by my last filter that catches all left over.
The ´accept´ action now also seems to work like it should.
Ok, same issue again, now in firewall filter:
/ip firewall filter
add action=accept chain=forward comment=“allow new connections” connection-state=new disabled=no src-address=172.25.48.4
add action=accept chain=forward comment=“allow established connections” connection-tate=established disabled=no src-address=172.25.48.4
add action=accept chain=forward comment=“allow related connections” connection-state=related disabled=no src-address=172.25.48.4
add action=drop chain=forward comment=“drop invalid connections” connection-state=invalid disabled=no src-address=172.25.48.4
add action=drop chain=forward comment=“drop everything else” disabled=no
This makes any traffic for 172.25.48.4 going ´through´ the router impossible.
While manual is clear and states that action=accept make package accepted and not pass to any other filter.
In my opinion this would mean it is accepted and passes through. But on the contrary, the last filter still drops it!
Only by disabling last filter traffic is possible. But then the whole setup is useless. ALL traffic is now possible, even unwanted…
You aren’t accounting for return traffic, where that IP is the destination IP address.
Move the rules for established and related traffic up above the one for new connections, and remove the to-address qualifier.
Djeee, you never sleep?
Anyway, I just woke up because some client has no internet…
Your suggestion, that was my setup until last night.
I came with the src address because I wanted to filter out all traffic coming fm address range that is not allowed by me.
(I see in conn. tracker addresses fm local side of CPE’s. I don’t know how it is possible but last night found over 200 connections in my border gateway that carried a src address not belonging to any of my CPE’s. All CPE have an address in 172.25.48.0/20 range. One way or another some mis-configs must be around ( I have some CPE in ´bridge mode´ connect to Wifi routers. Maybe client plugs CPE cable (=WAN client point of view) into one of the four LAN ports of router where wifi router is still handing local IP’s out which then are allowed to travel on my network.)
So I have to find a way to drop src address traffic not coming from my CPE’s WAN sides. (98% of my CPE’s are in nat mode so CPE-WAN address is clients src address on my network.)
I tried it like above.
I also tried with src address list “safe” as classifier for allowed network but seem not to be able to get it done…
Any suggestions?
as fewi said, you’re dropping packets with dst-address=172.25.48.4 - don’t do it