iked problems with Apple clients in 7.1
I ran into problems with Apple clients failing to connect to iked after updating a machine to 7.1, introduced by https://github.com/openbsd/src/commit/e3f5cf2ee26929d75dc2df9e86d97c36b2a94268 spi=0xac3d46687441f957: recv IKE_SA_INIT req 0 peer rrr.rrr.rrr.rr:49436 local lll.ll.lll.lll:500, 308 bytes, policy 'default' spi=0xac3d46687441f957: send IKE_SA_INIT res 0 peer rrr.rrr.rrr.rr:49436 local lll.ll.lll.lll:500, 341 bytes spi=0xac3d46687441f957: recv IKE_AUTH req 1 peer rrr.rrr.rrr.rr:64892 local lll.ll.lll.lll:4500, 368 bytes, policy 'default' policy_test: localid mismatch spi=0xac3d46687441f957: ikev2_ike_auth_recv: no compatible policy found spi=0xac3d46687441f957: ikev2_send_auth_failed: authentication failed for spi=0xac3d46687441f957: send IKE_AUTH res 1 peer rrr.rrr.rrr.rr:64892 local lll.ll.lll.lll:4500, 80 bytes, NAT-T spi=0xac3d46687441f957: sa_free: authentication failed I don't have full details of config done on the other side nor any fruit-based phones to test from myself, did anyone already run into this and figure out a way around it? I'm currently running code backed out to "cvs up -D'2021/11/26 15:00'" as a workaround. My config looks like - set fragmentation ikev2 "default" passive esp from 0.0.0.0/0 to dynamic \ \ local lll.ll.lll.lll \ peer any \ \ ikesa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group modp2048 \ ikesa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \ \ childsa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group modp2048 \ childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \ \ childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 \ \ srcid "" \ lifetime 3h bytes 5G \ eap "mschap-v2" \ config address ttt.ttt.tt.ttt/26 \ config name-server lll.ll.lll.aa \ config name-server lll.ll.lll.bb \ tag "$name-$id" ikev2 "keysim" active tunnel esp from 0.0.0.0/0 to 100.70.76.0/22 \ local lll.ll.lll.lll peer kk.kkk.kkk.kkk \ ikesa auth hmac-sha2-256 enc aes-256 group modp3072 \ childsa auth hmac-sha2-256 enc aes-256 group modp3072 \ srcid lll.ll.lll.lll dstid kk.kkk.kkk.kkk \ lifetime 3h bytes 20G \ psk \ tag "keysim" include "/etc/iked.users" -
Re: iked problems with Apple clients in 7.1
On Fri, May 20, 2022 at 03:41:12PM +0100, Stuart Henderson wrote: > I ran into problems with Apple clients failing to connect to > iked after updating a machine to 7.1, introduced by > https://github.com/openbsd/src/commit/e3f5cf2ee26929d75dc2df9e86d97c36b2a94268 > > spi=0xac3d46687441f957: recv IKE_SA_INIT req 0 peer rrr.rrr.rrr.rr:49436 > local lll.ll.lll.lll:500, 308 bytes, policy 'default' > spi=0xac3d46687441f957: send IKE_SA_INIT res 0 peer rrr.rrr.rrr.rr:49436 > local lll.ll.lll.lll:500, 341 bytes > spi=0xac3d46687441f957: recv IKE_AUTH req 1 peer rrr.rrr.rrr.rr:64892 local > lll.ll.lll.lll:4500, 368 bytes, policy 'default' > policy_test: localid mismatch > spi=0xac3d46687441f957: ikev2_ike_auth_recv: no compatible policy found > spi=0xac3d46687441f957: ikev2_send_auth_failed: authentication failed for > spi=0xac3d46687441f957: send IKE_AUTH res 1 peer rrr.rrr.rrr.rr:64892 local > lll.ll.lll.lll:4500, 80 bytes, NAT-T > spi=0xac3d46687441f957: sa_free: authentication failed > > I don't have full details of config done on the other side nor any > fruit-based phones to test from myself, did anyone already run into this > and figure out a way around it? Hey Stuart, I haven't seen this before but I have a theory. Based on the commit you pointed out the problem is probably the `dstid kk.kkk.kkk.kkk` line which was ignored before this change. This should be easy to check without access to the other device if you enable verbose logging on your server and look for "ikev2_pld_id" above the error. I suspect that the ID sent by your apple peer might actually be a different one than kk.kkk.kkk.kkk. Another thing you could try is just removing the dstid part and see if that works. > > I'm currently running code backed out to "cvs up -D'2021/11/26 15:00'" > as a workaround. My config looks like > > - > set fragmentation > > ikev2 "default" passive esp from 0.0.0.0/0 to dynamic \ > \ > local lll.ll.lll.lll \ > peer any \ > \ > ikesa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group > modp2048 \ > ikesa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group > curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \ > \ > childsa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group > modp2048 \ > childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group > curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \ > \ > childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 \ > \ > srcid "" \ > lifetime 3h bytes 5G \ > eap "mschap-v2" \ > config address ttt.ttt.tt.ttt/26 \ > config name-server lll.ll.lll.aa \ > config name-server lll.ll.lll.bb \ > tag "$name-$id" > > ikev2 "keysim" active tunnel esp from 0.0.0.0/0 to 100.70.76.0/22 \ > local lll.ll.lll.lll peer kk.kkk.kkk.kkk \ > ikesa auth hmac-sha2-256 enc aes-256 group modp3072 \ > childsa auth hmac-sha2-256 enc aes-256 group modp3072 \ > srcid lll.ll.lll.lll dstid kk.kkk.kkk.kkk \ > lifetime 3h bytes 20G \ > psk \ > tag "keysim" > > include "/etc/iked.users" > - >
Re: iked problems with Apple clients in 7.1
On 2022/05/21 13:44, Tobias Heider wrote: > On Fri, May 20, 2022 at 03:41:12PM +0100, Stuart Henderson wrote: > > I ran into problems with Apple clients failing to connect to > > iked after updating a machine to 7.1, introduced by > > https://github.com/openbsd/src/commit/e3f5cf2ee26929d75dc2df9e86d97c36b2a94268 > > > > spi=0xac3d46687441f957: recv IKE_SA_INIT req 0 peer rrr.rrr.rrr.rr:49436 > > local lll.ll.lll.lll:500, 308 bytes, policy 'default' > > spi=0xac3d46687441f957: send IKE_SA_INIT res 0 peer rrr.rrr.rrr.rr:49436 > > local lll.ll.lll.lll:500, 341 bytes > > spi=0xac3d46687441f957: recv IKE_AUTH req 1 peer rrr.rrr.rrr.rr:64892 local > > lll.ll.lll.lll:4500, 368 bytes, policy 'default' > > policy_test: localid mismatch > > spi=0xac3d46687441f957: ikev2_ike_auth_recv: no compatible policy found > > spi=0xac3d46687441f957: ikev2_send_auth_failed: authentication failed for > > spi=0xac3d46687441f957: send IKE_AUTH res 1 peer rrr.rrr.rrr.rr:64892 local > > lll.ll.lll.lll:4500, 80 bytes, NAT-T > > spi=0xac3d46687441f957: sa_free: authentication failed > > > > I don't have full details of config done on the other side nor any > > fruit-based phones to test from myself, did anyone already run into this > > and figure out a way around it? > > Hey Stuart, > > I haven't seen this before but I have a theory. > Based on the commit you pointed out the problem is probably the > `dstid kk.kkk.kkk.kkk` line which was ignored before this change. > > This should be easy to check without access to the other device if > you enable verbose logging on your server and look for "ikev2_pld_id" > above the error. I suspect that the ID sent by your apple peer might > actually be a different one than kk.kkk.kkk.kkk. > > Another thing you could try is just removing the dstid part and see > if that works. Oh sorry I wasn't clear about which one the apple was using - the one with "kk.kkk.kkk.kkk" is a lan-to-lan configuration (fixed IP on both endpoints) - the apple is expected to be using the first "from 0.0.0.0/0 to dynamic" one which doesn't have any dstid set, and that's the only one where the IP matches. > > > > I'm currently running code backed out to "cvs up -D'2021/11/26 15:00'" > > as a workaround. My config looks like > > > > - > > set fragmentation > > > > ikev2 "default" passive esp from 0.0.0.0/0 to dynamic \ > > \ > > local lll.ll.lll.lll \ > > peer any \ > > \ > > ikesa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group > > modp2048 \ > > ikesa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group > > curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \ > > \ > > childsa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group > > modp2048 \ > > childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group > > curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \ > > \ > > childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 \ > > \ > > srcid "" \ > > lifetime 3h bytes 5G \ > > eap "mschap-v2" \ > > config address ttt.ttt.tt.ttt/26 \ > > config name-server lll.ll.lll.aa \ > > config name-server lll.ll.lll.bb \ > > tag "$name-$id" > > > > ikev2 "keysim" active tunnel esp from 0.0.0.0/0 to 100.70.76.0/22 \ > > local lll.ll.lll.lll peer kk.kkk.kkk.kkk \ > > ikesa auth hmac-sha2-256 enc aes-256 group modp3072 \ > > childsa auth hmac-sha2-256 enc aes-256 group modp3072 \ > > srcid lll.ll.lll.lll dstid kk.kkk.kkk.kkk \ > > lifetime 3h bytes 20G \ > > psk \ > > tag "keysim" > > > > include "/etc/iked.users" > > - > > >
Re: iked problems with Apple clients in 7.1
On Sat, May 21, 2022 at 12:51:19PM +0100, Stuart Henderson wrote: > On 2022/05/21 13:44, Tobias Heider wrote: > > On Fri, May 20, 2022 at 03:41:12PM +0100, Stuart Henderson wrote: > > > I ran into problems with Apple clients failing to connect to > > > iked after updating a machine to 7.1, introduced by > > > https://github.com/openbsd/src/commit/e3f5cf2ee26929d75dc2df9e86d97c36b2a94268 > > > > > > spi=0xac3d46687441f957: recv IKE_SA_INIT req 0 peer rrr.rrr.rrr.rr:49436 > > > local lll.ll.lll.lll:500, 308 bytes, policy 'default' > > > spi=0xac3d46687441f957: send IKE_SA_INIT res 0 peer rrr.rrr.rrr.rr:49436 > > > local lll.ll.lll.lll:500, 341 bytes > > > spi=0xac3d46687441f957: recv IKE_AUTH req 1 peer rrr.rrr.rrr.rr:64892 > > > local lll.ll.lll.lll:4500, 368 bytes, policy 'default' > > > policy_test: localid mismatch > > > spi=0xac3d46687441f957: ikev2_ike_auth_recv: no compatible policy found > > > spi=0xac3d46687441f957: ikev2_send_auth_failed: authentication failed for > > > spi=0xac3d46687441f957: send IKE_AUTH res 1 peer rrr.rrr.rrr.rr:64892 > > > local lll.ll.lll.lll:4500, 80 bytes, NAT-T > > > spi=0xac3d46687441f957: sa_free: authentication failed > > > > > > I don't have full details of config done on the other side nor any > > > fruit-based phones to test from myself, did anyone already run into this > > > and figure out a way around it? > > > > Hey Stuart, > > > > I haven't seen this before but I have a theory. > > Based on the commit you pointed out the problem is probably the > > `dstid kk.kkk.kkk.kkk` line which was ignored before this change. > > > > This should be easy to check without access to the other device if > > you enable verbose logging on your server and look for "ikev2_pld_id" > > above the error. I suspect that the ID sent by your apple peer might > > actually be a different one than kk.kkk.kkk.kkk. > > > > Another thing you could try is just removing the dstid part and see > > if that works. > > Oh sorry I wasn't clear about which one the apple was using - the one with > "kk.kkk.kkk.kkk" is a lan-to-lan configuration (fixed IP on both endpoints) - > the apple is expected to be using the first "from 0.0.0.0/0 to dynamic" one > which doesn't have any dstid set, and that's the only one where the IP > matches. Oh, makes sense. I think it may still be related to the IDs, so checking if ikev2_pld_id matches what you expect for srcid might be a good start. Maybe the apple client is sending something different than "" in their dstid. If this doesn't help we could try adding a few printfs to see why the policy fails to match. > > > > > > > > I'm currently running code backed out to "cvs up -D'2021/11/26 15:00'" > > > as a workaround. My config looks like > > > > > > - > > > set fragmentation > > > > > > ikev2 "default" passive esp from 0.0.0.0/0 to dynamic \ > > > \ > > > local lll.ll.lll.lll \ > > > peer any \ > > > \ > > > ikesa enc aes-128-gcm group curve25519 group ecp521 group ecp256 group > > > modp2048 \ > > > ikesa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group > > > curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \ > > > \ > > > childsa enc aes-128-gcm group curve25519 group ecp521 group ecp256 > > > group modp2048 \ > > > childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 group > > > curve25519 group ecp521 group ecp256 group modp2048 group modp1024 \ > > > \ > > > childsa enc aes-128 enc aes-256 auth hmac-sha2-256 auth hmac-sha1 \ > > > \ > > > srcid "" \ > > > lifetime 3h bytes 5G \ > > > eap "mschap-v2" \ > > > config address ttt.ttt.tt.ttt/26 \ > > > config name-server lll.ll.lll.aa \ > > > config name-server lll.ll.lll.bb \ > > > tag "$name-$id" > > > > > > ikev2 "keysim" active tunnel esp from 0.0.0.0/0 to 100.70.76.0/22 \ > > > local lll.ll.lll.lll peer kk.kkk.kkk.kkk \ > > > ikesa auth hmac-sha2-256 enc aes-256 group modp3072 \ > > > childsa auth hmac-sha2-256 enc aes-256 group modp3072 \ > > > srcid lll.ll.lll.lll dstid kk.kkk.kkk.kkk \ > > > lifetime 3h bytes 20G \ > > > psk \ > > > tag "keysim" > > > > > > include "/etc/iked.users" > > > - > > > > > >
Re: iked problems with Apple clients in 7.1
On 2022/05/21 17:04, Tobias Heider wrote: > > Oh, makes sense. I think it may still be related to the IDs, so checking if > ikev2_pld_id matches what you expect for srcid might be a good start. > Maybe the apple client is sending something different than > "" > in their dstid. I'll try to find what they've got it set to in the week, though if they followed my setup docs it will match what I've set in iked.conf. iked.conf(5) just says "will be used by iked(8) as the identity of the local peer" so it's a surprise that a mismatch would cause iked to disallow the connection, seems like maybe a fallback would make sense if there's no explicit match? If anyone else reading sees this after updating to 7.1 and has direct access to an iPhone, any chance could you help us debug please? > If this doesn't help we could try adding a few printfs to see why the policy > fails to match.
Re: iked problems with Apple clients in 7.1
On Sun, May 22, 2022 at 01:07:42PM +0100, Stuart Henderson wrote: > On 2022/05/21 17:04, Tobias Heider wrote: > > > > Oh, makes sense. I think it may still be related to the IDs, so checking if > > ikev2_pld_id matches what you expect for srcid might be a good start. > > Maybe the apple client is sending something different than > > "" > > in their dstid. > > I'll try to find what they've got it set to in the week, though if they > followed my setup docs it will match what I've set in iked.conf. > > iked.conf(5) just says "will be used by iked(8) as the identity of the > local peer" so it's a surprise that a mismatch would cause iked to > disallow the connection, seems like maybe a fallback would make sense if > there's no explicit match? > > If anyone else reading sees this after updating to 7.1 and has direct > access to an iPhone, any chance could you help us debug please? > > > If this doesn't help we could try adding a few printfs to see why the policy > > fails to match. > Stuart I have an iPhone 13. I use it very little so am not a guru with it, nor am I familiar with what has happened in this thread. If you give me the required directions/instructions I will do what I can to help. I am running 7.1-current (GENERIC.MP) #540 on a laptop at present and it can be updated if needed whenever required, preferrably from a known real mirror site. Regards -- aer
Re: iked problems with Apple clients in 7.1
On 2022/05/21 17:04, Tobias Heider wrote:
> On Sat, May 21, 2022 at 12:51:19PM +0100, Stuart Henderson wrote:
> > On 2022/05/21 13:44, Tobias Heider wrote:
> > > On Fri, May 20, 2022 at 03:41:12PM +0100, Stuart Henderson wrote:
> > > > I ran into problems with Apple clients failing to connect to
> > > > iked after updating a machine to 7.1, introduced by
> > > > https://github.com/openbsd/src/commit/e3f5cf2ee26929d75dc2df9e86d97c36b2a94268
> > > >
> > > > spi=0xac3d46687441f957: recv IKE_SA_INIT req 0 peer
> > > > rrr.rrr.rrr.rr:49436 local lll.ll.lll.lll:500, 308 bytes, policy
> > > > 'default'
> > > > spi=0xac3d46687441f957: send IKE_SA_INIT res 0 peer
> > > > rrr.rrr.rrr.rr:49436 local lll.ll.lll.lll:500, 341 bytes
> > > > spi=0xac3d46687441f957: recv IKE_AUTH req 1 peer rrr.rrr.rrr.rr:64892
> > > > local lll.ll.lll.lll:4500, 368 bytes, policy 'default'
> > > > policy_test: localid mismatch
> > > > spi=0xac3d46687441f957: ikev2_ike_auth_recv: no compatible policy found
> > > > spi=0xac3d46687441f957: ikev2_send_auth_failed: authentication failed
> > > > for
> > > > spi=0xac3d46687441f957: send IKE_AUTH res 1 peer rrr.rrr.rrr.rr:64892
> > > > local lll.ll.lll.lll:4500, 80 bytes, NAT-T
> > > > spi=0xac3d46687441f957: sa_free: authentication failed
> > > >
> > > > I don't have full details of config done on the other side nor any
> > > > fruit-based phones to test from myself, did anyone already run into this
> > > > and figure out a way around it?
> > >
> > > Hey Stuart,
> > >
> > > I haven't seen this before but I have a theory.
> > > Based on the commit you pointed out the problem is probably the
> > > `dstid kk.kkk.kkk.kkk` line which was ignored before this change.
> > >
> > > This should be easy to check without access to the other device if
> > > you enable verbose logging on your server and look for "ikev2_pld_id"
> > > above the error. I suspect that the ID sent by your apple peer might
> > > actually be a different one than kk.kkk.kkk.kkk.
> > >
> > > Another thing you could try is just removing the dstid part and see
> > > if that works.
> >
> > Oh sorry I wasn't clear about which one the apple was using - the one with
> > "kk.kkk.kkk.kkk" is a lan-to-lan configuration (fixed IP on both endpoints)
> > -
> > the apple is expected to be using the first "from 0.0.0.0/0 to dynamic" one
> > which doesn't have any dstid set, and that's the only one where the IP
> > matches.
>
> Oh, makes sense. I think it may still be related to the IDs, so checking if
> ikev2_pld_id matches what you expect for srcid might be a good start.
> Maybe the apple client is sending something different than
> ""
> in their dstid.
I was able to get someone to do a couple of tests (after accidentally updating
that machine and running into the problem again..) - debug log from iked shows
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_payloads: decrypted payload
IDi nextpayload NOTIFY critical 0x00 length 28
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_id: id
FQDN/vpn2.xxx length 24
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_payloads: decrypted payload
NOTIFY nextpayload IDr critical 0x00 length 8
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_notify: protoid NONE
spisize 0 type INITIAL_CONTACT
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_payloads: decrypted payload
IDr nextpayload CP critical 0x00 length 12
2022-09-21T09:10:44.370Z vpn2 iked[9682]: ikev2_pld_id: id FQDN/user length 8
...
2022-09-21T09:10:44.371Z vpn2 iked[9682]: ikev2_resp_recv: NAT-T message
received, updated SA
2022-09-21T09:10:44.371Z vpn2 iked[9682]: sa_stateok: SA_INIT flags 0x,
require 0x
2022-09-21T09:10:44.371Z vpn2 iked[9682]: spi=0xbb3b1aa559598982: sa_state:
SA_INIT -> EAP
2022-09-21T09:10:44.371Z vpn2 iked[9682]: policy_lookup: peerid
'vpn2.xxx'
2022-09-21T09:10:44.371Z vpn2 iked[9682]: policy_lookup: localid 'user'
2022-09-21T09:10:44.372Z vpn2 iked[9682]: policy_test: localid mismatch
2022-09-21T09:10:44.372Z vpn2 iked[9682]: spi=0xbb3b1aa559598982:
ikev2_ike_auth_recv: no compatible policy found
2022-09-21T09:10:44.372Z vpn2 iked[9682]: spi=0xbb3b1aa559598982:
ikev2_send_auth_failed: authentication failed for
Which, given that the apple device is initiator, suggests that they're
sending the IDs the wrong way round. I don't know whether that's a
bug Apple-side or a config issue, either way it's going to be hard
to fix as I don't have access to the client devices (or any similar
device myself to tell them what to change).
Reading policy.c:policy_lookup() ...
125 /* Try to find a matching policy for this message */
126 if ((msg->msg_policy = policy_test(env, &pol)) != NULL) {
127 log_debug("%s: setting policy '%s'", __func__,
128 msg->msg_policy->pol_name);
129 return (0);
130 }
131
132 /* No matching policy found, try the default */
133
