Hello Tobias,
> A MAC address is 48 bits, so the 32 bits after the first two bytes > are taken from the 64-bit SipHash-2-4 value (just by casting to an > uint32_t) which is then run through htonl() and copied to the address > buffer. To calculate the value the 128-bit key > 0x000102030405060708090a0b0c0d0e0f is used. Ahhh. I missed that `id` was uint32_t. That clears up my confusion. Thanks! > If you use FQDNs as client identities they will be sent in a hostname > option (12) in the DHCP request, which you might be able to use > directly. Ok, that sounds like a better solution. However, I am having trouble making it work. I put a lot of detail into my message below to provide all the context I could, but the crux of my question now is this: can I configure the strongSwan server to force all clients to use an FQDN as their identifier, as you suggest? Or alternatively, can I force this by changing the way I generate certificates? Different clients send different identifiers ============================================ It seems that different clients send different things as identifiers: - macOS and iOS appear to send the bare Common Name from their certificate. For example, if the cert CN is macosclient.example.com a conn section with rightid=macosclient.example.com will match when the client attempts to connect. - Windows appears to send a DER-encoded X.509 Common Name object For example, if the cert CN is windowsclient.example.com, it sends: 30:24:31:22:30:20:06:03:55:04:03:0c:19:77:69:6e:64:6f:77:73:63: 6c:69:65:6e:74:2e:65:78:61:6d:70:6c:65:2e:63:6f:6d ... and that is matched by a conn section like rightid="/CN=windowsclient.example.com" - strongSwan (clients) are configurable. They appear to send the same thing that Windows sends by default, but can be configured to work the same as macOS, and even more ways besides, depending on what they have set as their 'leftid' First attempt: rightid=%client.example.com ========================================== I found some documentation here: <https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection> > Since 5.0.1 rightid for IKEv2 connections optionally takes a % as > prefix in front of the identity. If given it prevents the daemon from > sending IDr in its IKE_AUTH request and will allow it to verify the > configured identity against the subject and subjectAltNames contained > in the responder's certificate (otherwise, it is only compared with > the IDr returned by the responder). The IDr sent by the initiator > might otherwise prevent the responder from finding a config if it has > configured a different value for leftid. However, I wasn’t able to make that work the way I expected. I initially read this to mean that it would pluck the FQDN out of the cert that the client sends and use that as an identity, but that doesn't appear to be the correct reading. I put two conn sections in my ipsec.conf: conn macosclient-ikev2-pubkey rightid=%macosclient.example.com auto=add conn windowsclient-ikev2-pubkey rightid=%windowsclient.example.com auto=add (This isn’t ideal, because it requires a separate conn section for each user. Is there a way to avoid that?) With that configuration, the macOS client can connect just fine, but the Windows client cannot. (Note that the certificates were generated the same way, but of course with different hostnames.) Am I misreading the documentation? Is there some way to work around this for built-in IPSEC clients, like on Windows, which don’t appear to let me configure what is sent as the identifier? Further exploration: two conn sections per user =============================================== As I mentioned above, I found that Windows clients will connect if the rightid is something like rightid="/CN=windowsclient.example.com" However, the biggest problem with this is that I don’t know the operating system that my users will be on in advance. I provide VPN profiles for macOS and iOS (as .mobileconfig files), Windows (as a Powershell script), and Linux (as strongSwan configuration files); my users install whatever is appropriate for their operating system. That means that I’d need to have two conn sections for each user. conn USER-macos-ikev2-pubkey rightid=%user.example.com auto=add conn USER-windows-ikev2-pubkey rightid="/CN=%user.example.com" auto=add That’s not ideal, but I could make it work if I have to. Is there a better way? Open questions ============== A recap of my questions, since this got pretty long: 1. Can I configure the strongSwan server to force the clients to send the FQDNs as identities? 2. Alternatively, can I generate certificates differently to force the clients to send the FQDNs as identities? 3. Am I misreading the documentation about rightid=%fqdn? If so, what is it intended to do? 4. Can I avoid using two conn sections for each user somehow? 5. Even better, can I use a single conn section to match all users, no matter their operating system, and enforce that they send their client identifier to the DHCP server the same way? I don't think I said this before, but I am on Ubuntu, and my ipsec version is: Linux strongSwan U5.3.5/K4.4.0-1054-aws Thank you again very much for any help. - Micah