Unable to stablish first IPSec VPN

[cookiemonster]

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.

[cookiemonster]

This is what the redacted logs have:

Code Select Expand

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.

[cookiemonster]

Anyone please?
Perhaps someone who has setup IPSev with IKEv2 and EAP-TLS with an iphone as a client, to compare setup ?

[cookiemonster]

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 :)
You cannot view this attachment.

[cookiemonster]

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.

[Monviech (Cedrik)]

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.

[cookiemonster]

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.

[Monviech (Cedrik)]

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

[cookiemonster]

@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'"

[cookiemonster]

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

You're quite right. Painful it is. Appreciate the response. Any thoughts to investigate, please share.

[Monviech (Cedrik)]

If the certificate cannot be found, its a certificate issue, most likely common name mismatch in the client certificate with the username.

[cookiemonster]

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?

[cookiemonster]

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.

Code Select Expand

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.

Code Select Expand

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.

[Monviech (Cedrik)]

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.

[Patrick M. Hausen]

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