Hello there. I feel sad I have to post here since it’s the first time I can’t get things working as I’d like on a Mikrotik router…
Context:
- RB3011, Firmware 6.47.8 (had port flapping with 6.48…)
- Multiple subnets routed and firewalled by the 3011, say, to simplify, shared, r&d and sales
- Ikev2 server, tunnelling, on the 3011 with different modeconfigs (let’s say sales, and r&d) selected by matching the client certs DNs.
The needs/constraints:
- ‘sales’ vpn clients should have access to the sales and shared subnets, but not the r&d subnet
- as well, ‘r&d’ clients must access r&d and shared, but not sales
- vpn clients for the classical gang of three: linux,win10, osX (but that’s not the subject) and their config must be simple.
- multiple clients can be behind the same nat’ed IP, so going back to l2tp is not possible
The problem:
- I can’t distinguish incoming decrypted traffic in firewall rules from the ‘sales’ clients and the ‘r&d’ clients, so I can’t apply the same access rules for local and remote profiles.
I had some hope when seeing a connection-mark attribute (btw undocumented) under IPSec::mode-config, but it is only for initiators and not responders, so this just doesn’t work.
I only see the few possible solutions (without any firmware evolution), and each one looks kludgy, buggy, clumsy, painful or unmaintainable:
Solution 1
- periodically process the ipsec.active-peers (as there is no async notif of established SAs)
- parse the org/department from the SAs ids
- insert mangling rules matching the (addresses,ports) tuples to set a proper mark on the ESP packets
- hope the marks will be propagated when the linux xfrm handlers decrypt the ESP packets… (should, but not tested)
CONS: quite tedious…
Solution 2
- tweak the vpn clients or server config to use different ports for ike and esp udp encapsulated packets
- insert mangling rules matching the (addresses,ports) tuples to set a proper mark on the ESP packets
- hope the marks will be propagated when the linux xfrm handlers decrypt the ESP packets… (should, but not tested)
CONS: tedious, different client confs, more ports open on router, still need mangling rules
Solution 3
- force the vpn clients to emit the packets from their virtual vpn-allocated IP, for all the remote subnets (i.e. routed vpn)
CONS: requires tedious scripting and configuration on the client-side, already for strongswan, and this defeats the need for simplicity of client config and server-dictated config. Not even sure this is feasible on windows/osx.
The expected solution
- have a property on the mode-config, like “set-packet-mark”, which would ensure that all decrypted packets by the associated SA(s) would get the mark
CONS: I can’t implement it myself, this is rather a feature request…
So, questions;
- Did I miss something obvious (or not) which would make it easy and straightforward ?
- Are my usecase and my needs legitimate and common ? (looks rhetorical for me, but, nevermind…)
- What is the solution the most likely to work, until a better one is found ?
- Should I open a ticket / (Feature|Enhancement) request ?
Thanks for any help or valuable insights, and happy new year !