I’m doing some tests with my home router installation and it seems that I can’t get dst-address-type=local match to work. I just add first rule in input chain like this:
Then I just do ping 192.168.1.254 and counter does not increase. Address 192.168.1.254 is assigned to eth5. When I watch traffic with torch, I can see that ICMP packets arrives with dst address of 192.168.1.254.
When I remove dst-address-type=local from the rule, then counter starts increasing. Intrestingly, if I invert dst-address-type=local rule, counter still does not increase. I do not really understand what is wrong. It should be all straightforward here, but for some strange reason it does not work as expected.
By the way, I’m running RouterOS version 7.14. WOuld appreciate if anyone has good ideas on how to troubleshoot this.
EDIT:
Small update. When I add above mentioned rule with dst-address-type=local from the beginning, then it works, counters are increasing. Then I change the rule, so that it starts blocking packets, something like adding src-address-type=local, which obviously will not match packets. Then I change everything back as it was originally dst-address-type=local and rule does not work anymore (or at least counters are not increasing). Then I need to remove and re-create rule and it works again. It also works, as mentioned above, if I remove dst-address-type=local.
EDIT2:
I have another RouterOS machine running version 6.49.10, and this behavior described above does not exist. This router works as expected. Could this be some kind of bug? Anyone can test it on 7.14?
I tested it on Mangle chain prerouting: dst-address-type=local or src-address-type=local. Its seem that on prerouting only one known, either source or destination.
Edit:
Btw, it works on Mangle chain=input, dst-address-type=local or src-address-type=local
Thanks for checking! By saying it work, do you mean that you also have this issue as me, when after changing rule back to original, it does not work anymore? For me it is like this:
add only dst-address-type=local rules works, counters are counting
add also src-address-type=local rules stops counting packets
remove src-address-type-local rule still does not work, even though it looks exactly as rule number 1
Then I have found that adding src-address-type=unicast and then removing it helps to restore original rule behavior as it was in (1).
I have created bug report on this beginning of March, but never heard back from Mikrotik. Waiting.
Is there anybody who runs ROS 7.14 or 7.15 and are willing to test step-by-step this issue as I described in the first mail? I would really appreciate your help. The problem is that I have create a bug report 3 months ago and I have never got any response from MT. It would be nice to see if anybody else can reproduce this issue.
You do not need to destroy or change your existing rules. Just add new rule for a test, make manipulations with address-type=local and post results here.
User Lokamaya tested it, but it was on Mangle chain and I never got any information on ROS version or hardware being used. I also have no issues on my other 6.x devices. I have got this issue on 7.x device.
Id rather not play what if I do this or that on a config…useless.
Instead state reality and requirements
a. identify user(s)/device(s) and groups of users/devices including yourself as admin
b. identify what traffic they need to accomplish.
The config will fall out naturally from well thought out detailed requirements, and a network diagrams helps one in that process.
I wonder weather dst-address-type is available prior routing, in a mangle rule?
It would need at least a lookup in the router’s address list. Not impossible, but if the router is the geteway for a long list of vlans, then the address list will be long and it would be processed for each packet reaching that rule. I am not convinced it is done.
chain=input is processed after routing, and in the routing decision process dst-address-type can be completed. Makes more sense to me.
And in chain=input, I guess dst-address-type has to be local, I don’t think it still refers to the prerouting dst-address.