Hi Alexander, the log tells us that both times the handshake ends in the successful establishment of an IKE SA. Like you reported both match the policy 'clientA' instead of A and B:
> Jul 15 11:06:45 server iked[12701]: sa_state: VALID -> ESTABLISHED from > 5.6.7.8:4500 to 1.2.3.4:4500 policy 'clientA' > Jul 15 11:06:50 server iked[12701]: sa_state: VALID -> ESTABLISHED from > 5.6.7.8:1083 to 1.2.3.4:4500 policy 'clientA' The reason seems to be this: > Jul 15 11:06:45 server iked[12701]: ikev2_pld_id: id ASN1_DN//C=DE/ST=Lower > Saxony/L=Hanover/O=OpenBSD/OU=iked/CN=client1.example.com/emailAddress=r...@openbsd.org > length 165 > Jul 15 11:06:50 server iked[12701]: ikev2_pld_id: id ASN1_DN//C=DE/ST=Lower > Saxony/L=Hanover/O=OpenBSD/OU=iked/CN=client2.example.com/emailAddress=r...@openbsd.org > length 165 The iked server tries to match these IDs with the strings in the dstid configuration field, in your case: "client1.example.com" and "client1.example.com", which fails for obvious reasons. You could try the following: Set the dstid values to the full ASN1_DN strings: /C=DE/ST=Lower Saxony/L=Hanover/O=OpenBSD/OU=iked/CN=client1.example.com/emailAddress=r...@openbsd.org /C=DE/ST=Lower Saxony/L=Hanover/O=OpenBSD/OU=iked/CN=client2.example.com/emailAddress=r...@openbsd.org If this does not work (I'm not sure the format of the identity payloads is compatible) try setting the srcid explicitly to client1.example.com and client2.example.com with type FQDN in the client configurations (and leave the server dstid as it was before). Regards, Tobias
