Help with ikev2 ipsec psk mikrotik client - don't connect

RouterOS Beginner Basics
1

Hi!
Sorry for bad english!
Need to configure connection by ipsec ikev2 psk as client.
I tried to configure the connection using Strongswan (Ubuntu) and I did it (screenshot 1 and 2)
but the connection is not established on the microtik and an error “ipsec ike2 init timeout” is written to the logs( status is “no phase2”
left = server fqdn = sa dst address = address in peer
leftsubnet = “Encryption domain” x.x.x.x/29 = dst address
right = mikrotik (client) public static ip = sa src address
rightsubnet = private static ip x.x.x.x/32 get by destination company = src address
I tried to change various settings and it led nowhere
ipsec-no-phase2-6.png
ipsec-no-phase2-4.png
ipsec-no-phase2-3.png
ipsec-no-phase2-2.png
ipsec-no-phase2-5.png
ipsec-no-phase2.png
ipsec-mikrotik-safe.png
ipsec-config-safe.png

2

Found the cause of the error: the port at the peer was not specified, 500 was used, maybe 4500 were used in Mikrotik by default.
Set port 500 in peer settings and all work!
Thank you!

3

I also encountered this. IKEv2 in RouterOS connects to port 4500 no matter what. I though that it could at least take in account the NAT Traversal option and use port 500 when it’s disabled, but no. I was even looking through RFCs, but I don’t remember finding straight answer if preferring port 4500 is the right thing or not.

4

IKEv2 allows the usage of UDP/4500 even for first messages and RouterOS currently defaults to that. Forcing the port to UDP/500 may introduce some compatibility issues since packet format is still left the same.

IKE normally listens and sends on UDP port 500, though IKE messages
may also be received on UDP port 4500 with a slightly different
format (see Section 2.23).

5

Different format are those four zero bytes prepended to IKE packets to port 4500, to distinguish them from UDP-encapsulated ESP packets, right? It looks like RouterOS handles this automatically. If I add IKEv2 peer and I don’t specify port, packets are sent to port 4500 and zero bytes are present. If the only change I do is forcing port to 500, outgoing packets do not have these zero bytes. So that’s correct.

In my case it looked like there was actually some bug or perhaps misconfiguration on the other side (not under my control). RouterOS as initiator sent correct IKE packets to port 4500 (with zeroes), but responses were coming back without zeroes and RouterOS ignored them. So I’d says it was peer’s fault, but good luck explaining something like that to big mobile operator and their Indian support when you’re nobody compared to them.