Hello. First foray into an IPSec VPN for me. I need some help to get over the line please.
Goal: Setup as Roadwarrior using shared ip pool, using EAP-TLS.
Problem is that the connection is not completed, from the client.
IPSec log shows authentication successful, generating IKE_AUTH response and then sending the packet. Then no logs of anything received followed with deleting half open IKE_SA with client after timeout.
I appreciate it looks like a client problem but this is an iOS native vpn so no logs there I can see.
I have created a CA, intermediate and one leaf for this first client. All three installed on the iOS client.
Looking for some hints.
I have followed the docs line by line numerous times to be sure. I have been unable to follow only one item that seems in my ignorance that is only the docs to be needing adjusting. I am referring to this:
https://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html#eap-tls
Only one rule I haven't yet done is Firewall: NAT: Outbound. The reason is wanting to get the client in before getting it to go out to Internet via the tunnel.
I can see the firewall allowed hits from the outside, on both ports 500 and 4500
1.3 - VPN: IPsec: Connections
General Settings:
Proposals: aes256-sha256-ecs256 (Disable default!)
- My OPN version is 25.1.12. I don't have this suite in the list. So I have used another Proposals aes256-sha256-ecp256 [DH19, NIST EC] (Disabled default!)
- The doc shows that the children's ESP proposal matches the connection proposal. So I matched it.
The docs usually are just an example, so I expect the use of another suite to be OK, and that the matching child with connection proposal is relevant but I don't know if is necessary.
This is what the redacted logs have:
2025-08-14T12:22:44 Informational charon 09[JOB] <2921eb48-6200-422a-9227-6d669430dc83|8> deleting half open IKE_SA with 192.168.5.235 after timeout
2025-08-14T12:22:14 Informational charon 09[NET] <2921eb48-6200-422a-9227-6d669430dc83|8> sending packet: from {mypublicip}[4500] to 192.168.5.235[4500] (628 bytes)
2025-08-14T12:22:14 Informational charon 09[NET] <2921eb48-6200-422a-9227-6d669430dc83|8> sending packet: from {mypublicip}[4500] to 192.168.5.235[4500] (1236 bytes)
2025-08-14T12:22:14 Informational charon 09[ENC] <2921eb48-6200-422a-9227-6d669430dc83|8> generating IKE_AUTH response 1 [ EF(2/2) ]
2025-08-14T12:22:14 Informational charon 09[ENC] <2921eb48-6200-422a-9227-6d669430dc83|8> generating IKE_AUTH response 1 [ EF(1/2) ]
2025-08-14T12:22:14 Informational charon 09[ENC] <2921eb48-6200-422a-9227-6d669430dc83|8> splitting IKE message (1792 bytes) into 2 fragments
2025-08-14T12:22:14 Informational charon 09[ENC] <2921eb48-6200-422a-9227-6d669430dc83|8> generating IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
2025-08-14T12:22:14 Informational charon 09[IKE] <2921eb48-6200-422a-9227-6d669430dc83|8> sending issuer cert "C=GB, ST=Manchester, L=Salford, O=moomooland, OU=IT, E=replacedemail@example.net, CN=intermediate-ca"
2025-08-14T12:22:14 Informational charon 09[IKE] <2921eb48-6200-422a-9227-6d669430dc83|8> sending end entity cert "C=GB, ST=Manchester, L=Salford, O=moomooland, OU=IT, E=replacedemail@example.net, CN=vpn1.mydpublicdomain.com"
2025-08-14T12:22:14 Informational charon 09[IKE] <2921eb48-6200-422a-9227-6d669430dc83|8> authentication of 'vpn1.mydpublicdomain.com' (myself) with ECDSA_WITH_SHA256_DER successful
2025-08-14T12:22:14 Informational charon 09[IKE] <2921eb48-6200-422a-9227-6d669430dc83|8> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
2025-08-14T12:22:14 Informational charon 09[IKE] <2921eb48-6200-422a-9227-6d669430dc83|8> peer supports MOBIKE
2025-08-14T12:22:14 Informational charon 09[IKE] <2921eb48-6200-422a-9227-6d669430dc83|8> initiating EAP_IDENTITY method (id 0x00)
2025-08-14T12:22:14 Informational charon 09[CFG] <2921eb48-6200-422a-9227-6d669430dc83|8> selected peer config '2921eb48-6200-422a-9227-6d669430dc83'
2025-08-14T12:22:14 Informational charon 09[CFG] <8> looking for peer configs matching {mypublicip}[vpn1.mydpublicdomain.com]...192.168.5.235[vpn1.mydpublicdomain.com]
2025-08-14T12:22:14 Informational charon 09[ENC] <8> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ]
2025-08-14T12:22:14 Informational charon 09[ENC] <8> unknown attribute type INTERNAL_DNS_DOMAIN
2025-08-14T12:22:14 Informational charon 09[NET] <8> received packet: from 192.168.5.235[4500] to {mypublicip}[4500] (416 bytes)
2025-08-14T12:22:14 Informational charon 09[NET] <8> sending packet: from {mypublicip}[500] to 192.168.5.235[500] (280 bytes)
2025-08-14T12:22:14 Informational charon 09[ENC] <8> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
2025-08-14T12:22:14 Informational charon 09[IKE] <8> faking NAT situation to enforce UDP encapsulation
2025-08-14T12:22:14 Informational charon 09[CFG] <8> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
2025-08-14T12:22:14 Informational charon 09[IKE] <8> 192.168.5.235 is initiating an IKE_SA
2025-08-14T12:22:14 Informational charon 09[ENC] <8> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]
2025-08-14T12:22:14 Informational charon 09[NET] <8> received packet: from 192.168.5.235[500] to {mypublicip}[500] (370 bytes)
Anything there?
Note: this was a test from within the same lan but it is the same from outside, just the IP address changes.
Anyone please?
Perhaps someone who has setup IPSev with IKEv2 and EAP-TLS with an iphone as a client, to compare setup ?
I am preparing to close this thread down. I have had success following https://forum.opnsense.org/index.php?topic=44061.msg219647#msg219647 which I had seen but I followed the official current docs, which seem to have been updated based on this user's input (thanks @d39FAPH7 and @Monviech (Cedrik)).
What threw me was that the docs aren't exactly matching. With so many options a mismatch can be difficult to know which one to follow.
All that said, the problem for me appears to be with the certificates. I had created both CA and server with key as EC256. Not good for the iOS 18.6.1 client. RSA-2048 (Default) does. That seemed to be the problem.
Logs on server give no hint by the way.
Edit: also the docs don't mention that the correct type of cert for the server is of course server which was my suspicion and took me some reading in different places to confirm it and then confirmed it on this referenced post. Instead says the leaf. Got me chasing my tail :)
Screenshot from 2025-08-21 17-27-17.png
I spoke too soon. I started again so I had a tidy and reproducible setup and I can not get the client to authenticate.
The difference (if nothing for me to keep track) is I used a key RSA size 4096 bit (not default) so that might be the reason so I will have to start over again. So no success yet. It is a little frustrating.
This whole thread is my exact experience with roadwarrior ipsec.
I would always use OpenVPN or Wireguard now.
I would only use IPsec out of sheer desperation if its not for site2site.
Yes the documentation is long, I wrote it all, I dont know if it still works. Every OS change on the client side might break something ipsec related.
If you find it out please give feedback so the guide can be updated. I dont have time currently to verify it.
Thanks for the acknowledgement Monviech. I have you as one of the more knowledgeable people around for it.
Yes I have Wireguard working fine but this is a bit of a site2site one. I do wish to get it to work but your are right, it is painful.
It seems the documentation is not quite right though that thread is the nearest BUT we need help diagnosing on the OPN side.
I do a lot of Ipsec commercial support, and I can tell you that it never involves eap-tls.
Ipsec is uses site 2 site from router to router via psk or rsa keys, and openvpn is used for the roadwarriors.
This combination works, is business proven.
Anything else (especially eap-tls) is if you want to feel the pain. :D
@Monviech perhaps you can tell me where the Certs created in OPN are stored? A find on the filesystem gave me no results. And/or how does the IPSec code walks up the trust chains. That's what seems to be failing somehow. i.e the client cert exists, it is signed by the same CA.
From the github issue now logged, you can see now that the problem is "received fatal TLS alert 'certificate unknown'"
Quote from: Monviech (Cedrik) on August 28, 2025, 05:19:01 PMI do a lot of Ipsec commercial support, and I can tell you that it never involves eap-tls.
Ipsec is uses site 2 site from router to router via psk or rsa keys, and openvpn is used for the roadwarriors.
This combination works, is business proven.
Anything else (especially eap-tls) is if you want to feel the pain. :D
You're quite right. Painful it is. Appreciate the response. Any thoughts to investigate, please share.
If the certificate cannot be found, its a certificate issue, most likely common name mismatch in the client certificate with the username.
NO no I found them now. They're in /usr/local/etc/swanctl/
Name Mismatch I need to drill into. I have a username (that does not exist on the OPN db) declared in the client cert that is not the same as anything else. What do you mean please?
I might be on the wrong path but see this. Some certs are soft linked in /usr/local/etc/swanctl/x509ca/ . I assume this is the place for CAs only.
penguin@OPNsense:~ $ ls -alh /usr/local/etc/swanctl/x509ca/
total 55
drwxr-xr-x 2 root wheel 22B Aug 27 22:35 .
drwxr-xr-x 16 root wheel 19B Jul 5 01:03 ..
-rw-r----- 1 root wheel 1.5K Aug 27 22:35 3285fdb3.0.crt
-rw-r----- 1 root wheel 1.5K Aug 27 22:35 462422cf.0.crt
lrwxr-x--- 1 root wheel 14B Aug 12 16:55 60b6690d48092.crt -> 7de19d92.0.crt
lrwxr-x--- 1 root wheel 14B Aug 12 16:55 6194f84831c68.crt -> 8d33f237.0.crt
lrwxr-x--- 1 root wheel 14B Aug 12 16:55 630e092f49140.crt -> 8a6584a6.0.crt
lrwxr-x--- 1 root wheel 14B Aug 12 16:55 66a5b16a759dd.crt -> 9aad238c.0.crt
lrwxr-x--- 1 root wheel 14B Aug 12 16:55 66f4cb6e54cc7.crt -> 462422cf.0.crt
lrwxr-x--- 1 root wheel 14B Aug 12 16:55 689a1e7ea53e7.crt -> 3e741b88.0.crt
lrwxr-x--- 1 root wheel 14B Aug 12 16:55 689a6ba3882ea.crt -> 781cea7a.0.crt
lrwxr-x--- 1 root wheel 14B Aug 21 16:05 68a72f50dfe82.crt -> 52ac0765.0.crt
lrwxr-x--- 1 root wheel 14B Aug 21 23:52 68a79cfebefc4.crt -> 3285fdb3.0.crt
lrwxr-x--- 1 root wheel 14B Aug 22 16:51 68a8904b6b0bd.crt -> f66f9cdd.0.crt
lrwxr-x--- 1 root wheel 14B Aug 26 17:28 68ada38035eb5.crt -> f66f9cdd.0.crt
lrwxr-x--- 1 root wheel 14B Aug 27 11:26 68aed70399f58.crt -> e755faf7.0.crt
lrwxr-x--- 1 root wheel 14B Aug 27 22:35 68af7828b4e69.crt -> 3285fdb3.0.crt
-rw-r----- 1 root wheel 1.2K Aug 27 22:35 7de19d92.0.crt
-rw-r----- 1 root wheel 1.4K Aug 27 22:35 8a6584a6.0.crt
-rw-r----- 1 root wheel 1.8K Aug 27 22:35 8d33f237.0.crt
-rw-r----- 1 root wheel 1.5K Aug 27 22:35 9aad238c.0.crt
-rw-r----- 1 root wheel 2.2K Aug 27 22:35 e755faf7.0.crt
But then if for instance I try to look in one with a link to a file that does not exist, of course it fails.
penguin@OPNsense:~ $ pki --print --in /usr/local/etc/swanctl/x509ca/462422cf.0.crt
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
subject: "C=US, O=Let's Encrypt, CN=E5"
issuer: "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
validity: not before Mar 13 00:00:00 2024, ok
not after Mar 12 23:59:59 2027, ok (expires in 561 days)
serial: 83:8f:6c:63:ce:b1:39:8c:62:06:62:83:15:c9:fd:de
flags: CA CRLSign serverAuth clientAuth
CRL URIs: http://x1.c.lencr.org/
pathlen: 0
certificatePolicies:
2.23.140.1.2.1
authkeyId: 79:b4:59:e6:7b:b6:e5:e4:01:73:80:08:88:c8:1a:58:f6:e9:9b:6e
subjkeyId: 9f:2b:5f:cf:3c:21:4f:9d:04:b7:ed:2b:2c:c4:c6:70:8b:d2:d7:0d
pubkey: ECDSA 384 bits
keyid: e5:43:55:33:26:ce:0c:be:eb:cc:d6:37:1a:b5:c6:a2:8a:c0:89:07
subjkey: 99:cd:29:c3:a1:58:26:af:7a:7a:4c:84:5a:8f:73:88:60:b0:df:de
penguin@OPNsense:~ $ pki --print --in /usr/local/etc/swanctl/x509ca/3e741b88.0.crt
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
opening '/usr/local/etc/swanctl/x509ca/3e741b88.0.crt' failed: No such file or directory
building CRED_CERTIFICATE - X509 failed, tried 4 builders
parsing input failed
So why are there seemingly incorrect symlinks and is that an explanation for not finding the client cert? I don't know either but looks strange.
I have never done the esp-tls setup.
From what I understand from a high level view, you need 3 certificates:
Self signed root
root signed leaf (server use)
root signed leaf (client use)
Best no lets encrypt anywhere.
The server and the client both need the signed root.
The server needs the server certificate. The client /must/ use an FQDN to contact the von server, and the FQDN must be in the server certificate, as SAN (subject alternative name) otherwise no match.
The client needs the client certificate. The eap username configured in the opnsense must match with the common name in the client certificate, otherwise no match.
In the remote and local authentication these certificates have to be set.
Im not 100% sure here but thats what I imagine.
The symlinks are hash values of the content of the installed certificates. Each symlink should point to a valid file. There is a hash script to update/produce these, but of course in an appliance context all of this should "just work" without any orphaned ones.
For reference: https://docs.openssl.org/3.5/man1/openssl-rehash/#description
Quote from: Monviech (Cedrik) on August 28, 2025, 06:55:54 PMI have never done the esp-tls setup.
From what I understand from a high level view, you need 3 certificates:
Self signed root
root signed leaf (server use)
root signed leaf (client use)
Best no lets encrypt anywhere.
The server and the client both need the signed root.
The server needs the server certificate. The client /must/ use an FQDN to contact the von server, and the FQDN must be in the server certificate, as SAN (subject alternative name) otherwise no match.
The client needs the client certificate. The eap username configured in the opnsense must match with the common name in the client certificate, otherwise no match.
In the remote and local authentication these certificates have to be set.
Im not 100% sure here but thats what I imagine.
Exactly what I have Cedrik, and have done various times to ensure I weed out any mistakes but I keep failing.
The only element I'd like to validate is this one, where I feel I have a misconfiguration OR OPN is not matching a cert where it should:
QuoteThe client needs the client certificate. The eap username configured in the opnsense must match with the common name in the client certificate, otherwise no match.
Where is that done? The remote section in the docs have no users to use
Remote.png
I have been using the client cert (.p12 bundle of cert and private key & password protected), with the client also of course having the public cert of the CA installed and made trusted. The CN on this client (leaf) cert and SAN for DNS also is signed by the CA on OPN. But you can still see that the IPSec failure log still says "certificate unknown"
2025-08-27T23:24:39 Informational charon 14[MGR] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> checkin and destroy IKE_SA 1c9aaddd-79af-41d2-9b2b-db85ae839384[33]
2025-08-27T23:24:39 Informational charon 03[NET] sending packet: from 92.26.121.196[4500] to 192.168.5.235[4500]
2025-08-27T23:24:39 Informational charon 14[NET] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> sending packet: from 92.26.121.196[4500] to 192.168.5.235[4500] (80 bytes)
2025-08-27T23:24:39 Informational charon 14[ENC] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> generating IKE_AUTH response 5 [ EAP/FAIL ]
2025-08-27T23:24:39 Informational charon 14[IKE] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> EAP method EAP_TLS failed for peer penguin-vpn1
2025-08-27T23:24:39 Informational charon 14[TLS] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> received fatal TLS alert 'certificate unknown'
2025-08-27T23:24:39 Informational charon 14[ENC] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> parsed IKE_AUTH request 5 [ EAP/RES/TLS ]
2025-08-27T23:24:39 Informational charon 14[NET] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> received packet: from 192.168.5.235[4500] to 92.26.121.196[4500] (96 bytes)
2025-08-27T23:24:39 Informational charon 14[MGR] IKE_SA 1c9aaddd-79af-41d2-9b2b-db85ae839384[33] successfully checked out
2025-08-27T23:24:39 Informational charon 14[MGR] checkout IKEv2 SA by message with SPIs 65ce1e4934bf1455_i c22f661e67a203da_r
2025-08-27T23:24:39 Informational charon 02[NET] waiting for data on sockets
2025-08-27T23:24:39 Informational charon 02[NET] received packet: from 192.168.5.235[4500] to 92.26.121.196[4500]
2025-08-27T23:24:39 Informational charon 03[NET] sending packet: from 92.26.121.196[4500] to 192.168.5.235[4500]
2025-08-27T23:24:39 Informational charon 14[MGR] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> checkin of IKE_SA successful
2025-08-27T23:24:39 Informational charon 14[MGR] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> checkin IKEv2 SA 1c9aaddd-79af-41d2-9b2b-db85ae839384[33] with SPIs 65ce1e4934bf1455_i c22f661e67a203da_r
2025-08-27T23:24:39 Informational charon 14[NET] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> sending packet: from 92.26.121.196[4500] to 192.168.5.235[4500] (832 bytes)
2025-08-27T23:24:39 Informational charon 14[ENC] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> generating IKE_AUTH response 4 [ EAP/REQ/TLS ]
2025-08-27T23:24:39 Informational charon 14[ENC] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> parsed IKE_AUTH request 4 [ EAP/RES/TLS ]
2025-08-27T23:24:39 Informational charon 14[NET] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> received packet: from 192.168.5.235[4500] to 92.26.121.196[4500] (80 bytes)
2025-08-27T23:24:39 Informational charon 14[MGR] IKE_SA 1c9aaddd-79af-41d2-9b2b-db85ae839384[33] successfully checked out
2025-08-27T23:24:39 Informational charon 14[MGR] checkout IKEv2 SA by message with SPIs 65ce1e4934bf1455_i c22f661e67a203da_r
2025-08-27T23:24:39 Informational charon 02[NET] waiting for data on sockets
2025-08-27T23:24:39 Informational charon 02[NET] received packet: from 192.168.5.235[4500] to 92.26.121.196[4500]
2025-08-27T23:24:39 Informational charon 03[NET] sending packet: from 92.26.121.196[4500] to 192.168.5.235[4500]
2025-08-27T23:24:39 Informational charon 14[MGR] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> checkin of IKE_SA successful
2025-08-27T23:24:39 Informational charon 14[MGR] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> checkin IKEv2 SA 1c9aaddd-79af-41d2-9b2b-db85ae839384[33] with SPIs 65ce1e4934bf1455_i c22f661e67a203da_r
2025-08-27T23:24:39 Informational charon 14[NET] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> sending packet: from 92.26.121.196[4500] to 192.168.5.235[4500] (1104 bytes)
2025-08-27T23:24:39 Informational charon 14[ENC] <1c9aaddd-79af-41d2-9b2b-db85ae839384|33> generating IKE_AUTH response 3 [ EAP/REQ/TLS ]And that is the CN on the cert
Penguin-cert.png
So, is there another place I must put the user on ?
Quote from: Patrick M. Hausen on August 28, 2025, 07:03:55 PMThe symlinks are hash values of the content of the installed certificates. Each symlink should point to a valid file. There is a hash script to update/produce these, but of course in an appliance context all of this should "just work" without any orphaned ones.
For reference: https://docs.openssl.org/3.5/man1/openssl-rehash/#description
That is also very good information thank you Patrick. I definitively have sims to non-existing ones. No idea why. I haven't had any error messages when creating the CA and the other certs.
I'll have a read to see if I should rehash them.
I dont know how eap-tls works completely.
The part that I ran productively in that documentation is the mschapv2 setup, which does not beed client certificates and is much simpler to setup and troubleshoot.
Otherwise please just use openvpn or wireguard.
Im using openvpn with viscosity on a mac and never looked back, ipsec is just pain compared to that. And it continues to work after macos updates, unlike ipsec where they change something convoluted about the ciphers they accept and bam it just doesnt work anymore.
I will most likely not spend any time on this, sorry.
Ok that's fair if you don't use it. Thanks for the inputs you've made to this thread.
If it's site2site, use a suitably long PSK.
IPSec is bad enough without using certificates, unfortunately.
Speaking as the one who does the level 3 ipsec support at my employer.
thanks. It is a static "site" bimbar but technically is a road warrior setup. It is for my son to be able to connect to home now that he has moved out, so that he can backup to the home NAS.
For that I want to issue him certs he can then use on an apple mac but also on his iphone from time to time. There are other reasons I want to have this setup even if I have a wireguard setup working fine.
So I am mis-classifying it as S2S. It is road warrior.
Pesky certificates are not seemingly being accepted/found by OPN despite being setup as per documentation.
Any thoughts on what else to check, I'll be grateful.
Use OpenVPN, it really works flawlessly with any apple devices, and it also uses client certificates.
It is well documented and most businesses use it (and not ipsec) for these kinds of setups.
Problem is Cedrik that I also need to be able to connect to home network from time to time when using work devices. OpenVPN is not allowed but IPSec is. Not my policies.
I appreciate the input, I do. However I fail to understand why core functionality seems to not work despite following the documentation, and suggestions are to not use it.
These IPsec roadwarrior setup examples are more in community support scope, they are incredibly hard to troubleshoot without doing remote support. And even then its crawling logs and turning knobs until it finally works.
A good example to start with would be the MSCHAPv2 guide, I used that on MacOS before with the NCP client, productively with a business client in my previous job for around 2 years.
I needed around 2 weeks to get a stable setup, thats when I wrote the documentation for it (while I was still a community member).
The EAP-TLS example is a creation by a different user in the forum, adapted by me. I followed that discussion and saw how different iOS or MacOS version changed behavior without prior notice, and it stopped to work for that user on quite some occasions.
If the EAP-TLS example does not work, please create an issue in the docs repository and point out which steps are wrong or unclear. But verifying and testing this takes lots of time, as you probably noticed yourself by now. It is just a very complex setup that not a lot of people use right now in the connections GUI.
Understood. Thank you Cedrik.
Hallo,
I've been using IKEv2 with EAP‑TLS for years (not OPNsense but vanilla FreeBSD with strongswan) and have seen various odd issues, all of them were client issues.
On iOS and other Apple os, these problems are often due to Apple's strict certificate requirements, for example:
- certain certificate extensions must be marked as critical
- client certificates may fail if their lifetime exceeds one or two years (I don't remember, but currently I use 365 days for server and client certs)