I’m trying to pass all traffic entering an interface (rule #3) but it’s catching nothing:
Instead all traffic is caught by the later rule (rule #6) which just like the intended one, doesn’t specify
src.addr
. Why specifying the interface breaks the otherwise identical rule? They are processed in order, aren’t they?
Thanks.
You forgot to show the config…otherwise there is no context
/export hide-sensitive file=anynameyouwish
Oh man, I’m sorry, I’m still learning the rules around here.
I attached the file now. If it’s all scarily open it’s because it sits behind other firewalls, IDS/IPS and proxies already. I promise I’m not that reckless. 
This will be the “distribution” firewall, so to speak, it’ll filter outbound traffic only–or rather inbound traffic on a given interface from a host with destination to 0.0.0.0/0.
iftroubleshoot.rsc (39.8 KB)
What device is this?
I do not see any bridge configuration.
There’s no bridge, it’s a router. 
It’s not a device either, it’s a CHR.
It seems not to obey the firewall at random or something; I just blocked myself and I still can communicate out.
I have full access to what shouldn’t be allowed–everything outside of RFC1918. I doubled-checked the machine’s network and everything. IDK what’s up. 
Is very hard to follow any reasoning if you have all interface and items numbered like 0011.
I lost all context of every instruction.
You have configured the device, you know that.
The export is a rebus full of thing to remember at memory.
Even the screenshots without context they make it appear as if
you don’t know that, in the firewall, if you accept it, you can no longer drop it later with another rule.
Lets recap.
You have configured:
Are you sure that IPv6 isn’t used for your tests?
I'm having a hard time following what you're trying to say, but, if the last line is meant to sum it up… Interfaces are named to coordinate IP addressing in both IPv4 and IPv6. So it's easier just assigning them a number than some meaning. Whatever the case, I understand that rule processing end when traffic is accepted, I also know that in Mikrotik traffic can be fed from once chain into another, and that input chain is traffic going toward the firewall itself, so accepting traffic in the forward chain to RFC1918, even though it covers all IP addresses of the firewall, should not match traffic going to the firewall, specially since I put the firewall-bound rules always first (y'know, for safety).
I already posted all the other values in the exported config of the firewall, I think the table should be enough since nomenclature is straightforward. Bottom is rules that should be accepting traffic aren't, rules that should handle it don't. I may be new to Mikrotik's OS but I've enough experience with networking to know this shouldn't happen.
Also, one of these rules randomly started accepting traffic after a restart, then at the next restart it stopped again. It's sort of messy.
Thanks for answering and for your patience!
Yeah, that’s about right. I’m focusing mainly on VLAN 9, which is where I’m testing from. I blocked it whole (after the allow rule to the firewall itself) but it didn’t matter.
As you may have noticed, there’s no NAT or public IPv4 address, the connection to outside is handled by a set or firewalls in front of the CHR, that’s where IPv6 is cut off. The default gateway is 172.22.22.2, where also are all the edge devices and DMZs. All are in the 172.16.0.0/12 address space. Then there’s the 192.168.0.0/0 space for remote gateways. There’s no static routes or anything because they all are in the default gateway of the CHR.
The configuration posted and screenshots don’t correspond exactly, however the rules are working as expected - in the image ‘Screen Shot 2021-08-04 at 04.33.00.png’ the traffic source address is 10.0.0.32 which will match src-address-list ‘rfc1918’ referenced in rule #1 and be accepted, so never reaches rules #4 or #5.
@tdw you right
As already wroted but the OP do not understand:
you don’t know that, in the firewall, if you accept it, you can no longer drop it later with another rule> .
Dear @senseivita, discúlpame, but I do not want to participate in your confusion, and therefore I do not help further.
Perdón.
If you need help with something else, on another clear subject, I am happy to help, but for now
Adios.
Source address?! What do you—hold on a sec while my mind settles down.
(BRB)
Okay..oh man! It’s a lot.
So I went back on this haphazard log I had been keeping of what I’m setting up, tweaking, a few screenshots: at some point I that RFC1919 was in the next column i.e. destination, after posting though I focused away from this a bit since things were online it could wait. Some routes started failing, traffic started to get blocked. It took a while to trace it down to mismatching DNS which the firewalls and reverse proxies depend on. Bare-metal Domain Controllers had stopped replicating with virtualized DCs, I traced it to non-working IPv6, further traced it to no multicast traffic crossing in/out the hypervisor cluster. The CHR was occupying the place of the device that handled this before. I installed the multicast routing module (PIM), rebooted and now the rules were working. I hadn’t configured anything yet, IPv6 layer 2s still split.
I rebooted again, and rules stopped working. At that point I got desperate selected all rules and deleted them. Started over copying rules and I assumed that was when I missed putting RFC1918 in scr rather than dst. Perhaps the best thing is that to draw nice curve angles I blew the screenshots over 400% and I still missed it!
Just know I redid everything again and I got this in Firefox:
I had never felt good about seeing that. Rebooted a few times, intentionally screw things up a little but it keeps everything seems alright now. I don’t know what it was, I know that I made it worse though, if only snapshots could be used.
I can’t thank you enough for your patience, if you ever need a kidney or something. 