I did exactly same steps like in this guide. When I tried connect to VPN, Windows says this:
And Mikrotik logs shows this:
subject-alt-name is DDNS of Mikrotik. Win Firewal is turned off, I also tried AssumeUDPEncapsulationContextOnSendRule register. Firewalls rules are at top of all rules.
Setup is Windows 10 and Mikrotik hEX 6.47.10 (long-term)
I’m not able figure out what is the problem. Please could someone help me? We can check also together via TeamViewer. Thank you for any help!
No useful information in the Windows logs, so please activate logging at the Mikrotik: /system logging add topics=ipsec,!packet
Then start copying the interesting part of the log into a separate file: /log print follow-only file=ipsec-start where topics~“ipsec”
Next, connect the Windows client and wait until it gives up.
Then stop the /log print … by pressing Ctrl-C, download the file ipsec-start.txt, and start reading.
If it is over your head, use a text editor to replace the public IP addresses in the log, and then post it here as an attachment or between [code] and [/code] tags inline.
Have you permitted incoming connections to UDP port 4500 (chain input of /ip firewall filter)? Since there is a NAT between the responder (the Mikrotik) and the initiator (the Windows machine), the IKE connection migrates from port 500 to port 4500 once the presence of NAT is detected.
OK, you have, even twice (you’ve added the export before I’ve responded). However, the log does not indicate any packet to arrive to port 4500. Is it possible that there is another firewall between the Windows machine and the Mikrotik?
Can you open a command line window, make it as wide as your screen allows, run /tool sniffer quick port=4500 in that window and try to connect the Windows client again? I’m interested in whether any packet arrives to port 4500 at all, and if yes, what is its size. There may be an issue with handling of fragmented packets somewhere between the devices.
So that’s it regarding hiding your IP addresses… maybe withdraw the screenshot, use some more spray and re-post it?
Anyway, there are just two possibilities - either the Windows VPN client is broken (or maybe misconfigured) and does not send the packets to port 4500, or something on the path between the Windows and the Mikrotik doesn’t let them through. I have already seen a mobile ISP to selectively block some, not all, packets to port 4500 (probably some DPI didn’t like their contents), so nothing is impossible these days. Maybe that ISP and yours are using boxes from the same vendor in their core networks.
So the next step should be to run Wireshark at the Windows machine and capture on the network interface used with capture filter host public.ip.of.mikrotik and udp, then try to establish the connection. If you can see packets towards port 4500 to be sent, it’s the operator dropping them; if you cannot, but you can see the initial packets towards port 500, the Windows client is broken; if you cannot see even the initial ones towards port 500, the capturing doesn’t work properly.
@nichky, unfortunately, the Windows embedded VPN client doesn’t support PSK authentication with IKEv2. The only other authentication you can have for IKEv2 is an username/password one, but that requires User Manager 5 (ROS 7.2+) or an external RADIUS server at the responder side. Other than that, the timestamps show that the sniffer was running for at least 26 seconds. The previously posted log shows that Mikrotik starts sending keepalive packets from port 4500 even before the negotiation is completed, and that it took 13 seconds from the initial exchange till the first KA packet was sent, so I am a bit surprised that the sniff shows the first KA packet a bit earlier, but that does not necessarily mean that the sniffer was started too late.
@sindy, thank you for your time. I tried this setup also at another Windows, with same error.
I had to leave my computer for 2 days. At Friday I will try to wireshark it as you said and post here .pcap. If you will be so kind and could you check it.
For now I just deleted public IPs from screens. Ty.
Please follow the advice I gave to @kobe above (logging, sniffing). The error messages of Windows are not really detailed so the root cause of your issue may be different although it looks the same from the user perspective.
The capture confirms one of the known problem scenarios - you most likely use a certificate with an RSA key, so the size of the IKEv2 packet carrying it exceeds the interface MTU (1500 bytes) and the packet gets fragmented. And something on the path between the Windows initiator and the Mikrotik responder drops the fragmented packets. The Wireshark output is slightly confusing for newbies because when dissecting fragmented packets, it shows the L4 layer header (UDP ports etc.) in the last one, whereas it is actually present in the first one. If at least the first fragment made it to the Mikrotik, sniffing on Mikrotik would have shown it, but it hasn’t.
To me, the most likely reason is an MTU issue on your LTE router (that’s an assumption based on its IP address, maybe there actually is a PPPoE DSL router) - the WAN (LTE or PPPoE) interface may have a smaller MTU than the 1500 of the Ethernet/WiFi interface of the Windows, so the 1500-byte packet doesn’t fit; since IKE uses UDP as transport, the “adjust MSS” trick doesn’t work as it is TCP specific. So reducing the MTU on the Windows to the same value like the router’s WAN should help if this is the reason.
sindy, reducing MTU on Windows interface helps! I was using hotspot via USB cable from iPhone. I reduce MTU on iPhone interface in Windows. For those with same problem:
netsh interface ipv4 show subinterface
netsh interface ipv4 set subinterface “Local Area Connection” mtu=1400 store=persistent
You should replace Local Area Connection with the name that appeared in the “Interface” column from steps 1
Thank you sindy for your profesional help! You made this work. Ty.
