Can someone explain to me why just ‘mark routing’ with a source IP address works, but using connection marks to try and do the same thing doesn’t work?
I.e. with connection marks. Packets match, routing matches, but typing “what is my IP” in google shows it going through main routing tables ISP
I figured they should yield the same result? All packets from that source are being marked and then packets with those marks are being routed (if ‘not’ coming from the internet side so the return packets get delivered instead of also being policy routed)
So how is that different to just matching the IP address and then routing packets?
My guess is order of operations limiting the fact that the new marks aren’t applied instantly at that line for future processing, so a matcher on something that was placed in this current run wont match.
Why not just set all of them to src-address=192.168.1.0/24? In this current scenario, it will have the same effect.
The reason why i’d prefer to use connection and packet marks are for other operations i.e. queue’s, changing TTL etc. It makes more sense to only have to create 1 ‘top tier’ rule to match all traffic from an IP address
I.e. lets say its not 192.168.1.0/24 but is instead 192.168.1.55 which is the IP address of a server
Let’s say the servers IP address changes to 192.168.1.56 well I only have to change 1 rule, the first one that makes the connection mark.
Otherwise if every rule relies on the IP then I might have to change 6 different rules
And lets say another 2 servers are added - 192.168.1.60 & 192.168.1.61 - it’s really simple to make 2 copies of the first connection mark rule, update the src-address and that’s it. Otherwise I have to create 3 copies of each rule. Or create an address list and then change all rules to match to an address list instead
All what you have described here can be solved by using src-address**-list** instead of src-address in that single rule.
Nevertheless, I agree with you that your connection mark → packet mark → routing mark mapping as you’ve described it above should work the way you expect it to work. However, I have never used the middle step and I always translate the connection mark directly to routing mark, and I assume most people use it the same way like I do. So maybe there is some undiscovered issue in the connection-mark to packet-mark translation or in the packet-mark to routing-mark translation. But the first thing I’d double check would be whether the in-interface of packets from 192.168.1.0/24 hasn’t become a member of interface list name=InternetFacing by mistake, and only the next step would be to replace packet-mark=PolicyRouting_p by connection-mark=PolicyRouting_c in the action=mark-routing rule.
FWIW, I also encountered this same syndrome, not sure if we share the same circumstance, but here’s how I solved the problem in my case:
It turns out that, in my routing table for a specific routing-mark (say we call it PBR), I simply forgot to specify routes back into my private network, such that it was populated by just a single default gateway to the internet.
Expectedly, outgoing packets with routing-mark PBR can reach the internet through the gateway specified in PBR routing table. When the internet replies back, there are no routing-marks this time and so the main routing table is used, and packets find their way back into the private network.
However, in the case of mark-connection, the reply coming from the internet will still be marked as PBR, therefore, the PBR routing table will be used. And as routes back to my private network were missing, these packets get incorrectly sent back out to the internet through the solitary default gateway.
Okay, so my post is wrong altogether. As a matter of fact, I should instead be thanking you the OP, as your problem is actually the solution to mine. I can avoid specifying routes in the PBR table by simply not marking the replies from the internet.