Comment 11 for bug 1451091

Thanks for the example config.

The client will encode the identity as FQDN and the server is forced to encode it as keyid (the content will be the same but the type is different). So there won't be a match. Looking at the screenshot I'm not sure how to configure a FQDN in the pfSense GUI, perhaps "Distinguished name" even though the DN in FQDN stands for "domain name". Additionally, the identity in ipsec.secrets on the server is also encoded as FQDN as the prefix is missing (should probably be reported to pfSense). Also, rightid is missing on the server, so authentication will fail anyway as the server will default to the client's IP address, which won't match the client's leftid (omnicon-59000000).

Selecting the identity type could make sense, but the identities would have to be encoded properly (e.g. parse the configured string according to the type and binary encode it, then prefix it), otherwise the result will not be what the user intended (e.g. leftid=ipv4:192.168.0.1 is not the same thing as leftid=192.168.0.1 or leftid=ipv4:#c0a80001).