I am facing problems with IKEv2 routing and cannot figure out the issue. There are three players in my setup.
IKEv2 client (let us call it client - C).
Currently on macOS.
Router A) IKEv2 provider
VPN pool: 192.168.167.10-50/24
Subnets: 192.168.168.0/24
EOIP IP: 172.16.99.1
headquarters office, SAP, mail etc.
RouterOS: 6.41.1
Router B)
Subnets: 172.23.210.X
EOIP IP: 172.16.99.2
Server room at a provider, for special technology related servers (controls manufacturing processes)
RouterOS: 6.41.1
(A) and (B) are EOIP linked over the Internet. All devices in network (A) has access to (B). Perfect, lightning fast, works like magic. Routes seems fine as 192.168.168.100 is able to reach 172.23.210.100 without issues. Client (C) is able to connect (A) via IKEv2. Receives address from the pool fine. Routes are passed and can be listed. (C) is able to ping and reach everything in area (A). However it cannot reach area (B) addresses. No icmp, neither tcp, nothing.
Other clients connecting via OVPN (using the same VPN address pool) are able to reach site (B).
Is there anything special I need to setup for IKEv2? Firewall rules or routes?
Interestingly IKE clients do not create any ARP record. Should they?
I am not really familiar how IPSEC works in its deep logic. Where are the packets decrypted? Immediately on router (A) or somehow they are routed directly to router (B) which cannot process it? If so what is the workaround?
Thanks for the help.
For those who are insterested finally I figured out. It seems there is a bug in Mikrotik 6.46.1 or I misinterpret something.
Having multiple “Split Include” in mode-config causes the problem. Beside all routes are correctly pushed to client for some reason Mikrotik is responding from the first address space only. The traffic is visible in the log but packets won’t find their route back to client.
will cause 192.168.X respond and 172.0 not respond.
As a workaround I created a 172.168.X address space in our HQ. Frankly it is a hassle as all server IP-s had to be updated. Now both sites respond correctly.
One question remains to me: What is “address-prefix-length” in this context?
Not all IKE implementations support multiple split networks provided by split-include option.
If RouterOS client is initiator, it will always send CISCO UNITY extension, and RouterOS supports only split-include from this extension.
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.
In other words, it looks like split include is interoperability nightmare.
Same manual says about address-prefix-length:
Prefix length (netmask) of assigned address from the pool.
Thanks these are quite usefull information even I do not under some part of it
I read the “prefix” part but the Split part. I am bit confused why it needs a netmask at all. Does that mean that setting netmask lower than 32 will make IKE clients visible to each other?
Concerning MacOS: packets are sent and received by the router, routes are set correctly. How on earth the packet flow stops inside the router once it received? It does work under L2TP+IPSec I do not get the difference here.
I’m not sure about address-prefix-length, I used mode config only few times and didn’t really think much about details, I basically just tried the example.
I don’t have Mac, but as I read it, it will only accept first subnet from split-include. So when you try to access the other one, it won’t even know that those packets should be encrypted and sent to VPN server.
L2TP+IPSec is completely different. IPSec only protects L2TP packets between client and VPN server. But all traffic between client and remote network(s) is inside L2TP tunnel.
I confirm that I have the same issue here that I realized on a recent deployment using 6.47.2 and 6.47.3 releases with MacOS Clients. Split-include works always on the first subnet on the list but any other subnet after that simply doesn’t work. Using Windows clients works like a charm but I see this problem on MacOS and even iOS devices as well.
having the same issue with this wherein macos clients only recognize the first subnet in split include, any update if this is already fixed in new routerOs version?
@Qalderu: being a MacOS limitation this cannot be fixed on the RouterOS side.
If you really need this fixed you should chase the Apple’s support instead.
