Noel, thanks for the very thorough response, much appreciated. I have to admit,
I should have known how that connection 'id' looking logic would work. I was
mistakenly thinking that if I told the server that the id was a DNS value, that
it will pull the DNS info from the Subject Alt Name in the client cert,
regardless of what the client supplied as the IDi value. You confirmed that the
problem was that the client (by default) was sending in the cert DN as the IDi
so there is no way that the server was doing to find a match on the id DNS
connection profile.
I updated the swanctl.conf file on the client to specify local.id as DNS:....
and the connection works fine now. That's the path we'll be taking. The only
other thing we were trying to was to see if we could "stack" multiple values in
the id stmt on the server rather than specify two separate connection profiles
for similar client tunnels. Appears as though only one id value is allowed per
connection stanza. That's ok, we can make it work with multiple connection
stanzas.
Thx again for the great response!
Dave Finley
df1...@att.com
(630) 719-4391 (desk)
(630) 740-5198 (mobile)
-----Original Message-----
From: Noel Kuntze <noel.kuntze@thermi.consulting>
Sent: Wednesday, June 02, 2021 4:24 PM
To: FINLEY, DAVID BRIAN <df1...@att.com>; Users@lists.strongswan.org
Subject: Re: [strongSwan] FW: defining a connection profile using DNS name in
the cert's alt subject name cert field
Hello Dave,
Thank you for your persistence.
The error in your config is the following:
In your server config ikev2-conn-eNB-test-altname :
You implicitely configure the local identity here:
local-1 {
auth = pubkey
certs = gateway.crt
}
It defaults to the DN of gateway.crt
Then you explicitely define the required remote ID here:
remote-1 {
auth = pubkey
id = DNS:zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
}
Up to now, that's all fine.
The formulated requirement is:
- both use pubkey auth
- local identity is the DN of gateway.crt
- remote identity has to be of type DNS and value
zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
- remote certificate has to be signed by any valid and loaded CA
Now the client config ikev2-pubkey:
remote_addrs = 2001:1890:111b:1c03::2 # tunnel addr for C1/D1
local {
auth = pubkey
certs = zakr3dsegw51.crt
}
remote {
auth = pubkey
}
- both use pubkey auth
- remote ID has to be 2001:1890:111b:1c03::2
- local ID is DN of zakr3dsegw51.
- remote certificate has to be signed by any valid and loaded CA
That's the `pki --print`output of zakr3dsegw51:
subject: "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
issuer: "C=US, ST=Illinois, O=AT&T FSG Services, Inc., OU=Network Cloud
and Infrastructure, CN=FSG CA Signing Certificate, E=df1...@att.com"
validity: not before Mar 24 19:40:28 2021, ok
not after Mar 23 19:40:28 2026, ok (expires in 1754 days)
serial: a4:ad:fc:e0:19:40:b6:62:78:58:3b:7e:74:d4:2a:57
altNames: zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
flags: serverAuth clientAuth
authkeyId: b9:19:aa:84:72:ff:c5:c8:a3:5e:05:46:ff:f5:15:3a:63:d4:9e:d0
subjkeyId: 36:ea:bd:ec:7f:da:4e:5c:33:6b:cd:dd:85:72:d4:f2:e8:d9:2f:51
pubkey: RSA 2048 bits
keyid: e6:4c:d3:b6:c7:e5:08:1d:f1:ad:77:04:d1:c5:4e:49:42:61:84:1e
subjkey: 36:ea:bd:ec:7f:da:4e:5c:33:6b:cd:dd:85:72:d4:f2:e8:d9:2f:51
Valid IDs:
- DNS type, value: zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
- DN type, value: "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
In the log we see the following:
[...]
Mon, 2021-05-10, 10:12:41 07[CFG] vici client 4 requests: load-conn
Mon, 2021-05-10, 10:12:41 07[CFG] conn ikev2-conn-eNB-test-altname:
Mon, 2021-05-10, 10:12:41 07[CFG] child ikev2-conn-eNB-test-altname:
[...]
Mon, 2021-05-10, 10:12:41 07[CFG] id not specified, defaulting to cert
subject 'C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org'
[...]
Mon, 2021-05-10, 10:12:41 07[CFG] local:
Mon, 2021-05-10, 10:12:41 07[CFG] id = C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org
Mon, 2021-05-10, 10:12:41 07[CFG] class = public key
Mon, 2021-05-10, 10:12:41 07[CFG] remote:
Mon, 2021-05-10, 10:12:41 07[CFG] id =
zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
Mon, 2021-05-10, 10:12:41 07[CFG] class = public key
Mon, 2021-05-10, 10:12:41 07[CFG] updated vici connection:
ikev2-conn-eNB-test-altname
[...]
That means your actually loaded config is this on the server side:
local-1 {
auth = pubkey
certs = gateway.crt
id = "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org"
}
remote-1 {
auth = pubkey
id = DNS:zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
}
and on the client side it is this:
local {
auth = pubkey
certs = zakr3dsegw51.crt
id = "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
}
remote {
auth = pubkey
id = 2001:1890:111b:1c03::2 (value not sent because of $reasons)
}
Fron the log:
[...]
Mon, 2021-05-10, 10:13:44 13[IKE] <1> received end entity cert "C=US,
O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
Mon, 2021-05-10, 10:13:44 13[CFG] <1> looking for peer configs matching
2001:1890:111b:1c03::2[%any]...2001:1890:111b:1004::22[C=US, O=ATT_FirstNet,
OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org]
Mon, 2021-05-10, 10:13:44 13[CFG] <1> no matching peer config found
[...]
That peer configs matching line says the following:
I look for a config where the local allowed addresses (local_addrs) contain
2001:1890:111b:1c03::2 and the identity can be ANY identity (any type, any
value)
(that is because in the IKE packet the other peer (client) sent, there is
no IDr, just an IDi (IDr == Identity Responder, IDi == Identity Initiator),
that is valid behaviour)
and the remote allowed addresses contain 2001:1890:111b:1004::22 and the
allowed identities have to contain "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" (type[1] unknown, probably
DN).
Looking at your currently loaded server side config, which is the following:
- local ID "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org"
- remote ID "zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
Explicitely compared as follows:
local ID %any contains "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zrdm55asegw52.epc.mnc670.mcc312.3gppnetwork.org" (that's fine)
remote ID "C=US, O=ATT_FirstNet, OU=ATT_FN_SeGW,
CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" DOES NOT MATCH
zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org
Solutions:
a) Explicitely set the remote ID on the server side to "C=US, O=ATT_FirstNet,
OU=ATT_FN_SeGW, CN=zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" (that's the
ID the client actually sends)
* See if the identity check later on the client side works out once the
identity the server sends for itself is known to the client. If it doesn't,
mutate configs accordingly.
b) Set the local ID on the client to
"zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org" (that should/will work because
the ID is exactly contained as type FQDN in the SAN of the client cert)
remote_addrs = 2001:1890:111b:1c03::2 # tunnel addr for C1/D1
local {
auth = pubkey
certs = zakr3dsegw51.crt
id = "zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org"
}
remote {
auth = pubkey
}
c) Remove the identity in the server config's remote auth section (will permit
any certificate if sent id is part of the certificate, thus any correctly
configured client with a trusted certificate)
I presume this is a POC where in the end a single CA or CAs under a common sub
ca issue client certificates. In that case just get that cert and set it in
remote.cacerts. strongSwan will ensure that certificates of clients that try to
authenticate have to have the configured CA certificate in its trust path.
That's the preferred solution. That way you can use that single connection
definition for all clients. The lookup for configs while config matching in the
code is linear so keep your number of loaded connections at a reasonable
number. Also, don't configure DNS names as local or remote addresses.
That will cause a DNS lookup for every config match (not good).
Let me know if this helps.
Kind regards
Noel
Addendum:
1) Standardized Identity types (from RFC5996)
ID Type Value
-------------------------------------------------------------------
ID_IPV4_ADDR 1
A single four (4) octet IPv4 address.
ID_FQDN 2
A fully-qualified domain name string. An example of an ID_FQDN
is "example.com". The string MUST NOT contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined
in [IDNA <https://datatracker.ietf.org/doc/html/rfc5996#ref-IDNA>], for
example "xn--tmonesimerkki-bfbb.example.net".
ID_RFC822_ADDR 3
A fully-qualifiedRFC 822 <https://datatracker.ietf.org/doc/html/rfc822>
email address string. An example of a
ID_RFC822_ADDR is "jsm...@example.com". The string MUST NOT
contain any terminators. Because of [EAI
<https://datatracker.ietf.org/doc/html/rfc5996#ref-EAI>], implementations would
be wise to treat this field as UTF-8 encoded text, not as
pure ASCII.
ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address.
ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [PKIX
<https://datatracker.ietf.org/doc/html/rfc5996#ref-PKIX>].
ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX
<https://datatracker.ietf.org/doc/html/rfc5996#ref-PKIX>].
ID_KEY_ID 11
An opaque octet stream that may be used to pass vendor-
specific information necessary to do certain proprietary
types of identification.
2) known strongSwan identity types (from man swanctl.conf):
The following prefixes are known: ipv4, ipv6, rfc822, email, userfqdn, fqdn,
dns, asn1dn, asn1gn and keyid. Custom type prefixes may be specified by
surrounding the numerical type value by curly brackets.
Am 02.06.21 um 21:06 schrieb FINLEY, DAVID BRIAN:
> Hello, I've resent this a couple of times over the last few weeks with no
> response. Appreciate that you may be too busy, just let me know if that's the
> case so that I know you received it and then I wont send any further follow
> ups.
> Thx.
>
> Dave Finley
> df1...@att.com
> (630) 719-4391 (desk)
> (630) 740-5198 (mobile)
>
> -----Original Message-----
> From: FINLEY, DAVID BRIAN
> Sent: Monday, May 10, 2021 10:20 AM
> To: Noel Kuntze <noel.kuntze@thermi.consulting>
> Subject: RE: [strongSwan] defining a connection profile using DNS name in the
> cert's alt subject name cert field
>
> I set my charon-logging.conf file up to match whats on the Wiki page,
> although it seems like what I have now is less verbose than before. Anyway,
> the settings I used were:
>
> filelog {
> charon-systemd {
> path = /var/log/charon_debug.log
> time_format = %a, %Y-%m-%d, %H:%M:%S
> default = 2
> mgr = 0
> net = 1
> enc = 1
> asn = 1
> job = 1
> ike_name = yes
> append = no
> flush_line = yes
> }
> }
>
> Thanks.
>
> Dave Finley
> df1...@att.com
> (630) 719-4391 (desk)
> (630) 740-5198 (mobile)
>
> -----Original Message-----
> From: Noel Kuntze <noel.kuntze@thermi.consulting>
> Sent: Saturday, May 08, 2021 3:09 AM
> To: FINLEY, DAVID BRIAN <df1...@att.com>
> Subject: Re: [strongSwan] defining a connection profile using DNS name in the
> cert's alt subject name cert field
>
> Hi,
>
> The cert looks okay, the log contains nothing useful though.
> Please create logs using the settings on the HelpRequests[1] page on the wiki.
> Those will then contain useful information.
>
> Kind regards
> Noel
>
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests
>
> Am 06.05.21 um 16:26 schrieb FINLEY, DAVID BRIAN:
>> Forgot that our mail server probably wouldn't allow that crt file through,
>> renamed it as txt this time. Also attached the charon.log file from the
>> connection failure with msg level turned up to 4. I search for "looking for"
>> when I want to go right to the point in the log where the profile lookup is
>> attempted and then fails.
>> thx
>>
>> Dave Finley
>> df1...@att.com
>> (630) 719-4391 (desk)
>> (630) 740-5198 (mobile)
>>
>> -----Original Message-----
>> From: Noel Kuntze <noel.kuntze@thermi.consulting>
>> Sent: Wednesday, May 05, 2021 6:08 PM
>> To: FINLEY, DAVID BRIAN <df1...@att.com>
>> Subject: Re: [strongSwan] defining a connection profile using DNS name in
>> the cert's alt subject name cert field
>>
>> Hi,
>>
>> Your mailserver's security solution removed the certificate.
>> Config looks okay though.
>> The right syntax is described on the man page for swanctl.conf and you
>> basically already tried it all.
>> Please get me the certificate and logs somehow.
>> Logs show you what happens for what reason.
>>
>> Kind regards
>> Noel
>>
>> Am 05.05.21 um 22:33 schrieb FINLEY, DAVID BRIAN:
>>> Noel,
>>> I attached the swanctl.conf file from both the client and the server. I
>> also attached the cert being used by the client so that you can see what the
>> subject Alt name value is, if that's useful.
>>> thx
>>>
>>> Dave Finley
>>> df1...@att.com
>>> (630) 719-4391 (desk)
>>> (630) 740-5198 (mobile)
>>>
>>> -----Original Message-----
>>> From: Noel Kuntze <noel.kuntze+strongswan-users-ml@thermi.consulting>
>>> Sent: Wednesday, May 05, 2021 2:00 PM
>>> To: FINLEY, DAVID BRIAN <df1...@att.com>; Users@lists.strongswan.org
>>> Subject: Re: [strongSwan] defining a connection profile using DNS name
> in the cert's alt subject name cert field
>>> Hi,
>>>
>>> Please show your whole config and complete logs.
>>>
>>> Kind regards
>>> Noel
>>>
>>> Am 05.05.21 um 20:13 schrieb FINLEY, DAVID BRIAN:
>>>> *Hello,*
>>>>
>>>> **
>>>>
>>>> *I have ipsec clients using strongswan that are connecting to a strongswan
>>>> server and want to setup connection profiles based on info in the subject
>>>> Alt name string in each clients certificate. The subject Alt name in
>>> the client cert looks like this:*
>>>> **
>>>>
>>>> *X509v3 Subject Alternative Name:*
>>>>
>>>> * DNS:zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> **
>>>>
>>>> *I've tried every variation I can think of using the "id = " parm in
>> swanctl.conf on the server and I cannot seem to get the strongswan server
>> to recognize/match on the subject Alt name in the clients cert. I've tried
>> values including:*
>>>> **
>>>>
>>>> *id = DNS: zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> *id = zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> *id = FQDN: zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> *id = @ zakr3dsegw51.epc.mnc100.mcc313.3gppnetwork.org*
>>>>
>>>> *and others.*
>>>>
>>>> **
>>>>
>>>> *Any suggestions?*
>>>>
>>>> *Thx in advance. *
>>>>
>>>> **
>>>>
>>>> Dave Finley
>>>>
>>>> df1...@att.com <mailto:df1...@att.com>
>>>>
>>>> (630) 719-4391 (desk)**
>>>>
>>>> (630) 740-5198 (mobile)
>>>>
>
