FortiGate and Alwayson VPN

Hello everyone,

I’m currently rebuilding our always-on VPN to use certificate authentication. We are using a FortiGate 1800F cluster with the native Windows client. Certificates are deployed to our clients via SCEP through Intune. The FortiGate acts as the VPN server, with PacketFence as the RADIUS authentication.

In Windows, I’ve set the VPN type to IKEv2, with the option “Use machine certificates” checked. However, when trying to connect, I receive the error message: “IKE failed to find a valid machine certificate.”

Client certificate is placed in Machine → Personal and the server certificate placed in Machine → Trusted Certificate Authorities.
Root CA also placed in Trusted Certificate Authorities.

In the FortiGate logs, I do see the following entry:

FortiGate (root) # ike V=root:0: comes x.x.x.x.x:1012->x.x.x.x:500,ifindex=118,vrf=0,len=384....
ike V=root:0: IKEv2 exchange=SA_INIT id=7dab74ffc6a9a669/0000000000000000 len=384
ike 0: in 7DAB74FFC6A9A6690000000000000000212022080000000000000180220000300000002C010100040300000C0100000C800E0100030000080300000C0300000802000005000000080400001428000068001400000A83AEA46B646C70E6ABCEA32017FE7715E7ED26802732F232A1051BD7270B90554C257592E4D52886DF617734098CC43ED15B313FA55E18A401A9CB281F95725E749FB97BDFE4DB1F97371CFCB5A0B3829CB94AD5BA43E28724FBA5F0269E36290000345936E8F8F7C55B8BCB1B5447B846BB84FEE60D6DE840BE9DAA4D28DAC19ADA5CE7962B9CEB40F6AEBE7113A28193AF6B290000080000402E2900001C00004004AD3A5FA583AB9822A29A2D4C247A7D7D17FB938D2B00001C00004005E91284FEEC6A0460D09A7E8BF47BE82C0CFD12742B0000181E2B516905991C7D7C96FCBFB587E461000000092B000014FB1DE3CDF341B7EA16B7E5BE0855F1202B00001426244D38EDDB61B3172A36E3D0CFB8190000001801528BBBC00696121849AB9A1C5B2A5100000002
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: responder received SA_INIT msg
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: received notify type FRAGMENTATION_SUPPORTED
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: received notify type NAT_DETECTION_SOURCE_IP
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: received notify type NAT_DETECTION_DESTINATION_IP
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: VID MS NT5 ISAKMPOAKLEY 1E2B516905991C7D7C96FCBFB587E46100000009
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: VID unknown (16): FB1DE3CDF341B7EA16B7E5BE0855F120
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: VID unknown (16): 26244D38EDDB61B3172A36E3D0CFB819
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: VID unknown (20): 01528BBBC00696121849AB9A1C5B2A5100000002
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: incoming proposal:
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: proposal id = 1:
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:   protocol = IKEv2:
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:      encapsulation = IKEv2/none
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:         type=ENCR, val=AES_CBC (key_len = 256)
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:         type=PRF, val=PRF_HMAC_SHA2_256
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:         type=DH_GROUP, val=ECP384.
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: matched proposal id 1
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: proposal id = 1:
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:   protocol = IKEv2:
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:      encapsulation = IKEv2/none
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:         type=ENCR, val=AES_CBC (key_len = 256)
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:         type=PRF, val=PRF_HMAC_SHA2_256
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262:         type=DH_GROUP, val=ECP384.
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: lifetime=28800
ike V=root:0:7dab74ffc6a9a669/0000000000000000:13262: SA proposal chosen, matched gateway alwaysonVPN_v2
ike V=root:0:alwaysonVPN_v2:alwaysonVPN_v2: created connection: 0xf6440a0 0 x.x.x.x->x.x.x.x:1012.
ike V=root:0:alwaysonVPN_v2: HA start as master
ike V=root:0:alwaysonVPN_v2:13262: processing notify type NAT_DETECTION_SOURCE_IP
ike V=root:0:alwaysonVPN_v2:13262: processing NAT-D payload
ike V=root:0:alwaysonVPN_v2:13262: NAT detected: PEER
ike V=root:0:alwaysonVPN_v2:13262: process NAT-D
ike V=root:0:alwaysonVPN_v2:13262: processing notify type NAT_DETECTION_DESTINATION_IP
ike V=root:0:alwaysonVPN_v2:13262: processing NAT-D payload
ike V=root:0:alwaysonVPN_v2:13262: NAT detected: PEER
ike V=root:0:alwaysonVPN_v2:13262: process NAT-D
ike V=root:0:alwaysonVPN_v2:13262: processing notify type FRAGMENTATION_SUPPORTED
ike V=root:0:alwaysonVPN_v2:13262: responder preparing SA_INIT msg
ike V=root:0:alwaysonVPN_v2:13262: generate DH public value request queued
ike V=root:0:alwaysonVPN_v2:13262: responder preparing SA_INIT msg
ike V=root:0:alwaysonVPN_v2:13262: compute DH shared secret request queued
ike V=root:0:alwaysonVPN_v2:13262: responder preparing SA_INIT msg
ike V=root:0:alwaysonVPN_v2:13262: create NAT-D hash local x.x.x.x/500 remote x.x.x.x/1012
ike V=root:0:alwaysonVPN_v2:13262: sending CERTREQ payload (len=21)
ike V=root:0:alwaysonVPN_v2:13262: certreq[0]: '6429BB31975BEF471B42F6C00CAB789C7442229E'
ike 0:alwaysonVPN_v2:13262: out 7DAB74FFC6A9A669F43358F61A471791212022200000000000000121220000300000002C010100040300000C0100000C800E01000300000802000005030000080300000C0000000804000014280000680014000098E6CD7DC914A19FA2D7ECFDB75C245B2FEB8DE914B00868951D118D4F0FD69DED3C372F85FEDF82582E6744C38B6B9FB16274D54710864A1CBAAB7F32D9BA1E46CBD5EAF33BB260342B0596C25A922612655B56ADFE83CE14FDF1C8535CE11429000014DA392F970892C359745D6A9D379157CB2900001C000040042A8862BED01A19CD81371500480FE11C997D053B2600001C0000400586EAA8833AEE7399AB82DE237CEA483F150A3B1929000019046429BB31975BEF471B42F6C00CAB789C7442229E000000080000402E
ike V=root:0:alwaysonVPN_v2:13262: sent IKE msg (SA_INIT_RESPONSE): x.x.x.x:500->x.x.x.x:1012, len=289, vrf=0, id=7dab74ffc6a9a669/f43358f61a471791, oif=0
ike 0:alwaysonVPN_v2:13262: IKE SA 7dab74ffc6a9a669/f43358f61a471791 SK_ei 32:0FA5DACC125D50A0089A4DB7C709171B6C1F16D832055AB4F90BEBE294C71D13
ike 0:alwaysonVPN_v2:13262: IKE SA 7dab74ffc6a9a669/f43358f61a471791 SK_er 32:2F06F26B22A7F6745CAAD890808CFD75D0DB56AA7B39BA2BC06CC404A4B35BC7
ike 0:alwaysonVPN_v2:13262: IKE SA 7dab74ffc6a9a669/f43358f61a471791 SK_ai 32:17020575D3800E3E971941B3760380EDC79B367CF577A14B1B97E479CB2758FE
ike 0:alwaysonVPN_v2:13262: IKE SA 7dab74ffc6a9a669/f43358f61a471791 SK_ar 32:67256B42E1B6B59AC7651D639C436B10452E4BA95CC9F7F0BEA955353AFF6C7D
ike V=root:0: comes 5.22.248.250:1012->145.101.44.104:500,ifindex=118,vrf=0,len=384....
ike V=root:0: IKEv2 exchange=SA_INIT id=6fea6db642837a26/0000000000000000 len=384
ike 0: in 6FEA6DB642837A260000000000000000212022080000000000000180220000300000002C010100040300000C0100000C800E0100030000080300000C030000080200000500000008040000142800006800140000941E688488A58E191EEB2D8BB254184C88578A43F0BFC46ACDDDDAA80F5713ECCBB28AC7FBEE246282A1E5BA5FA5125A87C844EB7C5DC8E4846C1A1F1DF128D7A1E56FA9EE8FA6F891C1EF7E055FE8CCD9A737AB23CB41DCF29725CF30083351290000348AB22811F0A7712695756172258BF1A913A2F0F641D78FC142EDED2641ECF93BED8FD3AA755C9EB54B3AF6A3413441DA290000080000402E2900001C000040049C4F60EAF4E88936D9694A9AB1FC859B2B2465C92B00001C000040058F52CAB10169C176E4C9216C29AA155CA8B9F16B2B0000181E2B516905991C7D7C96FCBFB587E461000000092B000014FB1DE3CDF341B7EA16B7E5BE0855F1202B00001426244D38EDDB61B3172A36E3D0CFB8190000001801528BBBC00696121849AB9A1C5B2A5100000002
ike V=root:0:6fea6db642837a26/0000000000000000:13263: responder received SA_INIT msg
ike V=root:0:6fea6db642837a26/0000000000000000:13263: received notify type FRAGMENTATION_SUPPORTED
ike V=root:0:6fea6db642837a26/0000000000000000:13263: received notify type NAT_DETECTION_SOURCE_IP
ike V=root:0:6fea6db642837a26/0000000000000000:13263: received notify type NAT_DETECTION_DESTINATION_IP
ike V=root:0:6fea6db642837a26/0000000000000000:13263: VID MS NT5 ISAKMPOAKLEY 1E2B516905991C7D7C96FCBFB587E46100000009
ike V=root:0:6fea6db642837a26/0000000000000000:13263: VID unknown (16): FB1DE3CDF341B7EA16B7E5BE0855F120
ike V=root:0:6fea6db642837a26/0000000000000000:13263: VID unknown (16): 26244D38EDDB61B3172A36E3D0CFB819
ike V=root:0:6fea6db642837a26/0000000000000000:13263: VID unknown (20): 01528BBBC00696121849AB9A1C5B2A5100000002
ike V=root:0:6fea6db642837a26/0000000000000000:13263: incoming proposal:
ike V=root:0:6fea6db642837a26/0000000000000000:13263: proposal id = 1:
ike V=root:0:6fea6db642837a26/0000000000000000:13263:   protocol = IKEv2:
ike V=root:0:6fea6db642837a26/0000000000000000:13263:      encapsulation = IKEv2/none
ike V=root:0:6fea6db642837a26/0000000000000000:13263:         type=ENCR, val=AES_CBC (key_len = 256)
ike V=root:0:6fea6db642837a26/0000000000000000:13263:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike V=root:0:6fea6db642837a26/0000000000000000:13263:         type=PRF, val=PRF_HMAC_SHA2_256
ike V=root:0:6fea6db642837a26/0000000000000000:13263:         type=DH_GROUP, val=ECP384.
ike V=root:0:6fea6db642837a26/0000000000000000:13263: matched proposal id 1
ike V=root:0:6fea6db642837a26/0000000000000000:13263: proposal id = 1:
ike V=root:0:6fea6db642837a26/0000000000000000:13263:   protocol = IKEv2:
ike V=root:0:6fea6db642837a26/0000000000000000:13263:      encapsulation = IKEv2/none
ike V=root:0:6fea6db642837a26/0000000000000000:13263:         type=ENCR, val=AES_CBC (key_len = 256)
ike V=root:0:6fea6db642837a26/0000000000000000:13263:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike V=root:0:6fea6db642837a26/0000000000000000:13263:         type=PRF, val=PRF_HMAC_SHA2_256
ike V=root:0:6fea6db642837a26/0000000000000000:13263:         type=DH_GROUP, val=ECP384.
ike V=root:0:6fea6db642837a26/0000000000000000:13263: lifetime=28800
ike V=root:0:6fea6db642837a26/0000000000000000:13263: SA proposal chosen, matched gateway alwaysonVPN_v2
ike V=root:0: found alwaysonVPN_v2 x.x.x.x 0 -> x.x.x.x:1012
ike V=root:0:alwaysonVPN_v2 tunnel ignores oif, reset oif 118 to 0
ike V=root:0:alwaysonVPN_v2: HA state master(2)
ike V=root:0:alwaysonVPN_v2:13263: processing notify type NAT_DETECTION_SOURCE_IP
ike V=root:0:alwaysonVPN_v2:13263: processing NAT-D payload
ike V=root:0:alwaysonVPN_v2:13263: NAT detected: PEER
ike V=root:0:alwaysonVPN_v2:13263: process NAT-D
ike V=root:0:alwaysonVPN_v2:13263: processing notify type NAT_DETECTION_DESTINATION_IP
ike V=root:0:alwaysonVPN_v2:13263: processing NAT-D payload
ike V=root:0:alwaysonVPN_v2:13263: NAT detected: PEER
ike V=root:0:alwaysonVPN_v2:13263: process NAT-D
ike V=root:0:alwaysonVPN_v2:13263: processing notify type FRAGMENTATION_SUPPORTED
ike V=root:0:alwaysonVPN_v2:13263: responder preparing SA_INIT msg
ike V=root:0:alwaysonVPN_v2:13263: generate DH public value request queued
ike V=root:0:alwaysonVPN_v2:13263: responder preparing SA_INIT msg
ike V=root:0:alwaysonVPN_v2:13263: compute DH shared secret request queued
ike V=root:0:alwaysonVPN_v2:13263: responder preparing SA_INIT msg
ike V=root:0:alwaysonVPN_v2:13263: create NAT-D hash local x.x.x.x/500 remote x.x.x.x/1012
ike V=root:0:alwaysonVPN_v2:13263: sending CERTREQ payload (len=21)
ike V=root:0:alwaysonVPN_v2:13263: certreq[0]: '6429BB31975BEF471B42F6C00CAB789C7442229E'
ike 0:alwaysonVPN_v2:13263: out 6FEA6DB642837A26512B3D5D0598F0C9212022200000000000000121220000300000002C010100040300000C0100000C800E01000300000802000005030000080300000C000000080400001428000068001400000D2F387CB3D73A31BEEF9B59562B35F2B15A00348162FAC2EA26C1BD13D53F1C61EEFBE111FE1AADA6F527F06B626DB0CD0A6D75FFAA3673EF11D3E9778A19DD77C5007F978B6E8B8058E03DE5B80C79D430D36BEFF888BB24F8A504DDADF40C29000014D7B20700ECC6BB278C08E19464E9B4842900001C00004004A2842600BF426BA72DA88FCDF0E81EA0548BA0D02600001C00004005767ADE90AA4BF76321D4C198F553429DF7DC8A2429000019046429BB31975BEF471B42F6C00CAB789C7442229E000000080000402E
ike V=root:0:alwaysonVPN_v2:13263: sent IKE msg (SA_INIT_RESPONSE): x.x.x.x:500->x.x.x.x:1012, len=289, vrf=0, id=6fea6db642837a26/512b3d5d0598f0c9, oif=0
ike 0:alwaysonVPN_v2:13263: IKE SA 6fea6db642837a26/512b3d5d0598f0c9 SK_ei 32:8997D29895339E40F1BF2E30F925CC63CD679E371F5CBEA28F9570C4A868F2AF
ike 0:alwaysonVPN_v2:13263: IKE SA 6fea6db642837a26/512b3d5d0598f0c9 SK_er 32:5359865BE2E70D7E57CE5E36990EA94A2788CA5D308168E38F94A59022B601F6
ike 0:alwaysonVPN_v2:13263: IKE SA 6fea6db642837a26/512b3d5d0598f0c9 SK_ai 32:42B412E3C8B0AE9DB4447988BDA09B50D077B8FE9BF34F243F55B2056975A56A
ike 0:alwaysonVPN_v2:13263: IKE SA 6fea6db642837a26/512b3d5d0598f0c9 SK_ar 32:B20304446622C433C96C7EE083634029337A9889DEBB39DC9DA102A639CA729B
ike :shrank heap by 331776 bytes

Any ideas?

We recently moved to FortiClient based AlwaysOn as the windows client is trash

Using alwaysOn in computer-tunnel-mode needs windows enterprise license (afaik). Maybe this is your issue?

I’ve fighting with that shit a lot … key to the success is the key usage in certificates it need to be good (I don’t remember exactly ) for windows client to recognize certs

I don’t have any particular insights to offer on the error message, however we’ve been running the Microsoft AlwaysOn VPN through our Fortigate for a few years now without any problems. We do utilise a Device tunnel for the laptop to first connect, then a User tunnel when the user logs in. We use certificates from our PKI servers for both tunnels. I’d be happy to share some of that config info with you if you can be specific about which screens or settings you want to check. e.g. specifics on the certificate templates, what protocols/ports we need for inbound traffic thru the Fortigate, etc

If you haven’t already done so, check out Richard Hicks’ website for excellent AOVPN info. We actually got Richard to do the original setup for us and I’ve never regretted that decision.

I also have a build guide that we put together and could share some of that info with you (minus the network specifics and anything really sensitive).

EDIT – I should say that we don’t use the Fortigate as the endpoint for the tunnels – we use a Windows Server running RRAS for that, with another Windows Server running Network Policy Server (RADIUS) – so maybe this makes things a lot different from your setup?

Can you share the configuration for the windows .pbk used to connect the vpn? Also, you doing the user-tunnel or device tunnel?

Haha, that’s right. The IT department gave me the wrong laptop, one with Windows 11 Education. Now I’m running Enterprise, and I’ve made some progress.
The FortiGate logs show the following:

ike V=root:0:alwaysonVPN_v2:14979: error, payload not encrypted

At Fortinet, I found this

Which is strange, because both the laptop and the FortiGate are set to IKEv2.

Yes, it seems that the server certificate is correct (with the IKE intermediate), as it also works with our previous VPN configuration. It really appears to be an issue with the certificate-based authentication…

We’re using device tunnel

Here you can download the file :slight_smile: I changed it to txt.

Education works fine for AlwaysOn VPN.
Is the Forti Peercertificate signed from the same CA?
What does the Packetfence say?

I have a working AlwaysOn Config that i can lookup tomorrow, however we’re using Windows NPS instead of Packetfence.

But I don’t mean server but client (machine - device ) cert windows don’t chose cert to use because cert have wrong “extended key usage”

Hi!
PacketFence is also our CA, linked with Intune so that we can deploy certificates via SCEP. Any device with this Intune policy receives a certificate from PF.
I have indeed created a peer with the Root CA, as described here.

Additionally, I created a self-signed certificate for the server connection. This is configured in the FortiGate under the “signature” option in the VPN setup.
I have also placed that certificate in the client’s Root Certificate Store. The certificate includes the Extended Key Usage “IKE intermediate” (1.3.6.1.5.5.8.2.2).
PacketFence is not yet providing logs because the error occurs at the Gate level. No authentication is made yet.

I’m very curious about your configuration!

Sorry, took a lot longer to get back to you then i anticipated…

Our Signature-Fortigate-Certificate has IKE Intermediate (although that doesn’t seem to be needed anymore) and more importantly “TLS Web Server Authentication” set as Key Usages. Clientcertificates are the default Windows “Computer” Template.

As far as i’m aware the Signature Certificate and the Peer certificates (from the Clients) need to resolve to the same CA, you cannot use a self-signed/different CA for the signature Certificate.

If you select “Use machine certificates” instead of EAP, the Radius Server is never involved, the Fortigate alone validates the Certificate and allows the Connection. Device-Tunnel does not support EAP (and therefore Radius) AUTH. If you want EAP you need to use User-Tunnel which has it’s own drawbacks.

Here are the Parts from our Config for the DeviceTunnel.

https://pastebin.com/aEHxGqBT