Hello I have a ccr1016-12s-1s+ cloud core router. I am using it for L2TP with ipsec VPN GW with hapMini client for road warriors.
We are using FW ADDRESS LISTS in our rules.
Example:
We have 10 client address, in a list called A
1.1.1.1
1.1.1.2
1.1.1.3
1.1.1.4
1.1.1.5
…
1.1.1.10
We have another list called B for servers:
2.1.1.1
2.1.1.2
2.1.1.3
2.1.1.4
…
2.1.1.10
We have some rules where we are using these address lists.
Forward - address list A → address list B - accept.
Some of the address is working nice from B (replying to ping). BUT NOT ALL!
FW rule is top on the list to avoid problems.
GW and everything is same on every server. So should ALL ADDRESS WORKS or NONE OF THEM!
I think MT routerboard can’t handle properly the lists in FW rules. Am i right?
Did you meet some kind of problem?
So i think there is some problem with FW address lists. Am i right?
If it works for one, it should work for all, unless you forgot to add an address in your list, which you would have spotted fast enough.
A common problem that I see often in my classes is computer’s personal firewall. Disable it and redo your tests.
Make sure also that you have a rule that allows traffic from B to A. Again, I’m guessing it’s there already, but just in case because it’s not showing in your example.
Nope. None of them is the problem. No firewall on servers. So question is still open and i belive FIREWALL ADDRESS is not properly handled in MT!
Maybe if some of the address is on multiple list can also cause a problem?
For example if 2.1.1.2 is member of B but also member of X Z and H lists?
Of course rule of A → B - accept is the first firewall rule.
Crazy thing… some kind of selection algorythm is applied on the address list before they can be used by the rule.
If you have a list like this:
1.1.1.1
1.1.1.2
2.1.1.3
1.1.1.3
1.1.1.4
Then you wont reach 1.1.1.3 and 1.1.1.4 because they are behind higher address: 2.1.1.3.
In my case this was the situation: https://forum.mikrotik.com/download/file.php?mode=view&id=34618
So i could reach 100.50 and 100.124 but i was not able to reach 100.1 100.45 100.48 and so on…
If i put them before the 226.1 then… tadaaam its working.
I would be interested what kind of shitty algorythm is doing this… SO I report this BUG, or shall i call it a feature?? .
However thank you for your kindness to trying to help… but i realized its a BUG
Your shitting me, the firewall rule when accessing an address list, does not treat each address as an individual entry and tries to get cutsy with some sort of half baked list cutoff method??
Unless it says, in some wiki somewhere that order is important in the address list, it shouldnt matter.
I agree with Anav. Order SHOULD be irrelevent. “Grad that address list and use it to check for a match”.
I couldn’t care less about order. Imagine the hassle of redoing the entire list if there’s an order issue?? Hope you guys are good with Excel and sorting
You have misinterpreted my answer: current algo is the right way to go, as it WILL save on CPU cycles, BUT development => Mikrotik should have ordered the list first before using internally.
I did NOT meant that we => the users should be doing the ordering.
Basically, I fully expect to be two versions of each list:
as specified by configuration
as optimised for internal use
Each time the orignal list changes, the internal one should be updated.
Sorry no capiche… The address list is just that, the order should not be a factor or important, each address is equal in an address list.
If you want a new feature, an ordered address list, then call it something different such as (address-list-ordered). How that is implemented and used will be mikrotik programming, but I can see them allowing any order of entry and then the algorithm auto-orders the list each time you hit apply.
with no order, each entry has to be considered → this will result in 100 comparisons => linear search
with order, the order can be used to search for a possible match, starting in the middle, if “equal” → bingo, if “smaller” → take middle of lower half, if “bigger” → take middle of higher half
this algo will travers the same list of 100 entries much faster
Example your are not quoting Mikrotik Address lists per se, which are built upon the premise of INCLUSION (each independent) or EXCLUSION (each independent), all some or none scenarios - whatever is on the list is either included (accept), excluded (dropped), etc…
You wish to create a new capability called an ordered-list, which then all kinds of programming rules can be applied.
.
