What to do and what to avoid for IPsec connections (swanctl) on iOS

[meyergru]

Hi everyone,


I usually prefer Wireguard for its simplicity, but I found that some ISPs block it using Deep Packet Inspection (even for the purpose of fighting copyright violations). IPsec, being the more "enterprise" VPN protocol, is less often blocked, so it is handy to have a fallback.

While setting up an IKEv2 EAP-MSCHAPv2 Roadwarrior connection using the modern VPN: IPsec: Connections module according to the official OPNsense Roadwarrior (swanctl) Documentation, you might run into situations where the connection seems established on the firewall (swanctl --list-sas), but 0 packets / 0 bytes are being transmitted.

To save you hours of structural troubleshooting on the FreeBSD kernel or routing layers, here is a definitive list of bullet points on what actually causes issues with modern iOS/macOS clients—and what you can safely ignore.

⚠️ The Real Problems (What you must avoid / fix)

• Avoid Manual Profile Configuration (The DNS Trap)
  
  • The Issue: Typing the VPN credentials directly into the native iOS VPN settings menu.
    
  • The Impact: iOS manually configured profiles strictly ignore the DNS Configuration Payload sent by the server. This happens regardless of whether you use Split Tunneling or Full Tunneling (0.0.0.0/0). Internal DNS resolution will be completely broken.
    
  • The Fix: You must deploy the configuration via a .mobileconfig file to explicitly inject the DNS structure into the Apple network stack.
    You can create such profiles with the free Imazing app.
    
• Avoid "long" Server Certificate Lifetimes
  
  • The Issue: Creating a server certificate with a really long validity period, like more than a year.
    
  • The Impact: The Apple crypto subsystem silently and rigidly rejects any server certificate with too long lifetimes exceeding.
    
  • Note: While this rule can technically be bypassed by backdating the "Not Before" timestamp years into the past via OpenSSL CLI commands, the OPNsense GUI does not allow backdating (it always forces creation date to time()). Therefore, stick to ACME/Let's Encrypt (90 days) or issue short-lived certificates.
    Note: This will not be any problem when using ACME-type certificates. Also, the System : Trust : Certificate dialogue will preset the certificate lifetime with 397 days for this very reason.
    
• Avoid Missing Server Authentication EKU
  
  • The Issue: Generating the server certificate as a generic or unconstrained type.
    
  • The Impact: The certificate must explicitly contain the Extended Key Usage (EKU) attribute TLS Web Server Authentication. Without it, iOS drops the connection instantly during the IKE_AUTH phase. This is also done automatically in System : Trust : Certificate if you select "Server Authentication".
    
• Avoid Non-RSA certificates
  
  • The Issue: Generating the server certificate as an EC certificate.
    
  • The Impact: The certificate must be an RSA certificate to be recognized. This is also done automatically in System : Trust : Certificate per default.
    

ℹ️ The Cosmetic Illusion (Do not judge the connection by this)

• The Missing VPN Icon
  
  • The Reality: In current iOS versions, the VPN icon in the status bar standardly disappears after a successful IKEv2 handshake. Do not assume a vanished icon means a routing failure, a bad configuration, or a silent disconnect. The tunnel remains fully active (ESTABLISHED / INSTALLED in swanctl), even when the icon is missing. The status display is not tied to a failing DNS check.
    

🚫 Mythbusting (What is NOT the problem)

If your tunnel is up but registers 0 packets on active SAs, do not waste your time troubleshooting the following theoretical network pitfalls, as iOS handles them perfectly fine:

• Overlapping / Supernet Routing: iOS handles broad local traffic selectors like 192.168.0.0/16 flawlessly alongside CGNAT or carrier cellular networks. However, use a disjoint network for your IP pools.
  
• MTU sizes: IP fragmentation is handled correctly, but AI agents will often misinterpret log messages as to try to make the
  
• Multiple LocalNets / Comma-separated Lists: The native Apple client parses multiple distinct local networks in the traffic selector correctly.
  
• Strict SAN / Wildcard Validation: Wildcard certificates (*.domain.tld) or strict Subject Alternative Name (SAN) match anomalies are not the cause of 0-byte transmission stalls.
  
• IPv6 problems: There are none. AI bots may also misinterpret mixed IP adressing for the connection itself and the tunnel IPs, but that is not a problem.
  

Summary for a working setup:
Follow the official documentation, make sure your certificate is short-lived with the correct Server-EKU, ignore the missing status bar icon, and deploy the client configuration exclusively via a tailored .mobileconfig profile to get proper DNS access.

[Patrick M. Hausen]

🙇

[cookiemonster]

Thank you for this @meyergru . I had to abandon my last attempt at this and I can see from this what changes I must adopt despite following the guide, for instance not manually crafting the certs but using an app. The price of the recommended one for the this purpose stings but the technical background is very valuable. Thank you. I might be able to re-visit the attempts.

[newsense]

>>> Avoid Server Certificate Lifetimes > 397 Days


Or simply use your own certificate that can be issued from OPNSense, and enjoy 730 days of certificate validity. This is the hard limit from Apple for private/enterprise CAs

As long as you're controlling everything else on your VPN/devices importing your own CA everywhere is a no brainer.

[cookiemonster]

>>> Avoid Server Certificate Lifetimes > 397 Days


Or simply use your own certificate that can be issued from OPNSense, and enjoy 730 days of certificate validity. This is the hard limit from Apple for private/enterprise CAs

As long as you're controlling everything else on your VPN/devices importing your own CA everywhere is a no brainer.

So is this not going counter to the 397 days advice above? Asking because last time i was on this, the amount of effort I put into in vain was high.

[newsense]

Actually I think @meyergru forgot we're already down to 199 days for public certificates and come next March the value will be 100 days, and 45 days in another year.

Until we get hybrid certificates there's literally no justification for having to tinker with certificates every so often on your own vpn.

They're doing it to reduce costs mainly in the public space, and also to increase revenue by selling you certificate lifecycle management services now that LetsEncrypt destroyed their highly lucrative business of selling EV certificates as if they would have provided better security than OV or DV ones.


In a nutshell, you'll need the root on the devices you'll use for IPsec ( or any other place you use certificates issued by your own CA ). Create those certificates with 730 days validity and they will work fine until Apple or some other big player decides arbitrarily to reduce that number.

[Patrick M. Hausen]

Create those certificates with 730 days validity and they will work fine until Apple or some other big player decides arbitrarily to reduce that number.

I guess that this number is 825, really. That's based on my own research and tests for browser certificates.

Theoretically private CAs and certs can have arbitrarily long lifetimes. And e.g. Windows will respect that. When in 2018 the browser consortium decided to lower the maximum for public certs to 825 days Apple messed it up and limited the lifetime for all certs including private ones.

When the next round of lifetime cuts happened in 2020 the limit for public ones was reduced to 397 days. Luckily this time Apple did not touch the maximum for private certs.

So to the best of my knowledge today the situation is as follows:

- Public CA: 200 days since March 2026 (used to be 397), 100 days from March 2027, 47 days from March 2029
- Private CA: arbitrary for most platforms, 825 days for Apple.

I might be wrong about the 730 vs. 825 days value in the specific case of IPsec, I have only tested browsers, not certificate based VPNs.

Our company OpenVPN uses certs issued by a private CA with 10 years of cert lifetime without problems. Of course we have additional strong password authentication per user.

HTH,
Patrick

[meyergru]

Actually I think @meyergru forgot we're already down to 199 days for public certificates and come next March the value will be 100 days, and 45 days in another year.

What I wanted to stress is the fact that you cannot use your own long-lived certificates unless you use a trick that OpnSense has not got under its sleeve (maybe that would be a good feature request): namely, you cannot set the start date of an issued certificate to "-startdate 20190630120000Z", which I always do with my own CA. This is because "old" certificates can last arbitrarily long. I tend to issue them for at least 10 years, which is way longer than 825, 397, 199, 100 or even 47 days - and 10 years definitely does not work when the "Not Before" date is not manipulated. I changed my CA script to use that "Not Before" date and never looked back because that eliminates the need to ever think about this again ("i.e. "have your cake and eat it").

On the other hand, it simply does not matter how long ACME certificates can last, just because OpnSense can (and will) also reissue them at the respective appropriate intervals, even when the duration changes in the future.

I updated the guide to make this even more obvious.

[Patrick M. Hausen]

I'm fine with 825 days and warnings from Uptime Kuma. Of course automation will take care of all the public ones.

I'm planning to get some beer and popcorn ready when our enterprise customers' IT departments finally notice the 47 day change. 😬 I don't understand why so many insist to send us their "official" certs for their web sites instead of switching on ACME which we include free of charge in our hosting platform in the form of Dehydrated.

[sopex]

Great guide, as always!