One-click IPsec VPNs for Apple iOS

Are you referring to the Host-to-Net Endpoint: field?

If yes, then the field should be the name you obtained from ddns.net.

So for you: ipfire-test.ddns.net

Actually no. I’m thinking more in general how you name your iPfire installation.

I think the first part can only be done by SSH.

So it’s what’s been displayed here:

The Hostname in GUI Setting > Display should not match your FQDN. It has nothing to do with IPsec.

Just leave that hostname something simple like ipfire.

For now it is better to leave things simple until you get farther along…

OK, anyway I assume there is a minor bug in this release, and it’s being worked on, so eventually IPSec will work using road warrior with iOS.

I am not aware of any bugs in the implementation.

Could we try to organise this thread and collect any error messages from /var/log/messages if there are any? I just set up a connection and it worked straight away for me.

And just to add some more confusion.

Should I use the iPfire host name?


Hi Jon,

I believe that the following is meant.

The first bullet is saying that you need to have a FQDN for your IPFire system either as a fixed IP with your own domain name or with an IP from an ISP together with a domain name from a DDNS supplier.

The second bullet then says that the FQDN from the first bullet must be used for the subjectAlternativeName in the CA certificate that is being generated for your IPsec server

Hope this helps

Your explanation is correct. But, It’s not working. (At least not for me)

One year noip is now 14.95 by using code VIP10.

Andreas @r1200cl -

Are you using an iPad Wi-Fi or an iPad with Cellular (LTE) to connect to IPsec?

So for me I am connected like this:
iPhoneSE via LTE → Internet → IPFire box

I am thinking you may be connected like this:
iPad Wi-Fi → wi-fi → IPFire box

And that will not work…

Michael,

The issue for me was Wiki-ish. no bugs found!

I am using iOS 14.6. The Diffie Hellman Group (DH group) was updated from MODP-1024 to MODP-2048 after iOS 14.2. So MODP-1024 did not work for me.
See Apple-VPN.IKEv2.ChildSecurityAssociationParameters.

This is the error in the message log:
https://community.ipfire.org/t/one-click-ipsec-vpns-for-apple-ios/5847/26?u=jon

What parameters did you use that worked?

This is the only one that works for me:

iOS 14 (default values): AES-256 (GCM or CBC) / SHA2-256 / MODP-2048

That is a very valuable link. Should we add that? I have seen you have already added MODP-2048 which is very helpful.

Never mind. You have already been faster than me :slight_smile:

You are just bouncing around guessing at things. Start with the information in /etc/messages and then troubleshoot from there. The “No Proposal Chosen” error or other errors surrounding proposals have to do with the encryption ciphers selected. Uncheck the box to only use selected proposals at first, so StrongSwan will not insist that the far side match with what you have selected in the Advanced page. Then, once you have a working connection, you can see what proposals worked in /etc/messages and then enable those items in the advanced page and re-select the checkbox. Leaving the checkbox deselected in the long run is a bad idea, as it can result in low quality encryption if the far side proposes it.

1 Like

Hi Tom,

Thank you! I’m not sure I understand the above but let me give things a try before I ask too many questions!

In the beginning I was “just bouncing around guessing at things” since nothing made sense. One of the messages that was driving me insane is related to the %any.

Jul 22 22:42:47 ipfire charon: 10[CFG] selected peer config 'iPhoneSE' 
Jul 22 22:42:47 ipfire charon: 10[IKE] no shared key found for '%any' - '101.185.xxx.xxx' 
Jul 22 22:42:47 ipfire charon: 10[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding 
Jul 22 22:42:47 ipfire charon: 10[IKE] peer supports MOBIKE 
Jul 22 22:42:47 ipfire charon: 10[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ] 

-and-

Jul 26 21:44:45 ipfire charon: 10[CFG] received stroke: initiate 'iPhoneSE' 
Jul 26 21:44:45 ipfire charon: 10[IKE] unable to resolve %any, initiate aborted 
Jul 26 21:44:54 ipfire charon: 11[NET] received packet: from <internetIP>[12720] to <iphoneIP>[4500] (128 bytes) 

  • What is %any in the above message log snippets?
    • is this an error? Or just info?
  • Is this related to Remote host/IP?
    • my Remote host/IP field is blank.

New / separate issue:

Is the IPsec x509 shared with OpenVPN x509? Or is it two different things?

I ask because my OpenVPN no longer works and I either broke something in the OpenVPN side -OR- I deleted its x509.

So, if I click the IPsec Remove x509 will it destroy the OpenVPN x509?

@jon: This is better.
For any tunnel you configure, the local and remote IP addresses need to be defined. For a Net-to-Net tunnel, you specify the actual IP address for the remote site. However, since a RoadWarrior can be anywhere, you don’t specify a specific address, you specify “%any”, meaning any remote IP can connect to this configuration. This is done automatically when you create a Host-to-Net tunnel, you don’t need to type it anywhere (the remote IP box is actually disabled for that reason, IIRC).

The first log snippet seems to be the results of initiating the tunnel from the iPhone.

  • The “selected peer config ‘iPhoneSE’” message indicates that the system is picking the correct configuration. Now you need to make sure that the configuration is, well, configured properly.
  • “no shared key found” seems to indicate that you have a PSK configuration selected, not a certificate configuration. What’s worse, it indicates that the system cannot find that PSK in the /etc/ipsec.secrets file, perhaps. I vaguely remember an issue where one had to either restart strongswan or force strongswan to read new PSKs when creating a new tunnel, but I think that was fixed 5 or more years ago. I suspect this is more of a symptom of your making 1,000 changes trying to make this work. It wouldn’t hurt to reboot IPFire, just in case, but maybe starting from scratch would be an even better solution. It depends on how many other things you have configured on this machine.
  • The failure to find a PSK results in the final “AUTH_FAILED” message, as the system can’t successfully authenticate against a PSK it can’t find.

The second log snippet looks to me like you initiated the tunnel from the IPFire device, either as a side-effect of a configuration change (which shouldn’t really happen), or by issuing the command “ipsec up iPhoneSE” on the command line. What the second snippet is saying is that Strongswan on the IPFire box has received a command to bring up the “iPhoneSE” tunnel, and it immediately fails because the tunnel is configured to allow any host to connect, so it has no way of knowing what host to contact in order to bring the tunnel up. This is the very nature of a RoadWarrior tunnel, and the only odd thing is that IPFire was asked to bring that tunnel up. Perhaps it is a side effect of loading the tunnel from the configuration?

I’m pretty certain the clicking “Remove x.509” on the IPSec page will break any OpenVPN connections, but I’m no expert on OpenVPN, as it always seemed far too complex to me.

So let’s try to understand where I’m doing wrong.

I’m using

Which shows my DNS is OK.

Also I like to showmain page with my ISP info.


I’m showing this, as host name isn’t same as my DNS host name.
In addition my iPfire installation has a different host name.

So the term host name can be a bit confusing.

However FQDN ought to be clear. It can be your host name, but it can also be something else. In my case I expect “iPfire-test.ddns.net” to be my only FQDN.

Next, there is 3 steps to be done:

  1. Create a global setting
  2. Generate a certificate
  3. Create a connection

So, step one in my case look like this.


I’m not sure about the RoadWarrior setting, as the subnet isn’t part of my subnet locally. So 192.168.20.0/24 may working and may not. I don’t know. The zero before 24 is the number I rather change to 1, in order to comply with my local network. However my understanding from previous answers in this tread is it doesn’t matter, as this is just to assign an ip to the remote host. (My iPad).

Next is certificate:


Appart from the first required filed which can be anything, the next two required fields has been assigned the FQDN. Is this correct ?
It’s very clear to me that the host name has to equal the FQDN.
The explanation under Subject Alternative Name is very confusing to me. It’s a requirement, but it says IF you have (then conditions), you CAN implement them here, like if I don’t have, leave blank. Also the choices is so many.
This must be better explained in Wiki.

Last is connection.
Wiki is here:

And it’s not helpful at all. And latest editing did it even worse.

Adding name is easy. Call it what ever you like.
Local and Remote ID isn’t required. So I leave blank. But I think it’s not correct, as somewhere else the wiki says it’s a requirement and I don’t understand those requirements transferred to my example.

Local ID must be set to the IPFire’s FQDN prefixed by an “@” sign. Remote ID must be the system’s hostname prefixed by an “@” sign and the hostname must also be added to the certificate as “Subject Alternative Name” prefixed with “DNS:”.

I will test with FQDN on local ID after. @ipfire-test.ddns.net ought to be the correct setting. My iPfire host name I’m not 100% sure about. I do expect my iPfire host name to comply with what I actually have named my installation, but my understanding from @jon is that I’m wrong in this case.
As suggest before, it ought to to be equal to what’s visible using this setting:


But my understanding is I’m wrong.

Local subnet may be 0.0.0.0/0, but can also be something else. My picture shows what iPfire suggested. I don’t to my knowledge have this subnet.
192.168.20.0
I have
192.168.20.1
DNS servers (in plural?) is hopefully my local 192.168.20.1. I don’t know.

Further there is a authentication to be filled in.
I assume name and organization name can be anything. And those are the two required fields (apart from PW).

I think however SubjectAlternativeName(subjectAltName=email:,URI:,DNS:,RID:) must be filled in.
I’m confused what to fill in. I think DNS:”your FQDN”. That will at least comply with what I did when using same field (well same name) in creating the certificate.
It was said before to equal the remote ID, but that field is now blank.
@ms says it’s working for him. But can you either show what’s working or tell me what I’m doing wrong ?

I’m now been taking to the advanced section.
Here the wiki has been updated, but it’s unclear to me if the suggested choices is the only one to select, or of I can add several more.
I’m using lates iOS 14.7
First question is if IKE and ESP settings shall be equal.
Next, the wiki doesn’t say which of possible 3 drop down selections to edit. And what is written in wiki isn’t shown at all as an option.
But one can guess.

  • iOS 14: AES-GCM-256-128 / SHA2-256 / MODP-2048

Is probably here under encryption:

So question is, should I remove all default selections, and only select the 3 wiki says ?
I’m trying this for now.

So it’s looking like this and I’m ready for import to my iPad.

But it’s not working. So where to start and make corrections ?

Edit:
There is one error here for sure.
“ The hostname in the certificate has to match for MacOS and iOS to accept the certificate”

But I don’t fully understand that sentence.
We have host certificate and root certificate and then whatever shall be matched in iOS.

I’m sitting local at home and I’m doing everything on my iPad with Cellular.
But when testing IPSec, I’m switching of WiFi.

I can’t use WiFi to connect to IPSec. That’s impossible of cause.
Unless I was sitting in another WiFi than my home and at home is also where my iPfire installation is of cause.

1 Like

Hi Jon,

No it will not. They are separate certificate structures. See following post from @pmueller

https://community.ipfire.org/t/ipsec-remove-x509-what-it-affects/5771/2

1 Like

Is this an error ?