> Hello
>
> Last year (before about 3/27/2017 when "Add support for RFC4754
(ECDSA) and
> RFC7427 authentication" diff was committed to current), I had set up
and had
> been able to connect iOS devices (iphone/ipad) to OpenBSD's iked, and
have ikev2
> VPN's happen, almost as if by, magic.
>
> Authentication was accomplished using certificates signed by a local
authority
> and then distributed to the iOS devices.
>
> Since 3/27/17, this has not been working. I sent a couple of emails
about this
> last year (the initial one:
> https://marc.info/?l=openbsd-bugs&m=149706080419488&w=2).
>
> Over the last year, I have tried many things. Even though I don't
know anything
> about programming (or C), I tried making little changes to the iked
source, all
> without success. (Is that any surprise? No. I was amazed at times
that my
> changes even resulted in a program that would actually start up and run.)
>
> I have tried creating several different CA's and certificates, using
various
> different algorithms (ECDSA and RSA, with varying key lengths), all
without
> success. For example, I just tried creating a CA and certificates with
> ECDSA384/SHA2-384; I distribute those to the iOS device (which
supports them),
> but, iked will not accept them and create a tunnel.
>
> In iked.conf, if I don't explicitly state something like "ecdsa384"
as the
> authentication method (and, this requires having a local copy of the
public key
> on the openbsd machine), iked falls back to rfc7427 for
authentication, but it
> appears that iOS does not support this (yet?).
>
> I have been downgrading iked to a version before the 3/27/17 (every
time I
> update -current), and this still allows my old certificates to work.
But, that
> doesn't seem sustainable.
>
> I have no idea how to proceed?
>
> Has anyone been able to get -current (or at least, a snapshot after
3/27/17)
> version of iked to work with any iOS devices using certificates
successfully?
>
> If so, I would really appreciate some advice on how it can be done.
>
> Thanks
> Ted
I am not an expert and have not tried to connect an ios device, but I
noticed
from your other email, that your problem was *similar* to one I had.
From other email:
> In this case, there is an error, and the tunnel is CLOSED.
> ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
> ikev2_resp_recv: failed to send auth response
> sa_state: AUTH_REQUEST -> CLOSED from xxx.yyy.1.254:62164 to
xxx.yyy.1.20:4500
> policy 'ios2_vpn'
> Before learning how to go back in time, I found a suggestion that
placing an RSA
> public certificate on the local OBSD machine could help.
> So, I used:
> # openssl rsa -in private.key -pubout >
> /etc/iked/pubkeys/fqdn/ios.ikev2.myfqdn.co
I had a problem like this where the active peers (clients) would
complain about
not having a public key and show the above error as well. It seems from
the openssl command above that you
created a public key for the active peer, which is backwards from what
ended up
working for me. I created a public key based on the private key of the
passive
peer (server) and copied it to /etc/iked/pubkeys/ipv4/ on the active peers
(clients) and then I was able to connect.
> Jun 6 14:54:14 iPhone neagent(NetworkExtension)[824] <Error>:
Certificate
> at index 0 could not be created
> Jun 6 14:54:14 iPhone neagent(NetworkExtension)[824] <Error>:
Certificate
> authentication data could not be verified
This error from your iphone log is *similar* to the one I was recieveing
on my
openbsd clients.
So on whatever machine the CA is on, I did:
openssl rsa -in /etc/ssl/NAME_OF_CA/private/ip.of.passive.peer.key \
-pubout -out ip.of.passive.peer
... and then copied ip.of.passive.peer to /etc/iked/pubkeys/ipv4/ on the
*clients*
I am not sure where that would be on the iphone. Hope this helps, I am by no
means an expert, and if I am giving bad advice hopefully someone more
informed
will chime in.
I got this info from here:
https://www.going-flying.com/blog/mikrotik-openbsd-ikev2.html
It seems the person writing the article upgraded to 6.1 and things had
changed.
