I have a feeling that I already know the answer to this, but I’m hoping that I am overlooking some clever option or workaround.
Is there any way to influence which routing table packets generated by the router itself get processed by?
Here’s the situation: postulate 2 VRFs on a MikroTik router. Then postulate a common, overlapping prefix shared by both VRFs (e.g., 192.168.1.0/24), and the MikroTik holding 192.168.1.1 on an interface in each VRF. And then finally, postulate 2 devices, both associated with a different VRF but which both hold the same IP address within their respective VRF (e.g., 192.168.1.2). This is, of course, perfectly doable, and part of the point of VRFs.
But now, on top of all of this, I want device 1 in VRF 1 with IP address 192.168.1.2 and device 2 in VRF 2 with the same IP address 192.168.1.2 to both be able to take advantage of services offered by the host MikroTik at 192.168.1.1 (for example: NTP, TFTP, and so on). So far as I can tell, this is impossible. The problem is that the “output” chain always traverses the “main” routing table, so the MikroTik gets the NTP request or whatever from the client, but there is “no route to host” when it tries to send a response. I can make it work for one of the two clients either by adding a route entry to the main routing table or adding to IP route rules, but I can’t have it work for both clients (as long as they both have the same IP address).
Is there no way through connection tracking to have the MT respond via the VRF/table that the incoming request was received on? If not, any hacky workarounds that anybody might suggest? (I could accomplish this with MetaROUTER, but I don’t want the overhead if I can avoid it.)
Thanks. I am definitely sure that the first example wouldn’t work, because you can’t match on out-interface until the out-interface has been determined, and it can only be determined once you have already picked and traversed a specific routing table, so by the time out-interface has been determined, it is already too late.
However, your second example worked perfectly! It makes perfect sense, and I could swear that I tried something similar to this, and I was surprised when it did not work, but then later I managed to rationalize why it didn’t. I’ll have to figure out now what exactly I was doing wrong the first time!
It also happens to work just fine if I mark the connection in the “input” chain instead of “prerouting”, so that I am not marking all traffic being sent out by hosts on that VRF.
You are correct in thinking that the “output” chain is after routing decisions are made. But the “output” chain apparently has a “routing adjustment” phase, which I assume is used if the routing mark was changed.
See: https://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6
My current policy routing mangle rules are as follows:
Trying to account for both input and dstnat’ed forward traffic.
Also using packet marking on connection marked packets seem to be recommended, but the manual doesn’t seem to mention to much about all this.
Correct, route markings in output chain for locally generated traffic will be taken into account in the “route adjustment”, last phase of output chain, as mentioned.
