I have a IKEv2 server running on Windows Server 2019 and I have configured Mikrotik as IKEv2 client.
Once the connection is established, I can not access Mikrotik via IP but only via MAC address. From Mikrotik, I can not ping any public IPs however the VPNs remain established and I can also reach the other end of the tunnel.
Could you elaborate from where you can’t access the MikroTik via IP - from server side or from the LAN? How is the address.of the Windows server shared - via IPIP, GRE, etc. or how? A full exported config would be best
It appears I have the same problem as you, or at least symptom looks similar.
On the LAN side of the Mikrotik, everything works perfectly when VPN is down:
Mikrotik management is reachable from the LAN.
Gateway IP on Mikrotik can ping
Internet access works (Mikrotik is configured as WiFi client and traffic is routed and NATed from the LAN, this is the particularity in my case, VPN is established over WiFi in AP station mode.)
On the LAN side, Ethernet ports are bridged, and I also have a virtual WLAN interface bridged to the LAN. Without VPN, everything work fine.
As soon as IKEv2 VPN goes up, all of the above fails. It’s as if LAN became isolated from the Mikrotik.
I noticed that, from the other end of the VPN, through the IKEv2 VPN, I’m able to access the management interface (GUI, SSH, etc).
Maybe if the OP had exported the full config without eliding important parts such as the firewall and probably more, I could’ve helped him. Alas, I couldn’t. Maybe I could help you @Yanik if you give me some more details like what is on the other side of the VPN, whether GRE, IPIP, etc. is used for the local subnets to be routed through the tunnel, and a full, exported config (sensitive information like public IPs, keys, passwords and others should ofc be redacted)
IPsec policies override any result of regular routing, except blackhole. I.e. whenever the regular routing finds an out-interface for a packet and all the stages of packet processing in the firewall, including srcnat, do their job, the address, protocol, and eventually port header fields of the resulting packet are matched against the traffic selectors of the IPsec policies and if a match is found, the packet is processed according to the matching policy rather than getting sent out via the out-interface chosen by the regular routing. Routing marks etc. do not affect this.
Looking at the configuration of @NGiannis, the /ip ipsec mode-config row for the Windows peer does exist and the corresponding /ip ipsec identity refers to it, but the screenshot shows that the Windows server did not provide a “mode-config” (the name is different in IKEv2 vernacular but the purpose is the same) response and requested creation of a policy with a 0.0.0.0/0<->0.0.0.0/0 traffic selector. Such a policy intercepts anything, including a packet from the Mikrotik itself to a device in any network connected to it directly, such as 192.168.50.0/24 in this case.
So to maintain accessibility of the Mikrotik from LAN once the IPsec connection to the Windows server gets established, you have to add a policy with traffic selector src-address=192.168.50.0/24 dst-address=192.168.50.0/24 and action=none before (above) the policy template in group VPN (the one the identity for the Windows peer refers to). Matching of packets against IPsec policies is done exactly the same way like matching them against firewall rules, i.e. starting from the first (topmost) one down until the first match is found or until the list ends, so packets from Mikrotik itself to a host in its LAN subnet will be prevented from reaching the policy created dynamically from the template in the VPN group.
@Yanik, if adjusting the above to your configuration is not sufficient, follow the suggestion of @TheCat12 to post an anonymised export of your configuration.
