Community discussions

MikroTik App
 
lendi
just joined
Topic Author
Posts: 3
Joined: Tue Jan 21, 2020 6:23 pm

IKEv2 routing issues

Tue Jan 21, 2020 6:45 pm

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.
 
lendi
just joined
Topic Author
Posts: 3
Joined: Tue Jan 21, 2020 6:23 pm

Re: IKEv2 routing issues

Sun Jan 26, 2020 2:57 pm

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.

For instance:
/ip ipsec mode-config
add address-pool=ipsec-address-pool address-prefix-length=30 name=IKE2 split-include=172.0.0.0/8,192.168.0.0/16 static-dns=172.168.168.1 system-dns=no
Will respond from 172.X but wont respond from 192.168.X.

Setting:
/ip ipsec mode-config
add address-pool=ipsec-address-pool address-prefix-length=30 name=IKE2 split-include=192.168.0.0/16,172.0.0.0/8 static-dns=172.168.168.1 system-dns=no
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?
 
Sob
Forum Guru
Forum Guru
Posts: 6517
Joined: Mon Apr 20, 2009 9:11 pm

Re: IKEv2 routing issues

Sun Jan 26, 2020 5:12 pm

Some quotes from manual:
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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
lendi
just joined
Topic Author
Posts: 3
Joined: Tue Jan 21, 2020 6:23 pm

Re: IKEv2 routing issues

Sun Jan 26, 2020 5:47 pm

Some quotes from manual:
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 :-D
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.

Fair enough however.
 
Sob
Forum Guru
Forum Guru
Posts: 6517
Joined: Mon Apr 20, 2009 9:11 pm

Re: IKEv2 routing issues

Sun Jan 26, 2020 6:18 pm

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.
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
ksteink
Frequent Visitor
Frequent Visitor
Posts: 69
Joined: Thu Mar 31, 2016 6:54 pm

Re: IKEv2 routing issues

Sat Sep 05, 2020 8:03 am

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.
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.

Who is online

Users browsing this forum: Google [Bot] and 119 guests