Hi there,
I’m currently trying to implement an IKEv2 server in ROS (6.48.1) for macOS (Catalina/10.15) clients. Everything works great but only the first network in split-include is reachable. I have found multiple posts on this forum blaming the Apple VPN client. But I don’t think the problem is on the Apple side at least on my case. I think the problem resides on the dynamic policy generation on the Mikrotik side. Looks to me that the macOS client does add routes via the VPN interface for every network listed on the split-include parameter, but the dynamic policy generated on the router only includes the first network.
So the question is, how can I tell ROS to generated a policy for each network in the split-include parameter once a client connects?
Here is an example of the only dynamic policy generated once a client connects, as you can see, it only includes the network 10.10.9.0/24:
And here are the routes generated on macOS for that connection, this is printed with netstat -nrf inet, as you can see both 10.10.9.0/24 and 10.10.10.0/24 are added:
Known limitations
Here is a list of known limitations by popular client software IKEv2 implementations.
Windows will always ignore networks received by split-include and request policy with destination 0.0.0.0/0 (TSr). When IPsec-SA is generated, Windows requests DHCP option 249 to which RouterOS will respond with configured split-include networks automatically.
Both Apple macOS and iOS will only accept the first split-include network.
Both Apple macOS and iOS will use the DNS servers from system-dns and static-dns parameters only when 0.0.0.0/0 split-include is used.
While some implementations can make use of different PFS group for phase 2, it is advised to use pfs-group=none under proposals to avoid any compatibility issues.
Maybe Apple has changed something and now is capable of more than one route.
But I think you have to do more general police and combine your two polices into one. I think that Mikrotik can generate only one dynamic police.
So in your case, I’ll do
If those two networks are only examples, and can’t be group so easy to one bigger network eg 10.0.10.0/24 and 192.168.1.0/24 I’ll do a general rule with src-address=0.0.0.0/0 dst-address=10.10.200.0/24 and add rules to firewall to permit only 10.0.10.0/24 and 192.168.1.0/24
And also just for kicks added a windows client to the mix just to see the difference. I had to disable PFS since windows does not support it apparently. But in the end I managed to connect both clients at the same time.
The generated policies that are based on the same template, are different for some reason, check the src-address. Something is broken here and it does not look like the client.
# This is the policy generated for macOS
2 DA peer=roadw tunnel=yes src-address=10.10.9.0/24 src-port=any
dst-address=10.10.200.200/32 dst-port=any protocol=all action=encrypt level=unique
ipsec-protocols=esp sa-src-address=a.a.a.a sa-dst-address=b.b.b.b
proposal=default ph2-count=1
# This is the policy generated for Windows
3 DA peer=roadw tunnel=yes src-address=0.0.0.0/0 src-port=any dst-address=10.10.200.199/32
dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp
sa-src-address=a.a.a.a sa-dst-address=b.b.b.b proposal=default
ph2-count=1
Here is how the routing tables look on the clients
Windows
I love how Mikrotik went out of their way to make a non-standard client like windows work out of the box by doing the DHCP magic, I really do. But I also think standard compliance should come first, and from what I can tell, the IKEv2 macOS client is doing it’s job correctly here and RouterOS is not. I wonder how a StrongSwan client would behave in this case, I might just try that next and see.
Anyway, I would love to be corrected on this so if anyone can jump in and prove me wrong I would be delighted.
I’m not sure if I understand your problem. Do you wonder why those two polices are different?
In my opinion it is because of windows. As you can see in a fragment from wiki which I’ve quoted already
Windows will always ignore networks received by split-include and request policy with destination 0.0.0.0/0 (TSr). When IPsec-SA is generated, Windows requests DHCP option 249 to which RouterOS will respond with configured split-include networks automatically.
Hi fpawlak, thanks for your reply. No, I’m not wondering anything, I’m simply stating the fact that IKEv2 seems to be broken in RouterOS when used with split-include, and that it only works with Windows clients by using a non-standard behavior of that specific client. Everything else in my posts is me trying to proof that fact.
As for the security warning on the Mikrotik Wiki, I don’t really care, this is a lab and security is not important or relevant to the conversation. If this ever gets to production, that warning will be taken into consideration. And no, there is no need for firewall rules on my setup other than for security purposes.
I haven’t tested Windows 10 client against other IKEv2 servers. But I think that Windows is not working properly, ignoring split include and asking for 0.0.0.0/0 police. But I may be wrong.
You are right, windows does not behave in a standard way, and yet (thankfully) it works with RouterOS. The real problem is that clients that do behave in a standard way, don’t work with RouterOS. Hopefully they will soon.
I have the exactly same situation. On Windows 10/11 I get all the routes and the policy being generated is from 0.0.0.0/0 to whatever network was defined on the “Address Pool” at the IPSec Mode Config. All traffic flow just as expected. However, on MacOS and iOS, it generate routes for everything on the split include but, the template generate only a single policy, for the first split include network.
That is definitively a RouterOS issue. I want to move away from L2TP/IPSec to IKEv2 tunnels but as it seems, I’ll need to move away from MikroTik if that simple case isn’t supported
Have you tried to talk to MikroTik support already?
With ROSv7 I switched from IKEv2 to WireGuard and my problems with more than one subnet as interesting traffic for the VPN tunnel are now gone. Sorry IKEv2, WireGuard is more versatile and simple to configure and deploy!
