Community discussions

MikroTik App
 
kobe
just joined
Topic Author
Posts: 7
Joined: Tue Aug 09, 2022 10:28 am

IKEv2 VPN issue

Tue Aug 09, 2022 1:41 pm

Hello,

I'm trying to get work IKEv2 VPN by this guide:
https://www.reddit.com/r/mikrotik/comme ... 3rd_party/

I did exactly same steps like in this guide. When I tried connect to VPN, Windows says this:
<REMOVED>

And Mikrotik logs shows this:
<REMOVED>

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!

Best regards.
Last edited by rextended on Tue Aug 09, 2022 3:26 pm, edited 1 time in total.
Reason: removed images on third party sites
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: IKEv2 VPN issue

Tue Aug 09, 2022 3:24 pm

You can add image on "Attachments" section when you "+ Post Reply" without monetize or not on 3rd party sites.

Why didn't you ask for help directly here first, instead of going to reddit and asking someone to "correct" the reddit "guide" here?
 
kobe
just joined
Topic Author
Posts: 7
Joined: Tue Aug 09, 2022 10:28 am

Re: IKEv2 VPN issue

Tue Aug 09, 2022 3:34 pm

You can add image on "Attachments" section when you "+ Post Reply" without monetize or not on 3rd party sites.

Why didn't you ask for help directly here first, instead of going to reddit and asking someone to "correct" the reddit "guide" here?
Sorry, didn't know that. Screenshots at attachment. I asked on Redit and I asked also here. Sorry if I did something wrong, just want to get it work.

+ Resolution could help someone else with similiar problem in Mikrotik comunity.
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2 VPN issue

Tue Aug 09, 2022 4:13 pm

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.
 
kobe
just joined
Topic Author
Posts: 7
Joined: Tue Aug 09, 2022 10:28 am

Re: IKEv2 VPN issue

Tue Aug 09, 2022 10:21 pm

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.
Thank you for your help. I replaced my public IP with 88.33.22.11. Here is debug:
# aug/ 9/2022 21:10:54 by RouterOS 6.47.10
# software id = 7BR3-WUMY
#
21:11:11 ipsec,debug ===== received 624 bytes from 46.135.29.65[18577] to 88.33.22.11[500] 
21:11:11 ipsec -> ike2 request, exchange: SA_INIT:0 46.135.29.65[18577] 359050f7aa2471a2:0000000000000000 
21:11:11 ipsec ike2 respond 
21:11:11 ipsec payload seen: SA (256 bytes) 
21:11:11 ipsec payload seen: KE (136 bytes) 
21:11:11 ipsec payload seen: NONCE (52 bytes) 
21:11:11 ipsec payload seen: NOTIFY (8 bytes) 
21:11:11 ipsec payload seen: NOTIFY (28 bytes) 
21:11:11 ipsec payload seen: NOTIFY (28 bytes) 
21:11:11 ipsec payload seen: VID (24 bytes) 
21:11:11 ipsec,debug 1e2b516905991c7d7c96fcbfb587e46100000009 
21:11:11 ipsec payload seen: VID (20 bytes) 
21:11:11 ipsec,debug fb1de3cdf341b7ea16b7e5be0855f120 
21:11:11 ipsec payload seen: VID (20 bytes) 
21:11:11 ipsec,debug 26244d38eddb61b3172a36e3d0cfb819 
21:11:11 ipsec payload seen: VID (24 bytes) 
21:11:11 ipsec,debug 01528bbbc00696121849ab9a1c5b2a5100000002 
21:11:11 ipsec processing payload: NONCE 
21:11:11 ipsec processing payload: SA 
21:11:11 ipsec,debug unknown auth: #13 
21:11:11 ipsec,debug unknown prf: #6 
21:11:11 ipsec,debug unknown auth: #13 
21:11:11 ipsec,debug unknown prf: #6 
21:11:11 ipsec IKE Protocol: IKE 
21:11:11 ipsec  proposal #1 
21:11:11 ipsec   enc: 3des-cbc 
21:11:11 ipsec   prf: hmac-sha1 
21:11:11 ipsec   auth: sha1 
21:11:11 ipsec   dh: modp1024 
21:11:11 ipsec  proposal #2 
21:11:11 ipsec   enc: aes256-cbc 
21:11:11 ipsec   prf: hmac-sha1 
21:11:11 ipsec   auth: sha1 
21:11:11 ipsec   dh: modp1024 
21:11:11 ipsec  proposal #3 
21:11:11 ipsec   enc: 3des-cbc 
21:11:11 ipsec   prf: hmac-sha256 
21:11:11 ipsec   auth: sha256 
21:11:11 ipsec   dh: modp1024 
21:11:11 ipsec  proposal #4 
21:11:11 ipsec   enc: aes256-cbc 
21:11:11 ipsec   prf: hmac-sha256 
21:11:11 ipsec   auth: sha256 
21:11:11 ipsec   dh: modp1024 
21:11:11 ipsec  proposal #5 
21:11:11 ipsec   enc: 3des-cbc 
21:11:11 ipsec   prf: unknown 
21:11:11 ipsec   auth: unknown 
21:11:11 ipsec   dh: modp1024 
21:11:11 ipsec  proposal #6 
21:11:11 ipsec   enc: aes256-cbc 
21:11:11 ipsec   prf: unknown 
21:11:11 ipsec   auth: unknown 
21:11:11 ipsec   dh: modp1024 
21:11:11 ipsec matched proposal: 
21:11:11 ipsec  proposal #4 
21:11:11 ipsec   enc: aes256-cbc 
21:11:11 ipsec   prf: hmac-sha256 
21:11:11 ipsec   auth: sha256 
21:11:11 ipsec   dh: modp1024 
21:11:11 ipsec processing payload: KE 
21:11:11 ipsec,debug => shared secret (size 0x80) 
21:11:11 ipsec,debug 76ccf1a0 973f76c0 d3db660d 4ee139a1 e617f84a 0761828d ac97a104 89b753aa 
21:11:11 ipsec,debug 25d17986 170a9b20 5e04610b 2ae4fd8e 7eb18d08 d35c8344 8b1115d8 0b9b4a54 
21:11:11 ipsec,debug 50b46fe9 1e442a7f 6ddcb09d 9304dff3 e9a2e405 17f981c8 5ba84d4b 8169889f 
21:11:11 ipsec,debug e0d2c40c 46f3e2de f07e4195 22190bc4 3f1672f2 841f733f 61fb3d84 02d0dc60 
21:11:11 ipsec adding payload: SA 
21:11:11 ipsec,debug => (size 0x30) 
21:11:11 ipsec,debug 00000030 0000002c 04010004 0300000c 0100000c 800e0100 03000008 02000005 
21:11:11 ipsec,debug 03000008 0300000c 00000008 04000002 
21:11:11 ipsec adding payload: KE 
21:11:11 ipsec,debug => (size 0x88) 
21:11:11 ipsec,debug 00000088 00020000 76566e59 e78ad64e 5d13f82d a55fa5f0 538c16f5 6df0258e 
21:11:11 ipsec,debug 09bf8dfb 5f5e1d61 8a56d864 6d95358b c1f33f78 d1a71352 48be9736 5876fdd3 
21:11:11 ipsec,debug c3d7d26d 6e02c2f0 01e8451c 9bdde061 c528619d b4a1a0db 8d7397f5 5a6e35e1 
21:11:11 ipsec,debug 7042447f cdd4390b 9189a0b9 0e688c4f f285bb01 0168818f 984cc112 cf08c71b 
21:11:11 ipsec,debug 73eca040 0e14a5b7 
21:11:11 ipsec adding payload: NONCE 
21:11:11 ipsec,debug => (size 0x1c) 
21:11:11 ipsec,debug 0000001c 532877bc 4c879f22 3844a3a4 d9f384be 5c376843 ef985664 
21:11:11 ipsec adding notify: NAT_DETECTION_SOURCE_IP 
21:11:11 ipsec,debug => (size 0x1c) 
21:11:11 ipsec,debug 0000001c 00004004 2b2e9d45 bee7caf4 454efc8c ec3825bd bbc95cd9 
21:11:11 ipsec adding notify: NAT_DETECTION_DESTINATION_IP 
21:11:11 ipsec,debug => (size 0x1c) 
21:11:11 ipsec,debug 0000001c 00004005 8be05b3b f1635b1c 34318c97 65a48a9c 08f98225 
21:11:11 ipsec adding payload: CERTREQ 
21:11:11 ipsec,debug => (size 0x5) 
21:11:11 ipsec,debug 00000005 04 
21:11:11 ipsec <- ike2 reply, exchange: SA_INIT:0 46.135.29.65[18577] 359050f7aa2471a2:a88998c898d2f312 
21:11:11 ipsec,debug ===== sending 301 bytes from 88.33.22.11[500] to 46.135.29.65[18577] 
21:11:11 ipsec,debug 1 times of 301 bytes message will be sent to 46.135.29.65[18577] 
21:11:11 ipsec,debug => skeyseed (size 0x20) 
21:11:11 ipsec,debug 20332b7e 7832eda4 98ed0148 9ca3bca0 e8cab1e6 2bcdd503 a705691f 6f62090a 
21:11:11 ipsec,debug => keymat (size 0x20) 
21:11:11 ipsec,debug d815c6be 08b06e99 b487a9d0 c80c5e43 142fa5fb ce82dabe 1474178f 109ee9ac 
21:11:11 ipsec,debug => SK_ai (size 0x20) 
21:11:11 ipsec,debug 75f1d15b c3ef81ef 3aa3b60a 08aba9de bd415731 71947f2c 97ada6df 80747921 
21:11:11 ipsec,debug => SK_ar (size 0x20) 
21:11:11 ipsec,debug 91e5427c 227d6abd 0aba0c3d ebe8a80f cb5d728d fc6ea9b5 f0bb65e6 8ae2d28f 
21:11:11 ipsec,debug => SK_ei (size 0x20) 
21:11:11 ipsec,debug 773ad1d0 d27c0548 c1275afe fd03ac6b 2edcb232 ede57763 5e028711 77c8fcd0 
21:11:11 ipsec,debug => SK_er (size 0x20) 
21:11:11 ipsec,debug 9dfac359 de8742e5 b4b87b83 b93736b4 bef47b10 2dbf703b d93f4026 d32284d0 
21:11:11 ipsec,debug => SK_pi (size 0x20) 
21:11:11 ipsec,debug 0507ca95 cfac2436 ce17ea0d d2e5d6b7 f62b4f85 0f25480b c99f8b30 789099d2 
21:11:11 ipsec,debug => SK_pr (size 0x20) 
21:11:11 ipsec,debug 3ac429c2 6bbb8332 084ea6c0 a90d30e1 d64760de 41039fdb 4bd3c2cc fbf48bf3 
21:11:11 ipsec,info new ike2 SA (R): 88.33.22.11[500]-46.135.29.65[18577] spi:a88998c898d2f312:359050f7aa2471a2 
21:11:11 ipsec processing payloads: VID 
21:11:11 ipsec peer is MS Windows (ISAKMPOAKLEY 9) 
21:11:11 ipsec processing payloads: NOTIFY 
21:11:11 ipsec   notify: IKEV2_FRAGMENTATION_SUPPORTED 
21:11:11 ipsec   notify: NAT_DETECTION_SOURCE_IP 
21:11:11 ipsec   notify: NAT_DETECTION_DESTINATION_IP 
21:11:11 ipsec (NAT-T) REMOTE  
21:11:11 ipsec KA list add: 88.33.22.11[4500]->46.135.29.65[18577] 
21:11:24 ipsec,debug KA: 88.33.22.11[4500]->46.135.29.65[18577] 
21:11:24 ipsec,debug 1 times of 1 bytes message will be sent to 46.135.29.65[18577] 
21:11:41 ipsec child negitiation timeout in state 0 
21:11:41 ipsec,info killing ike2 SA: 88.33.22.11[4500]-46.135.29.65[18577] spi:a88998c898d2f312:359050f7aa2471a2 
21:11:41 ipsec KA remove: 88.33.22.11[4500]->46.135.29.65[18577] 
21:11:41 ipsec,debug KA tree dump: 88.33.22.11[4500]->46.135.29.65[18577] (in_use=1) 
21:11:41 ipsec,debug KA removing this one... 
And here is /export terse:
# aug/09/2022 21:31:35 by RouterOS 6.47.10
# software id = 7BR3-WUMY
#
# model = RB750Gr3
# serial number = <CENSORED>
/interface bridge add admin-mac=DC:2C:6E:7D:3F:65 auto-mac=no comment=defconf name=bridge
/interface list add comment=defconf name=WAN
/interface list add comment=defconf name=LAN
/interface wireless security-profiles set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile set [ find default=yes ] html-directory=flash/hotspot
/ip ipsec policy group add name=group-vpn
/ip ipsec profile add dh-group=modp2048,modp1536,modp1024 enc-algorithm=aes-256,aes-192,aes-128 hash-algorithm=sha256 name=profile-vpn
/ip ipsec peer add exchange-mode=ike2 local-address=88.33.22.11 name=peer-WAN passive=yes profile=profile-vpn
/ip ipsec proposal add auth-algorithms=sha512,sha256,sha1 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm lifetime=8h name
=proposal-vpn pfs-group=none
/ip pool add name=dhcp ranges=192.168.88.10-192.168.88.254
/ip pool add name=pool-vpn ranges=10.10.10.10-10.10.10.50
/ip pool add name=vpn ranges=192.168.89.2-192.168.89.255
/ip dhcp-server add address-pool=dhcp disabled=no interface=bridge name=defconf
/ip ipsec mode-config add address-pool=pool-vpn address-prefix-length=32 name=modeconf-vpn split-include=192.168.88.0/24 system-dns=no
/ppp profile set *FFFFFFFE local-address=192.168.89.1 remote-address=vpn
/interface bridge port add bridge=bridge comment=defconf interface=ether2
/interface bridge port add bridge=bridge comment=defconf interface=ether3
/interface bridge port add bridge=bridge comment=defconf interface=ether4
/interface bridge port add bridge=bridge comment=defconf interface=ether5
/ip neighbor discovery-settings set discover-interface-list=LAN
/interface l2tp-server server set use-ipsec=yes
/interface list member add comment=defconf interface=bridge list=LAN
/interface list member add comment=defconf interface=ether1 list=WAN
/interface sstp-server server set default-profile=default-encryption
/ip address add address=192.168.88.1/24 comment=defconf interface=ether2 network=192.168.88.0
/ip cloud set ddns-enabled=yes
/ip dhcp-client add comment=defconf disabled=no interface=ether1
/ip dhcp-server network add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns set allow-remote-requests=yes
/ip dns static add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter add action=accept chain=input comment="IPSec Policies" dst-port=500,4500 log=yes protocol=udp
/ip firewall filter add action=accept chain=input log=yes protocol=ipsec-esp
/ip firewall filter add action=accept chain=forward ipsec-policy=in,ipsec log=yes
/ip firewall filter add action=accept chain=forward ipsec-policy=out,ipsec log=yes
/ip firewall filter add action=accept chain=input comment="allow IPsec NAT" dst-port=4500 protocol=udp
/ip firewall filter add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
/ip firewall filter add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
/ip firewall filter add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
/ip firewall filter add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
/ip firewall filter add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
/ip firewall filter add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
/ip firewall filter add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
/ip firewall filter add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
/ip firewall filter add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
/ip firewall filter add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
/ip firewall filter add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
/ip ipsec identity add auth-method=digital-signature certificate=*A generate-policy=port-strict match-by=certificate mode-config=modeconf-vpn peer=peer-WAN policy-template-group=group-v
pn remote-id=user-fqdn:kobe@domain.com
/ip ipsec policy add dst-address=10.10.10.0/24 group=group-vpn proposal=proposal-vpn src-address=0.0.0.0/0 template=yes
/ppp secret add name=vpn
/system clock set time-zone-name=Europe/Prague
/system logging add topics=ipsec,!packet
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN
Last edited by rextended on Wed Aug 10, 2022 12:16 am, edited 1 time in total.
Reason: <CENSORED>
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2 VPN issue

Tue Aug 09, 2022 11:26 pm

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.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2 VPN issue

Tue Aug 09, 2022 11:35 pm

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.
 
kobe
just joined
Topic Author
Posts: 7
Joined: Tue Aug 09, 2022 10:28 am

Re: IKEv2 VPN issue

Wed Aug 10, 2022 8:40 am

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.
There is no other firewall between. Maybe ISP? Sniffer in attachment. Thank you for helping. (I also screenshot set of certificates)
You do not have the required permissions to view the files attached to this post.
Last edited by kobe on Thu Aug 11, 2022 12:08 am, edited 1 time in total.
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1275
Joined: Tue Jun 23, 2015 2:35 pm

Re: IKEv2 VPN issue

Wed Aug 10, 2022 9:24 am

how long was the sniffing for?

form the result that you got , we can clear see that u are not getting response @sindy will give u more info.

i will play first with pre shared key, once u see that everything is working that you can switch over to certificate.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2 VPN issue

Wed Aug 10, 2022 10:15 am

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.
 
kobe
just joined
Topic Author
Posts: 7
Joined: Tue Aug 09, 2022 10:28 am

Re: IKEv2 VPN issue

Thu Aug 11, 2022 12:12 am

@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.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2 VPN issue

Thu Aug 11, 2022 9:13 am

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.
 
kobe
just joined
Topic Author
Posts: 7
Joined: Tue Aug 09, 2022 10:28 am

Re: IKEv2 VPN issue

Fri Aug 12, 2022 3:21 pm

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, here is report from Wireshark - I capture on interface which I used to connect to Mikrotik IKEv2 VPN. What do you think? Thank you.
No.     Time           Source                Destination           Protocol Length Info
      1 0.000000       172.20.10.2           88.33.22.11         ISAKMP   666    IKE_SA_INIT MID=00 Initiator Request

Frame 1: 666 bytes on wire (5328 bits), 666 bytes captured (5328 bits)
Ethernet II, Src: 2a:c7:09:a4:f6:ff (2a:c7:09:a4:f6:ff), Dst: 2a:c7:09:4a:90:64 (2a:c7:09:4a:90:64)
Internet Protocol Version 4, Src: 172.20.10.2, Dst: 88.33.22.11
User Datagram Protocol, Src Port: 500, Dst Port: 500
Internet Security Association and Key Management Protocol

No.     Time           Source                Destination           Protocol Length Info
      2 0.180658       88.33.22.11         172.20.10.2           ISAKMP   343    IKE_SA_INIT MID=00 Responder Response

Frame 2: 343 bytes on wire (2744 bits), 343 bytes captured (2744 bits)
Ethernet II, Src: 2a:c7:09:4a:90:64 (2a:c7:09:4a:90:64), Dst: 2a:c7:09:a4:f6:ff (2a:c7:09:a4:f6:ff)
Internet Protocol Version 4, Src: 88.33.22.11, Dst: 172.20.10.2
User Datagram Protocol, Src Port: 500, Dst Port: 500
Internet Security Association and Key Management Protocol

No.     Time           Source                Destination           Protocol Length Info
      3 0.189659       172.20.10.2           88.33.22.11         IPv4     1514   Fragmented IP protocol (proto=UDP 17, off=0, ID=fc5e) [Reassembled in #4]

Frame 3: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
Ethernet II, Src: 2a:c7:09:a4:f6:ff (2a:c7:09:a4:f6:ff), Dst: 2a:c7:09:4a:90:64 (2a:c7:09:4a:90:64)
Internet Protocol Version 4, Src: 172.20.10.2, Dst: 88.33.22.11
Data (1480 bytes)



No.     Time           Source                Destination           Protocol Length Info
      4 0.189659       172.20.10.2           88.33.22.11         ISAKMP   1414   IKE_AUTH MID=01 Initiator Request

Frame 4: 1414 bytes on wire (11312 bits), 1414 bytes captured (11312 bits)
Ethernet II, Src: 2a:c7:09:a4:f6:ff (2a:c7:09:a4:f6:ff), Dst: 2a:c7:09:4a:90:64 (2a:c7:09:4a:90:64)
Internet Protocol Version 4, Src: 172.20.10.2, Dst: 88.33.22.11
User Datagram Protocol, Src Port: 4500, Dst Port: 4500
UDP Encapsulation of IPsec Packets
Internet Security Association and Key Management Protocol

No.     Time           Source                Destination           Protocol Length Info
      5 1.185378       172.20.10.2           88.33.22.11         IPv4     1514   Fragmented IP protocol (proto=UDP 17, off=0, ID=fc5f) [Reassembled in #6]

Frame 5: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
Ethernet II, Src: 2a:c7:09:a4:f6:ff (2a:c7:09:a4:f6:ff), Dst: 2a:c7:09:4a:90:64 (2a:c7:09:4a:90:64)
Internet Protocol Version 4, Src: 172.20.10.2, Dst: 88.33.22.11
Data (1480 bytes)



No.     Time           Source                Destination           Protocol Length Info
      6 1.185378       172.20.10.2           88.33.22.11         ISAKMP   1414   IKE_AUTH MID=01 Initiator Request

Frame 6: 1414 bytes on wire (11312 bits), 1414 bytes captured (11312 bits)
Ethernet II, Src: 2a:c7:09:a4:f6:ff (2a:c7:09:a4:f6:ff), Dst: 2a:c7:09:4a:90:64 (2a:c7:09:4a:90:64)
Internet Protocol Version 4, Src: 172.20.10.2, Dst: 88.33.22.11
User Datagram Protocol, Src Port: 4500, Dst Port: 4500
UDP Encapsulation of IPsec Packets
Internet Security Association and Key Management Protocol

No.     Time           Source                Destination           Protocol Length Info
      7 2.187607       172.20.10.2           88.33.22.11         IPv4     1514   Fragmented IP protocol (proto=UDP 17, off=0, ID=fc60) [Reassembled in #8]

Frame 7: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
Ethernet II, Src: 2a:c7:09:a4:f6:ff (2a:c7:09:a4:f6:ff), Dst: 2a:c7:09:4a:90:64 (2a:c7:09:4a:90:64)
Internet Protocol Version 4, Src: 172.20.10.2, Dst: 88.33.22.11
Data (1480 bytes)



No.     Time           Source                Destination           Protocol Length Info
      8 2.187607       172.20.10.2           88.33.22.11         ISAKMP   1414   IKE_AUTH MID=01 Initiator Request

Frame 8: 1414 bytes on wire (11312 bits), 1414 bytes captured (11312 bits)
Ethernet II, Src: 2a:c7:09:a4:f6:ff (2a:c7:09:a4:f6:ff), Dst: 2a:c7:09:4a:90:64 (2a:c7:09:4a:90:64)
Internet Protocol Version 4, Src: 172.20.10.2, Dst: 88.33.22.11
User Datagram Protocol, Src Port: 4500, Dst Port: 4500
UDP Encapsulation of IPsec Packets
Internet Security Association and Key Management Protocol
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2 VPN issue  [SOLVED]

Sat Aug 13, 2022 11:46 am

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.
 
kobe
just joined
Topic Author
Posts: 7
Joined: Tue Aug 09, 2022 10:28 am

Re: IKEv2 VPN issue

Tue Aug 16, 2022 10:07 am

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.

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot], h1ghrise, HugoCar, menyarito, xristostsilis and 68 guests