I have a following VPN routing problem. I have a sparse list of network ranges that are inside private address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) from organisation A and I want to route the traffic to these addresses from organisation B over VPN tunnel. These address ranges get updated every now and then, so I’d like to use an address list in the router in the organisation B side, because these addresses are needed not only in routing but also in various firewall rules. The VPN connection is over L2TP/IPSec, organisation B being the client and A the server.

The access is only for organisation B to access hosts of organisation A.

For various reasons, it is not possible to use any routing protocol between these 2 organisations.

I have a pre-routing mangle rule, to set routing mark to packets having a destination address matching to the address list of organisation A addresses. Then I have a static route 0.0.0.0/0 with that routing mark to the VPN connection. This does work.

The problem is that there are no (and will not be) return routes in the organisation A side back to organisation B. For that reason, I’d need to set masquerading for the VPN interface in the organisation B side. This does NOT work. Something very weird is happening with the traffic, but the bottom line is that the organisation B side local addresses “leak” over the masquerade and the traffic does not go through. Also looking into statistics, the traffic seems to “match” with the masquerade rule, but it just does not do, what it’s supposed to.

If I instead of address list and routing mark, just create individual static routes for all organisation A ranges, then masquerade works perfectly and traffic flows fine. This is not very nice solution for me, because now I have same addresses in two places and must keep them in sync. RouterOS does not support using an address list in static route configuration, which would, of course, solve my problem neatly. Still, I see no reason, why masquerade wouldn’t work also with a routing mark.

I’m running MikroTik (RouterOS 6.47.8) and because it took some time to believe that it’s indeed RouterOS that is wrong, not me, I’ve faced the same behaviour in MIPSBE and ARM hardware versions as well as Intel CHR installation.

The description is clear and the behaviour you describe is really strange, but without seeing your configuration export, it is hard to say whether it is a bug or a configuration issue. See my automatic signature below for hints on "non-destructive anonymisation".

And indeed, if I remove mangle rule and the route, and instead add static route to all destination addresses separately (and without routing mark), it works as expected.

It works for me on 6.46.8 the way you want (with the routing-mark and with an action=masquerade rule matching on an out-interface-list rather than out-interface), but I've only tested with a ping from the router itself (ping 8.8.8.8 src-address=some.other.local.one routing-table=via-l2tp). If I disable the masquerade rule, some.other.local.one is the source address seen on the L2TP interface.

So if those two masquerade rules are the only ones in your chain srcnat, it's either the version (you run 6.47.8) or it works different for forwarded traffic.

Can you see the masquerade rule to count with each new connection? And how do you know the actual addresses leak, do you sniff on the L2TP interface itself?

I was also able to ping directly from the router via the VPN (at least the router in the other end). But I was not able to ping form other host.

Masquerade statistics counter is increased by every connection.

I did virtually identical configuration to three separate routers with identical problems. In one case, I was able to add "routing back" to the other end and therefore able to disable masquerading and it started to work. In other two cases, jury is still out, because in this case "routing back" is not possible. There I just quickly tested removing mangle rules setting the routing mark if destination matches the list and replacing routes by routing mark with individual routes for each entry in the address list. That works fine with masquerade.

Oh, and the address "leak". I was using PPP Torch in the server end router. I was amazed to see the IP address of the host I was pinging from, to appear.

I don't have a spare router that I could use right now, so I don't dare downgrading to 6.46.8 long-term. If I find one sometime soon, I'll try that.

OK

I did some tests and even tried to downgrade to 6.46 and the problem persisted.

However, I was able to go through it. The problem was triggered by the routing table entry:
And the actual trigger was that the address 0.0.0.0/0 includes the addresses of my local network. Even though the routing mark is set only using the destination matching the address list where most addresses are in the 10.0.0.0/8 range and none are overlapping with my local network. But if I replace 0.0.0.0/0 with 10.0.0.0/8 in the route with routing mark set by destination addresses (smaller ranges inside 10.0.0.0/8), it works fine. Even with masquerade.

Also the symptoms in the not-working case are extremely weird. Obviously the ping does not get around, but on the other hand, I was able to see the private addresses in the "wrong side of the masquerade" using ppp torch in the server side. I don't understand this at all. Also, if I am able to eliminate masquerade from the PPP interface, it works absolutely fine with 0.0.0.0/0 routing with routing mark.

All this seems to work identically in 6.46 and 6.47. I refuse to believe that this is a configuration case. There is something fishy in routing by routing mark + masquerading PPP interface. It works for me now and the work-around is not overly ugly, but I don't see any reason why masquerade makes a difference here.

I think the problem is in:
/ip firewall mangle add action=mark-routing chain=prerouting dst-address-list=org-a-intra new-routing-mark=org-a-intra passthrough=yes
You have to put src-address-list=org-a-intra instead of dst-address-list. Try it

I think the problem is in:
/ip firewall mangle add action=mark-routing chain=prerouting dst-address-list=org-a-intra new-routing-mark=org-a-intra passthrough=yes
You have to put src-address-list=org-a-intra instead of dst-address-list. Try it

No, that's not it. Those org-a and org-b are a bit misleadingly named. The A is the server side to which the traffic is forwarded via the VPN and B is the originating one running this route marking masquerading shebang. And as I said, without masquerading, that works (but can't be used in my use case) and without route marking it works (by just enumerating the remote address ranges in separate routes) and even with routing mark and masquerading it works, if I don't use just 0.0.0.0/0 as route destination (with mark) but limit it to something that does not include the local source network.

Set the l2TP connection to have a unique IP.
192.168.200.2 and 192.168.200.3
Put that on each router.
Then tell your routers that the router has to use the VPN as the gateway.