its not clear yet, i believe bug no much information about that in changelog also, i stay in 7.2.1 until this bug fixSince routeros version 7.2.2. mark routing has a higher priority than routing/rules. version 7.2.3 and 7.3 also like this.
Is this a bug or a feature change?
Why isn't there any information about this in the changelog.Mangle has now strictly the highest priority.
/ip route
add dst-address=0.0.0.0/0 gateway=xx routing-table=wan1
add dst-address=0.0.0.0/0 gateway=xx routing-table=wan2
/ip firewall mangle
add chain=prerouting in-interface=LAN connection-state=new per-connection-classifier=something/0 action=mark-connection new-connection-mark=wan1
add chain=prerouting in-interface=LAN connection-state=new per-connection-classifier=something/1 action=mark-connection new-connection-mark=wan2
add chain=prerouting in-interface=LAN connection-mark=wan1 action=mark-routing new-routing-mark=wan1
add chain=prerouting in-interface=LAN connection-mark=wan2 action=mark-routing new-routing-mark=wan2
/ip route rule
add dst-address=192.168.0.0/16 action=lookup-only-in-table table=main
Name FIB
aaa yes
bbb yes
D main yes
wg-1 yes
wg-2 yes
/routing rule
add action=lookup disabled=no table=main
hem i thought remove all checks in FIB it wont show in mangle routing mark, and how about 0.0.0.0/0 destination are we need to delete this too in ip route?It was curious what was up with this and it indeed a nasty one. My config was also broken. Looking in the mangle pre-routing routing marking the counters did not increase. Only the one catching traffic that should be mangled but has not been not mangled and setting the TTL to zero, to avoid traffic going out a wrong exit.
In the new-mark-routing lines, I had the condition that traffic should be routing table main. Now traffic is not automatically put in table main first, and then you can change that to an other routing table.
My routing table looks like this:
I have had to remove all checks on routing table main and I have no replacement for main on the moment.Code: Select allName FIB aaa yes bbb yes D main yes wg-1 yes wg-2 yes
Is this the way to get the previous working back to have all traffic be default "main"?
Code: Select all/routing rule add action=lookup disabled=no table=main
add action=mark-routing chain=prerouting new-routing-mark=WireGuard routing-mark=main
/ip firewall mangle
add chain=prerouting routing-mark=main action=log log-prefix=1-main
add chain=prerouting routing-mark=!main action=log log-prefix=1-notmain
add chain=prerouting new-routing-mark=test action=mark-routing
add chain=prerouting routing-mark=main action=log log-prefix=2-main
add chain=prerouting routing-mark=!main action=log log-prefix=2-notmain
add chain=prerouting action=mark-routing new-routing-mark=main
add chain=prerouting routing-mark=main action=log log-prefix=3-main
add chain=prerouting routing-mark=!main action=log log-prefix=3-notmain
So it seems that this undocumented routing priority changes they understand as an "issue" I stay on 7.2.1 or 6.49.5 and waiting...Hi,
The issue is still unresolved that could cause this, we are working on possible fixes. I cannot give you any specific ETD for this, unfortunately.
Best regards,
Oskars K.
So now it sounds like an intention from your side. Then I do not undestand why this major change was not documented in fw 7.2.2/7.2.3 change log (?) and why you cannot provide step-by-step help what to change in related config of i.e. dualwan scenario to be working again?"issue" in a sense that many expect old behaviour. Probably this will be solved by making order selectable.
Thanks but I cannot see the posiblity to add this option to rule via Winbox?With current version, if you don't want something use another routing table, then don't mark routing for it. So e.g. if problem is access to router like in this example, then add dst-address-type=!local to first two rules.
Sob wrote: With current version, if you don't want something use another routing table, then don't mark routing for it. So e.g. if problem is access to router like in this example, then add dst-address-type=!local to first two rules.
OK, did a try, it solves unreachability of the router itself but still issue with nonworking routing rules under Routing/Rules ?Was referring to the mangle rules in the reply from sob (in the linked post):
Sob wrote: With current version, if you don't want something use another routing table, then don't mark routing for it. So e.g. if problem is access to router like in this example, then add dst-address-type=!local to first two rules.
Because in this release, the routing-mark assigned by a mangle rule cannot be superseded using a routing rule. So the rules are not "nonworking" per se, it's just that their purpose was to supersede the verdict of the mangle rules and they can't do that any more.OK, did a try, it solves unreachability of the router itself but still issue with nonworking routing rules under Routing/Rules ?
I have a static routing and related routing rules to reach directly (not via internet) some public IPs assigned to local devices or other routers in our network but also some sort of local subnets and device IPs to reach localy...all of them does not work. As I mentioned above, if developers do silently this major change, I would expect BIG warning and step by step manual what need to be check and change in the configuration to meet this new router behaviour. Now it seems that they will provide some option to switch router to the previous standard behaviour.Because in this release, the routing-mark assigned by a mangle rule cannot be superseded using a routing rule. So the rules are not "nonworking" per se, it's just that their purpose was to supersede the verdict of the mangle rules and they can't do that any more.
We'd have to see the configuration export to say how exactly the mangle rules need to be modified to gain the same effect you currently obtain by overriding them using routing rules.