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 "xxxxxxxxxxxxxxxxxxxx" \ > > 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 xxxxxxxxxxxxxxxx \ > > tag "keysim" > > > > include "/etc/iked.users" > > ----- > > >
