IPSEC VPN stopped working under Windows 11 + Forticlient

[Solrac_Leinad]

I had a working IPSEC VPN between our main site and my home computer, a few days ago my VPN stopped working and I can't figure out why. So let me lay the important VPN details down:

- Fortigate model: 100-F
- Fortigate unit NOT behind NAT.
- Home computer IS behind NAT.
- OS: Windows 11 Pro version 22H2
- VPN type: IPSEC (Dialup)
- Authentication: X.509 client cert
- This VPN works on a strongSwan client under Debian 12.

Here's the FTG log:

ike 0:****************/0000000000000000:370001: responder: aggressive mode get 1st message...
ike 0:****************/0000000000000000:370001: VID CISCO-UNITY 12F5F28C4...
ike 0:****************/0000000000000000:370001: VID RFC 3947 4A131C81070---
ike 0:****************/0000000000000000:370001: VID draft-ietf-ipsec-nat-t-ike-02 CD6046433...
ike 0:****************/0000000000000000:370001: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913E...
ike 0:****************/0000000000000000:370001: VID DPD AFCAD71368A1...
ike 0:****************/0000000000000000:370001: VID forticlient connect license ************
ike 0:****************/0000000000000000:370001: VID Fortinet Endpoint Control ************
ike 0::370001: received peer identifier DER_ASN1_DN '[cert information]'
ike 0: IKEv1 Aggressive, comes *******:39762->***** 7
ike 0:****************/0000000000000000:370001: negotiation result
ike 0:****************/0000000000000000:370001: proposal id = 1:
ike 0:****************/0000000000000000:370001: protocol id = ISAKMP:
ike 0:****************/0000000000000000:370001: trans_id = KEY_IKE.
ike 0:****************/0000000000000000:370001: encapsulation = IKE/none
ike 0:****************/0000000000000000:370001: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256
ike 0:****************/0000000000000000:370001: type=OAKLEY_HASH_ALG, val=SHA2_256.
ike 0:****************/0000000000000000:370001: type=AUTH_METHOD, val=RSA_SIG.
ike 0:****************/0000000000000000:370001: type=OAKLEY_GROUP, val=MODP1536.
ike 0:****************/0000000000000000:370001: ISAKMP SA lifetime=86400
ike 0:****************/0000000000000000:370001: SA proposal chosen, matched *********
ike 0:VPN_name: created connection: 0x966a8c0 7 ***.***.**.**->***.***.**.**:39762.
ike 0:VPN_name:370001: DPD negotiated
ike 0:VPN_name:370001: peer supports UNITY
ike 0:VPN_name:370001: enable FortiClient license check
ike 0:VPN_name:370001: FEC vendor ID received FEC but IP not set
ike 0:VPN_name:370001: selected NAT-T version: RFC 3947
ike 0:VPN_name:370001: cookie ****************/****************
ike 0:VPN_name:370001: ISAKMP SA ****************/**************** key 32:****************
ike 0:VPN_name:370001: sending 1 CERTREQ payload
ike 0:VPN_name:370001: local cert, subject='***********', issuer='***************'
ike 0:VPN_name:370001: local CA cert, subject='***********', issuer='****************'
ike 0:VPN_name:370001: out ********************************0110040000000000000010670400003C00000001000000010000003001010....
ike 0:VPN_name:370001: sent IKE msg (agg_r1send): ***.***.**.**:500->***.***.**.**:39762, len=4199, vrf=0, id=****************/****************
ike 0:VPN_name:370001: out ********************************0110040000000000000010670400003C00000001000000010000003001010...
ike 0:VPN_name:370001: sent IKE msg (P1_RETRANSMIT): ***.***.**.**:500->***.***.**.**:39762, len=4199, vrf=0, id=****************/****************

As you can see, the FTG receives the certificate info and the proposal, it matches and then it sends a response but it retransmits this response until it times out.

The same thing is going on, on the forticlient side. This is the log:

5/21/2024 2:19:57 PM debug ipsecvpn AuthDaemon. Message in pipe
5/21/2024 2:19:57 PM debug ipsecvpn AuthDaemon. CSP_AND_CERTNAME
5/21/2024 2:19:57 PM debug ipsecvpn {"source":1,"thumbprint":"21E3AF9E74ECFBF9CD5FB627BB48AF6DC6B0014E"}
5/21/2024 2:19:57 PM debug ipsecvpn AuthDaemon. Certificate returned
5/21/2024 2:19:57 PM info ipsecvpn date=2024-05-21 time=14:19:57 logver=1 id=96566 type=securityevent subtype=ipsecvpn eventtype=status level=info uid=CAF04C108D28465385C5983898CD4528 devid=FCT8001********* hostname=the_hostname pcdomain=N/A deviceip=it's_my_local_IP devicemac=my_mac site=N/A fctver=7.2.4.0972 fgtserial=FCT8001********* emsserial=N/A os="Microsoft Windows 11 Professional Edition, 64-bit (build 22621)" user=my_username msg="loc_ip=it's_my_local_IP loc_port=500 rem_ip=my_remote_ip rem_port=500 out_if=0 vpn_tunnel=VPN_name action=negotiate init=local mode=aggressive stage=1 dir=outbound status=success Initiator: sent my_remote_ip aggressive mode message #1 (OK)" vpntunnel="VPN_name"
5/21/2024 2:20:10 PM warning ipsecvpn date=2024-05-21 time=14:20:09 logver=1 id=96561 type=securityevent subtype=ipsecvpn eventtype=error level=warning uid=CAF04C108D28465385C5983898CD4528 devid=FCT8001********* hostname=the_hostname pcdomain=N/A deviceip=it's_my_local_IP devicemac=my_mac site=N/A fctver=7.2.4.0972 fgtserial=FCT8001********* emsserial=N/A os="Microsoft Windows 11 Professional Edition, 64-bit (build 22621)" user=my_username msg="No response from the peer, phase1 retransmit reaches maximum count" vpntunnel="VPN_name" locip=it's_my_local_IP locport=500 remip=my_remote_ip remport=500
5/21/2024 2:20:10 PM debug ipsecvpn AuthDaemon. Message in pipe
5/21/2024 2:20:10 PM debug ipsecvpn AuthDaemon. Got Quit message.
5/21/2024 2:20:10 PM debug ipsecvpn authentication finished

Because of this behavior I decided to pop a Wireshark on my PC and a weird thing happens:

I have network packets leaving my computer but 0 packets received from the FTG!

What I tried so far:

• I plugged a 10/100 USB dongle and tested
• I plugged 2 diff wireless adapters and tested
• I plugged those adapters on a Linux laptop and the VPN works there.
• I reset the network stack on the computer and tested
• I tested multiple network drivers
• I removed every network filter/firewall
• I also made a DMZ from the modem to this computer
• I read +30 articles/posts on similar problems
• I switched the VPN from Aggresive mode to Main mode
• I upgraded my forticlient
• I created NEW client and server certificates because FORTICLIENT wont show my old certs (it only accepts certificates with v3 extensions it seems)

I am going nuts here, any help would be greatly appreciated.
Thanks in advance :)

[dfeifer]

Sounds like the issue I have had with my user base for the past couple of months. Rectifying it on my end is to make sure the forticlient is running 7.2.4.0972 and install any system firmware/ drivers that are available. For me it's generally bios/intel management driver and wifi/network drivers. 98% of our vpn enrolled devices are lenovo laptops so its running the lenovo vantage app install all updates and verify forticlient 7.2.4 is installed. 

7.0.5 and 7.0.8 were giving me unable to connect messages or just timing out with the same sending but not receiving from the fortigate. 

[Solrac_Leinad]

Thanks I'm currently running 7.2.4.0972, made no changes to my BIOS or upgraded any firmware. I can't recall windows updating itself either. It was previously working with Forticlient 6.2.6.0951 tho.

I also spent a fair amount of time upgrading my MOBO drivers as well as network drivers on both WiFi and Eth, this is an AMD chipset so I upgraded those drivers too. No luck so far.

[Solrac_Leinad]

Today I also updated my BIOS.
Same result.

[Mrinmoy]

What is the forti client version?

Also can you please check the IPsec NPU "npu-offload" option.

for the wireshark traffic you can capture from fortigate also to match the traffic.

[Solrac_Leinad]

The fortigate unit is answering perfectly fine.
Like I said, the very same VPN is working, same location, same internet just diff OS and client.
I also disabled "npu-offload" for the test... same result

I've used Forticlient versions:

• 7.2.4.0972
• 7.0.2.0090
• 6.2.6.0951

All have the same result.
It was originally working with 6.2.6.0951

[Solrac_Leinad]

I forgot to add the Wireshark view of the capture:

And I also did a "Debug Flow", this is the output:

Trace ID	Time	Message
Packet Trace #1125	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTCLIENT_IP_ADDR:56780->FTG_IP_ADDR:500) tun_id=0.0.0.0 from wan1.
Packet Trace #1125	24/05/2024 11:59	allocate a new session-020c3785, tun_id=0.0.0.0
Packet Trace #1125	24/05/2024 11:59	in-[wan1], out-[]
Packet Trace #1125	24/05/2024 11:59	len=2
Packet Trace #1125	24/05/2024 11:59	checking gnum-100000 policy-9
Packet Trace #1125	24/05/2024 11:59	checking gnum-100000 policy-12
Packet Trace #1125	24/05/2024 11:59	result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000
Packet Trace #1125	24/05/2024 11:59	find a route: flag=80000000 gw-FTG_IP_ADDR via root
Packet Trace #1125	24/05/2024 11:59	in-[wan1], out-[], skb_flags-02000000, vid-0
Packet Trace #1125	24/05/2024 11:59	gnum-100017, check-ffffffbffc02bd54
Packet Trace #1125	24/05/2024 11:59	after check: ret-no-match, act-accept, flag-00000000, flag2-00000000
Packet Trace #1125	24/05/2024 11:59	in-[wan1], out-[], skb_flags-02000000, vid-0
Packet Trace #1125	24/05/2024 11:59	gnum-100011, check-ffffffbffc02cd20
Packet Trace #1125	24/05/2024 11:59	after check: ret-no-match, act-drop, flag-00000000, flag2-00000000
Packet Trace #1125	24/05/2024 11:59	gnum-100001, check-ffffffbffc02bd54
Packet Trace #1125	24/05/2024 11:59	after check: ret-no-match, act-accept, flag-00000000, flag2-00000000
Packet Trace #1125	24/05/2024 11:59	gnum-10000e, check-ffffffbffc02bd54
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-no-match, act-accept
Packet Trace #1125	24/05/2024 11:59	checked gnum-10000e policy-4294967295, ret-matched, act-accept
Packet Trace #1125	24/05/2024 11:59	policy-4294967295 is matched, act-accept
Packet Trace #1125	24/05/2024 11:59	gnum-10000e check result: ret-matched, act-accept, flag-00000001, flag2-00000000
Packet Trace #1125	24/05/2024 11:59	after check: ret-matched, act-accept, flag-00000001, flag2-00000000
Packet Trace #1126	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTG_IP_ADDR:500->FTCLIENT_IP_ADDR:56780) tun_id=0.0.0.0 from local.
Packet Trace #1126	24/05/2024 11:59	Find an existing session, id-020c3785, reply direction
Packet Trace #1127	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTCLIENT_IP_ADDR:56780->FTG_IP_ADDR:500) tun_id=0.0.0.0 from wan1.
Packet Trace #1127	24/05/2024 11:59	Find an existing session, id-020c3785, original direction
Packet Trace #1128	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTG_IP_ADDR:500->FTCLIENT_IP_ADDR:56780) tun_id=0.0.0.0 from local.
Packet Trace #1128	24/05/2024 11:59	Find an existing session, id-020c3785, reply direction
Packet Trace #1129	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTG_IP_ADDR:500->FTCLIENT_IP_ADDR:56780) tun_id=0.0.0.0 from local.
Packet Trace #1129	24/05/2024 11:59	Find an existing session, id-020c3785, reply direction
Packet Trace #1130	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTCLIENT_IP_ADDR:56780->FTG_IP_ADDR:500) tun_id=0.0.0.0 from wan1.
Packet Trace #1130	24/05/2024 11:59	Find an existing session, id-020c3785, original direction
Packet Trace #1131	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTG_IP_ADDR:500->FTCLIENT_IP_ADDR:56780) tun_id=0.0.0.0 from local.
Packet Trace #1131	24/05/2024 11:59	Find an existing session, id-020c3785, reply direction
Packet Trace #1132	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTCLIENT_IP_ADDR:56780->FTG_IP_ADDR:500) tun_id=0.0.0.0 from wan1.
Packet Trace #1132	24/05/2024 11:59	Find an existing session, id-020c3785, original direction
Packet Trace #1133	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTG_IP_ADDR:500->FTCLIENT_IP_ADDR:56780) tun_id=0.0.0.0 from local.
Packet Trace #1133	24/05/2024 11:59	Find an existing session, id-020c3785, reply direction
Packet Trace #1134	24/05/2024 11:59	vd-root:0 received a packet(proto=17, FTG_IP_ADDR:500->FTCLIENT_IP_ADDR:56780) tun_id=0.0.0.0 from local.
Packet Trace #1134	24/05/2024 11:59	Find an existing session, id-020c3785, reply direction

[Brunn3r]

Did you recently install windows updates? could that cause the issue?
Try do uninstall the latest Windows Updates and try again.

[Solrac_Leinad]

Saddly no updates were  installed

[Solrac_Leinad · Accepted solution]

I managed to connect my VPN again today and I think this error is 100% forticlient's fault and I'll explain why, please bear with me.

At some point along my tests I upgraded my forticlient from v6.2.6.0951 to v7.2.4.0972 and this wiped every single certificate on the forticlient side which led me to create a NEW connection only to show me no certificates on the "new connection window" so "[Prompt on connect]" was the only option left. I was able to select certificates there but my old certificate was nowhere to be found in that list, my forticlient was showing certificates with V3 extensions back then, this led me to create new certificates with V3 extensions. Certificates were installed and my Forticlient was finally showing them, I used these certificates for all the subsequent tests nothing, for all that's worth nothing changed.

We reboot the fortigate unit a couple of days ago and nothing changed apparently but today I noticed a different error, this is today's log from the fortigate side:

ike 0: comes __CLIENT_IP__:39748->__FTG_IP__:500,ifindex=7,vrf=0....
ike 0: IKEv1 exchange=Aggressive id=c57d045b0c16a837/0000000000000000 len=661 vrf=0
ike 0: in C57D045B0C16A837000000000000000001100400000000000000029504000064000000010000000100000.............
ike 0:c57d045b0c16a837/0000000000000000:16346: responder: aggressive mode get 1st message...
ike 0:c57d045b0c16a837/0000000000000000:16346: VID CISCO-UNITY 12F5F28C457168A9702D9FE274CC0100
ike 0:c57d045b0c16a837/0000000000000000:16346: VID RFC 3947 4A131C81070358455C5728F20E95452F
ike 0:c57d045b0c16a837/0000000000000000:16346: VID draft-ietf-ipsec-nat-t-ike-02 CD60464335DF21F87CFDB2FC68B6A448
ike 0:c57d045b0c16a837/0000000000000000:16346: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913EBB696E086381B5EC427B1F
ike 0:c57d045b0c16a837/0000000000000000:16346: VID DPD AFCAD71368A1F1C96B8696FC77570100
ike 0:c57d045b0c16a837/0000000000000000:16346: VID forticlient connect license 4C53427B6D4********
ike 0:c57d045b0c16a837/0000000000000000:16346: VID Fortinet Endpoint Control B4F01CA951E9DA8D0BAFB********
ike 0::16346: received peer identifier DER_ASN1_DN '[cert information]'
ike 0: IKEv1 Aggressive, comes __CLIENT_IP__:39748->__FTG_IP__ 7
ike 0:c57d045b0c16a837/0000000000000000:16346: my proposal, gw __VPN_TUNNEL_NAME__:
ike 0:c57d045b0c16a837/0000000000000000:16346: proposal id = 1:
ike 0:c57d045b0c16a837/0000000000000000:16346: protocol id = ISAKMP:
ike 0:c57d045b0c16a837/0000000000000000:16346: trans_id = KEY_IKE.
ike 0:c57d045b0c16a837/0000000000000000:16346: encapsulation = IKE/none
ike 0:c57d045b0c16a837/0000000000000000:16346: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256
ike 0:c57d045b0c16a837/0000000000000000:16346: type=OAKLEY_HASH_ALG, val=SHA2_512.
ike 0:c57d045b0c16a837/0000000000000000:16346: type=AUTH_METHOD, val=RSA_SIG.
ike 0:c57d045b0c16a837/0000000000000000:16346: type=OAKLEY_GROUP, val=MODP1536.
ike 0:c57d045b0c16a837/0000000000000000:16346: ISAKMP SA lifetime=86400
ike 0:c57d045b0c16a837/0000000000000000:16346: incoming proposal:
ike 0:c57d045b0c16a837/0000000000000000:16346: proposal id = 0:
ike 0:c57d045b0c16a837/0000000000000000:16346: protocol id = ISAKMP:
ike 0:c57d045b0c16a837/0000000000000000:16346: trans_id = KEY_IKE.
ike 0:c57d045b0c16a837/0000000000000000:16346: encapsulation = IKE/none
ike 0:c57d045b0c16a837/0000000000000000:16346: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256
ike 0:c57d045b0c16a837/0000000000000000:16346: type=OAKLEY_HASH_ALG, val=SHA2_512.
ike 0:c57d045b0c16a837/0000000000000000:16346: type=AUTH_METHOD, val=RSA_SIG.
ike 0:c57d045b0c16a837/0000000000000000:16346: type=OAKLEY_GROUP, val=MODP1536.
ike 0:c57d045b0c16a837/0000000000000000:16346: ISAKMP SA lifetime=86400
ike 0:c57d045b0c16a837/0000000000000000:16346: proposal id = 0:
ike 0:c57d045b0c16a837/0000000000000000:16346: protocol id = ISAKMP:
ike 0:c57d045b0c16a837/0000000000000000:16346: trans_id = KEY_IKE.
ike 0:c57d045b0c16a837/0000000000000000:16346: encapsulation = IKE/none
ike 0:c57d045b0c16a837/0000000000000000:16346: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256
ike 0:c57d045b0c16a837/0000000000000000:16346: type=OAKLEY_HASH_ALG, val=SHA2_512.
ike 0:c57d045b0c16a837/0000000000000000:16346: type=AUTH_METHOD, val=RSA_SIG.
ike 0:c57d045b0c16a837/0000000000000000:16346: type=OAKLEY_GROUP, val=MODP1536.
ike 0:c57d045b0c16a837/0000000000000000:16346: ISAKMP SA lifetime=86400
ike 0:c57d045b0c16a837/0000000000000000:16346: negotiation failure
ike Negotiate ISAKMP SA Error: ike 0:c57d045b0c16a837/0000000000000000:16346: no SA proposal chosen

Both incoming and expected proposals matched (apparently) and yet I was getting "negotiation failure, no SA proposal chosen" which led me to create new certificates (once again) because I wanted to see if it was a factor (it turns out it isn't) and this led me to create another connection wich in fact, worked out of the blue.

Now, one of the weirdest things I noticed was the fact that Forticlient was now showing me EVERY single certificate in my system, so I chose the very same configuration I had and now it successfully connects, I then go back to the fortigate, select my old certificates, return to my forticlient and select my OLD certificate and once again, boom, I have a working connection again.

The fact that certificates disappear out of nothing and the fact that diff connections with the same configuration behave differently makes me think there's something wrong inside the forticlient. Oooh remember that the very same VPN worked 100% of the time under Linux + strongswan client.

Although I didn't solve "the real problem" I have a working tunnel again. I can't say for sure what fixed but I hope this helps someone.
Thanks to everyone