mark packet based on a specific ip in a eth interface?

hello,
i need to mark some packets for PBR based on which IP of the local interface on the routerboard the station used as gateway, but i can’t find any info about that.
for example:
ether0 has two ip: 192.168.0.1/24 and 192.168.0.2/24

i want that stations that use .1 go through WAN1 and the ones with .2 go through WAN2(as well as dstnat rules but those are no problem afaik masquerading should take care of that i think).

¿how can i mark the packets with that?, i can’t use in-interface as it will match any packet, i’ve checked the manual for mangle and it doesn’t has a “IP%interface” like in ip route gateway.

i don’t want to use address lists as source for the routing mark because i want the freedom to chose which ISP to go out based on the station default gateway, address lists need to be maintained on the mikrotik which is a hassle in this environment. Using another ether interface is also not possible

There is no way you can detect “which gateway address a station uses” to send traffic to the router.
Hence, there is also no way you can mark packets based on that.

What you want to do (i.e. the way you want to do it) is impossible.
Of course you can use VLAN or different IP subnets to achieve similar behaviour.

it seems so, i did a ton of digging and seems to be a limitation of iptables as well…

i’d use vlan but then i’d have issues on the switch because i don’t know if the port would accept being in PVID 1 and having vlan 1 as tagged as well..
EDIT: nope, it farts rainbows, can’t have the same vlan as tagged and untagged on same port…

i’m going to have to use two ethernet interfaces and then simply do mark routing based on the in-interface, right?

It is not “a limitation of iptables”. It simply CANNOT BE DONE.
Why? The “IP address of the gateway being used” never appears anywhere in the packet.
The client system has a routing table, it wants to send some packet, it looks up the destination IP of the packet in the routing
table, and finds the gateway address. (e.g. it is the default route, it finds the default gateway).
It then does an ARP request to get the MAC address of that gateway, and sends the original packet to that MAC address.
The router (the MikroTik in this case) receives the packet because it is sent to its MAC address, looks at the destination,
sees it is not the router itself, and repeats the operation (lookup in the route table, etc). The IP address of the gateway
does not appear in the packet. It was only briefly know in the client when it routed the packet, but does not travel along
with it. So there is no need to look for a solution.

Of course, when you would assign multiple subnets to the same ethernet interface (e.g. 192.168.0.1/24 and 192.168.1.1/24),
you could still not know to which of them it was sent, but you could guess so by looking at the source address of the packet,
which is the address of the client, and it would be 192.168.0.x or 192.168.1.x for the two subnets living on the same ethernet.
Then you can mark the packets depending on the source address.
Of course, the problem now shifts to “how do you get the proper source address assigned to the client”.
It cannot be done by completely dynamic assignment using DHCP, because the DHCP server will not know from which of
2 pools (192.168.0.x and 192.168.1.x) to pick the address. However, you can use static assignments for part of your
clients (fixed mapping of client MAC address to IP address) to work around that.
Another new problem for you could be that the clients now cannot communicate to eachother directly, only via the router.
You could fix that by telling the clients that the subnet mask is /23 instead of /24, so they see these two /24 networks
as a single network.

well i can’t separate the subnets nor change the internal addressing at all, i tried setting the ips on different interfaces but the second i enable the 2nd ip all traffic to the RB stops so apparently it’s not supported to have two IP from teh same subnet in different interfaces(and i can’t have them on the same interface either).

so it seems that i’ll have to retain two separate routers for each isp as i’m doing now, so much for simplifying the quantity of devices :confused: