(scenario 1) goes through routing policy rule as expected
but (scenario 2) not going through routing policy rule, it directly hitting to_modem (if exist or main) routes instead following routing policy rule
dont care about partial config in the slightest or commenting on so little information and a config is all interrelated.
Mangling depends upon well articulated requirements
identify devices/users ( internal, external, admin etc…)
identify traffic they need to execute
config, with mangles or routing rules will fall out naturally.
It is not recommended to use both methods at the same time or you should know exactly what you are doing. If you really do need to use both mangle and routing rules in the same setup then keep in mind that mangle has higher priority, meaning if the mangle marked traffic can be resolved in the table then route rules will never see this traffic.
if that is true how (scenario 1) working?
i want to do it because there is no way to specify [lookup-only-in-table] in mangle so it fallback to main route, without routing rule policy.
how to achieve this (scenario 2)?
I included my code, please check this now.
In this code iot_user hitting fiber_route , all ok, working as i expected
but modem_user and fiber_user not going through routing policy rule, instead these hitting main route
MANGLING…
I understand the first rule which basically states for any user connecting to login gateway, allow this connection to occur.
I presume because you failed to provide any requirements information…
one cannot makes heads or tails of what you are trying to do after that…
Normally, forgetting hotspot, one would use three subnets, trusted, iot, guest and make them VLANS.
Or if you need to identify three different groups of users within a single subnet, not as easy, via source-address-lists.
One can easily work with address lists, or subnets, or interfaces,not sure what you are doing or how hotspot is involved.
Also one does not mangle and use routing rules unless one is very skilled as results may not be as expected.
Mangled traffic ignores routing rules for example.
’
In summary, without a detailed set of requirements on how the two WANS are to be used as would be described in requirements
(including primary secondary, or failover or load balancing, plus any vpns, or any port forwarding explained, not much more I can offer )
1 and 2. i want bridge device to go through firewall that why added following code (although removing them won’t affect hotspot)
/interface bridge settings
set allow-fast-path=no use-ip-firewall=yes
I do not know are you trying to tell, i am not talking about vlan or separate network, this is all about, routing policy rule, i do not want modem as main route, modem_user>modem_route specified in routing policy rule
in iot_user case routing policy rule working
in modem_user and fiber_user routing policy rule not working
why i want to achieve this?
reason 1: because, this is confusing me, why iot_user works and others don’t
reason 2: because, mangle doesn’t have [lookup-only-in-table] which is why it fall back to main, mangle default behavior is [lookup]
my requirement is: i want some user to go through modem, some through fiber based on hotspot user profile packet marking, out could be modem,fiber,vpn etc.
I just want to know why different behavior for same identical mangle rule coming from preroute with IP and with packet marking? why one is respecting routing policy rule, other not?
how to achieve [lookup-only-in-table] with mangle if routing policy is ignored?
I can still achieve by dropping with filter rule and mangle, but still question is why routing policy rule ignored? Is this a bug? Or intentional?
In version 6 it was [lookup] but in version 7 it now is [lookup-only-in-table].
In fact, even local routes are not examined when you have a routing mark, making it necessary to only apply the routing mark for traffic that will leave your local router and -network (e.g. make an address-list with your local addresses and exempt that).
Also, for IPv6 it is necessary to have a routing rule that says “routing mark X action lookup(-only-in-table) table X”.
Without that, routing marks do not work in IPv6. In IPv4 they work without it.
My version is 7 latest stable as of now. I can see it still MTs mangle route marking behave like [lookup] fallback to main if it can’t find route it is looking for.
leave ipv6 for now, just clarify one thing, why above example working two different way?
what am i missing?
.
As I ran more test on it, it seems a bug. I opened a support ticket as BUG, Lets see. What they say. The problem is:
if i mark-route with src-address to new-mark-route it goes through routing policy rule
if i mark-route with hotspot user’s packet-mark to new-mark-route it does not go through routing policy rule
Note: not only hotspot user, if i use packet-mark to mark new-mark-route it does not go through routing policy rule
.
I don’t understand what you mean with “if it can’t find route it is looking for”.
You have destination 0.0.0.0/0 in your route tables so it ALWAYS can find the route that it is looking for.
The only issue will be that this may not be the route YOU expect it to find.
You need to make sure that the routing mark is only set for traffic that you already know is going outside.
So NOT traffic destined for the router itself (e.g. DNS service, hotspot service).
To work around that you NEED to have an exception list of addresses/networks you do not want to mark, OR you need to copy all routes created automatically in the main table (with C flag, “connected”) into all other tables.
(scenario 1) goes through routing policy rule as expected hits to_wan>wan_route
(scenario 2) not going through routing policy rule, it directly hitting to_modem (if exist, if not exist main) routes instead of following routing policy rule which should be to_modem>modem_route
why would it hit main if routing policy rule is [lookup-only-in-table]. do you get it now? it should not hit main.