Project

General

Profile

Issue #3264

feature CUSTOM:kernel-ipsec in plugin 'kernel-netlink' failed to load

Added by James Fahrny 8 months ago. Updated 4 months ago.

Status:
Feedback
Priority:
Normal
Category:
configuration
Affected version:
5.8.1
Resolution:

Description

I apologize in advance if this has already been solved. I am using strongSwan 5.8.0 and a working baseline that uses ipsec config files and can create SAs with a series of target devices that are running Debian Linux. I have performed measurements for performance and I am now trying to get to a new baseline with the addition of a Spyrus HSM microSD card.

This seems like a kernel privilege issue but I could really use some expert input on how to solve this.
All of the certificates and keys are loaded in PKCS 12 format on the SD token and are being found correctly.

I am getting an error that is "feature CUSTOM:kernel-ipsec in plugin 'kernel-netlink' failed to load".

I am attaching the charon log so that the path is defined. Can you please provide some insight?
Thanks,
Jim Fahrny

charon.log (6.95 KB) charon.log James Fahrny, 12.11.2019 06:54
ipsec.conf (679 Bytes) ipsec.conf James Fahrny, 12.11.2019 17:17
ipsec.conf (768 Bytes) ipsec.conf James Fahrny, 13.11.2019 06:59
charon.log (9.15 KB) charon.log James Fahrny, 13.11.2019 06:59
charon.log.initiator (328 KB) charon.log.initiator Initiator Log Charon James Fahrny, 13.03.2020 18:02
strongswan.conf.responder (1.64 KB) strongswan.conf.responder Responder config strongSwan James Fahrny, 13.03.2020 18:02
ipsec.conf.responder (950 Bytes) ipsec.conf.responder Responder config ipsec James Fahrny, 13.03.2020 18:02
strongswan.conf.initiator (1.8 KB) strongswan.conf.initiator Initiator config strongSwan James Fahrny, 13.03.2020 18:02
ipsec.conf.initiator (932 Bytes) ipsec.conf.initiator Initiator config ipsec James Fahrny, 13.03.2020 18:02
charon.log.responder (2.61 MB) charon.log.responder Responder Log Charon James Fahrny, 13.03.2020 18:02

History

#1 Updated by Tobias Brunner 8 months ago

  • Category changed from charon to configuration
  • Status changed from New to Feedback
  • Priority changed from High to Normal

I am getting an error that is "feature CUSTOM:kernel-ipsec in plugin 'kernel-netlink' failed to load".

Becasue you already loaded the kernel-libipsec plugin. It's not really an error if you actually want to use the latter (read the linked page).

More of an issue is probably this:

Nov 11 23:21:15 00[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
Nov 11 23:21:15 00[CFG] line 1: expected PIN

See PinSecret.

#2 Updated by James Fahrny 8 months ago

Thanks Tobias for the quick reply! It sounds like I don't need to load kernel-libipsec and that there is an ipsec component in kernel-netlink? That sounds much better since the reduced performance of kernel-libipsec is not going to match the long term goal.

Both of these lines below are redundant with having the keys/certs on the HSM.

Loading ca certificates from /usr/local/etc/ipsec.d/cacerts
Loading secrets from /usr/local/etc/ipsec.d/ipsec.secrets

With ipsec.secrets, I only have the HSM reference, slot, key ID, PIN in this file and the secret key is on the SD Token.
If I only have the leftcert ID in the ipsec.conf file, the certs and secret key will auto load from token. Why would strongSwan also try to load from certs/secret keys from these directories?

Attaching the ipsec.conf file.
Thanks,
Jim

#3 Updated by James Fahrny 8 months ago

Made some changes including adding the %prompt to the PIN in ipsec.secrets I also removed eliminated the loading of the kernel-libipsec plugin. I am attaching a new copy of the charon.log and the ipsec.conf files. I am now seeing the same issues that you had talked about in issue 3048.
unable to create IPv4 routing table rule
unable to create IPv6 routing table rule

http://wiki.strongswan.org/issues/3048

I looked at the charon_nm kernel privilege that you outlined in this issue 3048. I have added the plugin section for in the strongswan.conf file but did not see any change?

I have a routing table setup at 254:

ip route list table 254
default via 192.168.3.254 dev br0
172.20.0.0/16 dev br0 proto kernel scope link src 172.20.40.32
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.32
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.32
192.168.4.0/24 dev rdl1 proto kernel scope link src 192.168.4.32
However, the seems to be some type of routing table issue and it may be permissions?

I also used "ipsec listcerts" and "ipsec listcacerts" and see no output but will this command work on an HSM?
If yes, then I probably have and issue with packaging multiple certs/keys in each PKCS #12 package or a problem with the referencing of the CKA_ID, Subject name or Alt Subject. I see some areas where the strongSwan document says CKA_ID must be used but not sure about this piece?
Thanks,
Jim Fahrny

#4 Updated by Tobias Brunner 8 months ago

I looked at the charon_nm kernel privilege that you outlined in this issue 3048. I have added the plugin section for in the strongswan.conf file but did not see any change?

Why do you think charon-nm is relevant? (You are using the charon daemon, not the NM backend.) Anyway, to use routing rules, the kernel must support them (they are required to install routes in a separate table, however, they could also be installed in the main routing table, or routing installation may be disabled completely if not required).

I looked at the charon_nm kernel privilege that you outlined in this issue 3048. I have added the plugin section for in the strongswan.conf file but did not see any change?

Again, charon-nm is not relevant here.

I have a routing table setup at 254:

That's just the main routing table.

However, the seems to be some type of routing table issue and it may be permissions?

Don't think it's a permission issue as the XFRM socket, which requires CAP_NET_ADMIN, has been opened successfully.

I also used "ipsec listcerts" and "ipsec listcacerts" and see no output but will this command work on an HSM?

If any certificates have been loaded from the device, yes.

If yes, then I probably have and issue with packaging multiple certs/keys in each PKCS #12 package or a problem with the referencing of the CKA_ID, Subject name or Alt Subject. I see some areas where the strongSwan document says CKA_ID must be used but not sure about this piece?

Certificates are loaded automatically if found and unless disabled (see pkcs11 plugin). Keys are referenced via CKA_ID in config files (certificates may be associated with configs via them too). Regarding PKCS#12 and how to store certificates/keys, you'd have to check the docs of your HSM. strongSwan uses PKCS#11 to communicate with the HSM, so as long as it implements it properly, it doesn't matter how the data is stored.

#5 Updated by James Fahrny 8 months ago

Yes, I was working late and should have not gone down the charon_nm path. I didn't think it would apply.

Thanks for the link on kernel routing rules. I corrected some missing pieces in that area a few days ago.

You do agree that the two unable messages need to be corrected?
unable to create IPv4 routing table rule
unable to create IPv6 routing table rule

On the HSM, there must be some type of issue if the keys/certs are automatically loaded on startup.
with strongswan running, there is nothing showing up with the "ipsec listcerts"
I do have the private key/cert/CA cert all in the same file and the CN is the same ID. I think that the HSM uses CKA_Label by default and the CKA_ID needs to be added to make this work?

Thanks Again!

#6 Updated by Tobias Brunner 8 months ago

You do agree that the two unable messages need to be corrected?

Depends on whether you need the routes (depends on the scenario and existing routes etc.) and whether it is an advantage to have them in a separate table.

I think that the HSM uses CKA_Label by default and the CKA_ID needs to be added to make this work?

No idea. Ask the manufacturer of your device. The pkcs11 plugin simply enumerates all X.509 certificate objects returned by the device, the CKA_ID is not relevant for that.

#7 Updated by James Fahrny 8 months ago

Several issues are resolved. There appear to not be any routing issues and I have connections along with a tunnel and Child SA with "ipsec statusall". I only have a few more questions since I do not have security associations.
I am still not seeing certificates when I use the "ipsec listcerts". Since the CA certs are still setup in PEM files, I can see those with "ipsec listcacerts". This leads to a few questions:
1) Is there any tool/logging capability in strongSwan to log PKCS 11 messages/transactions between PKCS11 plugin and the HSM?

2) Does it make sense to store the end entity private key in the clear to possibly eliminate any problems with the PIN in ipsec.secrets?

3) There are two choices in ipsec.secrets with * : PIN %smartcard0:<key_id> "Pin Code"* or : PIN %smartcard0:<key_id> %prompt
4) I am using the x509 certificate Common Name for Key_ID. Will this work?
If the prompt is used, should there be a way to enter the PIN?
Are these the only 2 methods for specifying a PIN for the private key?

Thanks for all of your assistance.

#8 Updated by Tobias Brunner 8 months ago

1) Is there any tool/logging capability in strongSwan to log PKCS 11 messages/transactions between PKCS11 plugin and the HSM?

The plugin itself has not much logging except for error cases. Since it's the configured PKCS#11 library that actually communicates with the HSM, check if you can enable logging there.

2) Does it make sense to store the end entity private key in the clear to possibly eliminate any problems with the PIN in ipsec.secrets?

What do you mean? Not store the key on the HSM? Or does it allow storing it unencrypted?

4) I am using the x509 certificate Common Name for Key_ID. Will this work?

<key_id> is the CKA_ID of the key object. Since that's a byte array it could theoretically be the CN, but you'll have to use the hex encoding there.

If the prompt is used, should there be a way to enter the PIN?

You have to call ipsec secrets to get prompted.

Are these the only 2 methods for specifying a PIN for the private key?

Yes. What other method would you expect?

#9 Updated by James Fahrny 8 months ago

Tobias Brunner wrote:

1) Is there any tool/logging capability in strongSwan to log PKCS 11 messages/transactions between PKCS11 plugin and the HSM?

The plugin itself has not much logging except for error cases. Since it's the configured PKCS#11 library that actually communicates with the HSM, check if you can enable logging there.

Thanks! I wanted to make sure and I am building a PKCS 11 open source logging tool.

2) Does it make sense to store the end entity private key in the clear to possibly eliminate any problems with the PIN in ipsec.secrets?

What do you mean? Not store the key on the HSM? Or does it allow storing it unencrypted?

I think that it does but it would require some modification

4) I am using the x509 certificate Common Name for Key_ID. Will this work?

<key_id> is the CKA_ID of the key object. Since that's a byte array it could theoretically be the CN, but you'll have to use the hex encoding there.

OK, thanks! The private keys have a CKA ID and I have entered that no in place of what I had used.

If the prompt is used, should there be a way to enter the PIN?

You have to call ipsec secrets to get prompted.

Are these the only 2 methods for specifying a PIN for the private key?

Yes. What other method would you expect?

Thanks and I was just thinking that there should be a way to secure the PIN but the prompt method does that.

Back at the beginning of this thread you stated:
"More of an important issue is"
Nov 11 23:21:15 00[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
Nov 11 23:21:15 00[CFG] line 1: expected PIN

I was looking at this log entry that the file was loaded and the PIN was found as expected on Line 1.
Is this interpretation correct or is this an error/warning stating that a PIN was expected but not found?

#10 Updated by Noel Kuntze 8 months ago

Make sure the line is formatted correctly. Check the man page for ipsec.secrets for reference.

#11 Updated by James Fahrny 8 months ago

I have SAs and security tunnels running with a pkcs 12 file for the certificate packages on the initiator and responder. Is the keyid value required to be an integer in ipsec secrets and a string/character array does not work? I am not getting a valid match for the certificate and the keyid in the ipsec.secrets file.

#12 Updated by Tobias Brunner 8 months ago

I have SAs and security tunnels running with a pkcs 12 file for the certificate packages on the initiator and responder. Is the keyid value required to be an integer in ipsec secrets and a string/character array does not work? I am not getting a valid match for the certificate and the keyid in the ipsec.secrets file.

PKCS#12 is a container format, it has nothing to do with PIN secrets and keyids. However, if you are referring to PKCS#11, then these things would be relevant (as I said before, the keyid is the CKA_ID, parsed as a hexadecimal binary string).

#13 Updated by James Fahrny 7 months ago

I was able to resolve series of issues around p12, keyid, HSM and there is one area that we would like to see if there are any plans to modify the strongswan configure/configure.ac build variables? We are using strongswan in several projects for endpoint/server communication security. We need to be able to easily make openssl to package components like librypto into locations that we want to control for applications but have the linux environment/system be unchanged. We want to have specific versions of openssl, pkcs11 engines and other strongswan components built and packaged into non-system linux locations that are not in the /usr/lib/aarcch64-linux-gnu/ path. We also need to modify plugin dependencies like libstrongswan-openssl paths/locations other than the /usr/lib/aarch-linux-gnu/libcrypto.so.1.0.0 but a path to a library that we control. Is this easily modifiable or are the plans to make this easier to control? Thanks!

#14 Updated by Tobias Brunner 7 months ago

./configure --help?

#15 Updated by James Fahrny 6 months ago

I am having a problem that the error status is no pkcs11 module found with key id = x in the log status.

I wanted to confirm that the subject key identifier must have the same value of the keyid for the
find_lib_and_keyid_by_skid function to return a valid value. Is this correct?

When I print the elements of the certs/keys that I have generated using "ipsec pki", the keyid is not the same
value as the subject key identifier. I thought that the keyid could be set in the ipsec pki command by setting it
with --keyid (hex value) but this does not seem to work. Are there examples for this or is the --keyid only for displaying
the keyid value?

Thanks!

#16 Updated by Tobias Brunner 6 months ago

With regards to the pkcs11 plugin the "id", "keyid" or "handle" refers to the CKA_ID of the key/certificate object on the token/smartcard. And yes, it's usually easiest if that value matches the keyid (as printed by pki) of the related key/certificate. But it doesn't have to if you explicitly configure it.

#17 Updated by James Fahrny 6 months ago

Let me layout this issue with more details so it makes more sense. I wrote this last message late last night.
In Issue #845 (5 years ago), you stated that the "same ID is not enough, the ID must actually match the SubjectKeyIdentifier of the certificate (or a hash of the subjectPublicKey.)" However, this issue was using charon_nm. I am using charon so does this requirement of matching apply to charon as well?

Loaded plugins
loaded plugins: charon pkcs11 aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac gcm attr kernel-netlink resolve socket-default forecast stroke vici updown xauth-generic dhcp counters

ipsec.conf

config setup
        charondebug="all" 
        uniqueids = yes
        strictcrlpolicy=no

conn %default
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        keyexchange=ikev2
        type=tunnel
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        leftsubnet=192.168.50.0/24
        rightsubnet=192.168.50.0/24
        left=%defaultroute
        leftid="C=US, O=strongSwan, CN=860109a4-6e61-42c6-84fa-f3c319ce2feb" 
        auto=start

conn ux32 
        right=192.168.3.32
        rightid="C=US, O=strongSwan, CN=cfa9cb85-3e39-4e6a-a7ee-abba7d9af91f" 

ipsec.secrets

: PIN %smartcard0:33 "$p412usA" 

strongswan.conf

charon {
    load_modular = yes
    multiple_authentication=no
    plugins {
            include strongswan.d/charon/*.conf
    }

    libstrongswan {
       plugins {
         modules {
          HSM_SD {
            # Full path to the shared object file of this PKCS#11 module.
            path = /usr/local/lib/lib3pkcs11x64sd.so.1.18
          }
        }
    }
 }

pkcs11.conf

pkcs11 {

    # Whether to load the plugin. Can also be an integer to increase the
    # priority of this plugin.
    load = yes

    # Reload certificates from all tokens if charon receives a SIGHUP.
     reload_certs = no

    # Whether the PKCS#11 modules should be used for DH and ECDH (see use_ecc
    # option).
     use_dh = no

    # Whether the PKCS#11 modules should be used for ECDH and ECDSA public key
    # operations. ECDSA private keys can be used regardless of this option.
     use_ecc = no

    # Whether the PKCS#11 modules should be used to hash data.
     use_hasher = no

    # Whether the PKCS#11 modules should be used for public key operations, even
    # for keys not stored on tokens.
     use_pubkey = no

    # Whether the PKCS#11 modules should be used as RNG.
     use_rng = no

    # List of available PKCS#11 modules.
    modules {

        MICRO_SD {

            # Whether to automatically load certificates from tokens.
            load_certs = yes

            # Whether OS locking should be enabled for this module.
            os_locking = no

            # Full path to the shared object file of this PKCS#11 module.
            path = /usr/local/lib/lib3pkcs11x64sd.so.1.18

        }

    }

}

Log file with details
Getting this error with extra debug added into pkcs11_private_key.c

Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading aa certificates from '/usr/local/etc/ipsec.d/aacerts'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading ocsp signer certificates from '/usr/local/etc/ipsec.d/ocspcerts'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading attribute certificates from '/usr/local/etc/ipsec.d/acerts'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading crls from '/usr/local/etc/ipsec.d/crls'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] BUILD PKCS#11 slot# 0
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] BUILD PKCS#11 Key ID 33
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] CKO Public - PKCS#11 module NOT found having CKO Pub keyid 33
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] CKO Certificate - PKCS#11 module NOT found having CKO Cert keyid 33
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] PKCS#11 module '(null)' found
Jan 12 21:57:05 oc03 charon-custom: 00[CFG] no PKCS#11 module found having a keyid 33
Jan 12 21:57:05 oc03 charon-custom: 00[LIB] failed to load private key with ID '0:33' from engine 'pkcs11'
Jan 12 21:57:05 oc03 charon-custom: 00[LIB] building CRED_PRIVATE_KEY - ANY failed, tried 7 builders

Key Print

ipsec pki --print --in 860109a4-6e61-42c6-84fa-f3c319ce2feb-Cert.pem

  subject:  "C=US, O=strongSwan, CN=860109a4-6e61-42c6-84fa-f3c319ce2feb" 
  issuer:   "C=US, O=strongSwan, CN=Root CA" 
  validity:  not before Jan 13 01:58:39 2020, ok
             not after  Jan 12 01:58:39 2022, ok (expires in 729 days)
  serial:    44:73:3e:a4:1f:75:06:f2
  altNames:  oc31
  flags:     serverAuth ikeIntermediate 
  authkeyId: 1e:e2:11:cc:19:ce:42:d1:de:80:32:09:2d:08:cf:75:d6:d7:94:df
  subjkeyId: e3:e4:68:88:d9:b1:76:06:8c:ba:82:1f:41:a4:1d:d7:34:ef:dc:53
  pubkey:    RSA 2048 bits
  keyid:     38:a2:41:c6:81:03:cb:39:fe:fe:3c:0c:a8:9c:bf:ba:42:7b:23:10
  subjkey:   e3:e4:68:88:d9:b1:76:06:8c:ba:82:1f:41:a4:1d:d7:34:ef:dc:53

Questions
Should the PKCS#11 module value be null or match the name MICRO_SD?

I have loaded the private key, the public key and the certificate onto the SD token with a CKA_ID value of 33.
Does the "module" = NULL create any problem with the the function "find_lib_and_keyid_by_skid"?

Do you see any other problems that could create this error?
Thanks Much!

#18 Updated by Tobias Brunner 6 months ago

I am using charon so does this requirement of matching apply to charon as well?

No, because you can explicitly configure the CKA_ID.

The modules section in your strongswan.conf file is useless (there is no plugin called modules). Is the module configured in the pkcs11.conf file actually loaded (check the log)?

Should the PKCS#11 module value be null or match the name MICRO_SD?

Doesn't really matter if you only have one module configured.

I have loaded the private key, the public key and the certificate onto the SD token with a CKA_ID value of 33.

33 hex or decimal? The handles in strongSwan are always hex. Are you sure about the slot ID (otherwise just omit it)?

Does the "module" = NULL create any problem with the the function "find_lib_and_keyid_by_skid"?

No, that function is actually only called if the module is not set. Otherwise find_lib is called directly.

#19 Updated by James Fahrny 6 months ago

Tobias Brunner wrote:

I am using charon so does this requirement of matching apply to charon as well?

No, because you can explicitly configure the CKA_ID.

OK, great. That is what I am doing with the tool that loads the objects onto the SD token.

The modules section in your strongswan.conf file is useless (there is no plugin called modules). Is the module configured in the pkcs11.conf file actually loaded (check the log)?

The log shows that the plugin was loaded successfully.

Yes, this was a typo and I corrected it. It is now setup as:

libstrongswan {
plugins {
pkcs11 {
modules {
TOKEN_SD { # Full path to the shared object file of this PKCS#11 module.
path = /usr/local/lib/lib3pkcs11x64sd.so.1.18
}
}
}
}
}

Actually, I realized that I don't need this explicit callout
of the plugin for PKCS 11 modules since the section at the top of the strongswan.conf file has:

plugins {
include strongswan.d/charon/*.conf
}

Should the PKCS#11 module value be null or match the name MICRO_SD?

Doesn't really matter if you only have one module configured.

Both are called the same name (TOKEN_SD) and yes I only have one token configured on each target.

Is it required to have the module defined in both the strongswan.conf and in the pkcs11.conf file?

I have loaded the private key, the public key and the certificate onto the SD token with a CKA_ID value of 33.

33 hex or decimal? The handles in strongSwan are always hex. Are you sure about the slot ID (otherwise just omit it)?

I will need look at this but I am 99% sure that the value is 33 hex. Does this need to be specified in ipsec.secrets as 0x33?
Yes, the slot is 0 so I will just omit it.

Does the "module" = NULL create any problem with the the function "find_lib_and_keyid_by_skid"?

No, that function is actually only called if the module is not set. Otherwise find_lib is called directly.

The function "find_lib_and_keyid_by_skid" is definitely being called given the debug statements in the log.

For this function below, I added the DBG1 logging and I am not getting to the "case BUILD_PKCS11_MODULE:" in the switch statement.

pkcs11_private_key_t *pkcs11_private_key_connect(key_type_t type,
va_list args) {
private_pkcs11_private_key_t *this;
char *module = NULL;
chunk_t keyid = chunk_empty, ckaid = chunk_empty;
int slot = -1;
CK_RV rv;

while (TRUE)
{
switch (va_arg(args, builder_part_t)) {
case BUILD_PKCS11_KEYID:
keyid = va_arg(args, chunk_t);
DBG1(DBG_CFG, "BUILD PKCS#11 Key ID%#B", &keyid);
continue;
case BUILD_PKCS11_SLOT:
slot = va_arg(args, int);
DBG1(DBG_CFG, "BUILD PKCS#11 slot# %d",slot);
continue;
case BUILD_PKCS11_MODULE:
module = va_arg(args, char*);
DBG1(DBG_CFG, "BUILD PKCS#11 Module %s",module);
continue;
case BUILD_END:
break;
default:
return NULL;
}
break;

Why would I need get to this case in the switch?
Thanks!

#20 Updated by James Fahrny 6 months ago

Actually, forget the first question since I figured this out by examining the strongswan.conf file later in my responses.

#21 Updated by James Fahrny 6 months ago

The last question should say...
What would cauae the code execution to not get to the "case BUILD_PKCS11_MODULE:" in the switch statement?
The public key and certificate appear to be found on the token but the private key is not found. Is it possible that the login has not happened to permit access to the private key?
The 33 is definitely 0x33 hex value for keyid.
THANKS

#22 Updated by Tobias Brunner 6 months ago

What would cauae the code execution to not get to the "case BUILD_PKCS11_MODULE:" in the switch statement?

Obviously, this block is only executed if a module was passed (e.g. if you configure one in the %smartcard statement).

The public key and certificate appear to be found on the token but the private key is not found.

The certificate is loaded automatically (unless disabled in the config) simply by enumerating all certificate objects on the token. You can try loading it explicitly via leftcert=%smartcard... to see if it can loaded that way.

Is it possible that the login has not happened to permit access to the private key?

No that happens later, after the module and object with matching CKA_ID has been found.

The 33 is definitely 0x33 hex value for keyid.

Can you post a list of object on the token (e.g. via pkcs11-tool --list-objects if you have OpenSC installed).

#23 Updated by James Fahrny 6 months ago

Here are the objects on the token:

Token Information:
                         label: SPYRUS ROSETTA SD 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
                manufacturerID: SPYRUS INC.                     
                         model: Rosetta SD      
                  serialNumber: 02000000900022EE
                         flags: CKF_RNG,CKF_LOGIN_REQUIRED,CKF_USER_PIN_INITIALIZED,CKF_TOKEN_INITIALIZED
             ulMaxSessionCount: 4096
             ulMaxSessionCount: 4096
                   ulMaxPinLen: 20
                   ulMinPinLen: 1
           ulTotalPublicMemory: 8000
            ulFreePublicMemory: 8000
          ulTotalPrivateMemory: 8000
           ulFreePrivateMemory: 8000
               hardwareVersion: 003.000
               firmwareVersion: 000.014
           utcTime: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
Object 0
                   Object size: 1587
                     CKA_CLASS: CKO_CERTIFICATE
                     CKA_TOKEN: TRUE
                   CKA_PRIVATE: FALSE
                     CKA_LABEL: 860109a4-6e61-42c6-84fa-f3c319ce2feb
                     CKA_VALUE: 
30 82 04 5a 30 82 02 42 a0 03 02 01 02 02 08 57 
9c ad 22 f6 f8 fc cc 30 0d 06 09 2a 86 48 86 f7 
0d 01 01 0c 05 00 30 34 31 0b 30 09 06 03 55 04 
06 13 02 55 53 31 13 30 11 06 03 55 04 0a 13 0a 
73 74 72 6f 6e 67 53 77 61 6e 31 10 30 0e 06 03 
55 04 03 13 07 52 6f 6f 74 20 43 41 30 1e 17 0d 
31 39 30 39 31 30 30 34 34 36 30 37 5a 17 0d 32 
31 30 39 30 39 30 34 34 36 30 37 5a 30 51 31 0b 
30 09 06 03 55 04 06 13 02 55 53 31 13 30 11 06 
03 55 04 0a 13 0a 73 74 72 6f 6e 67 53 77 61 6e 
31 2d 30 2b 06 03 55 04 03 13 24 38 36 30 31 30 
39 61 34 2d 36 65 36 31 2d 34 32 63 36 2d 38 34 
66 61 2d 66 33 63 33 31 39 63 65 32 66 65 62 30 
82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 
05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 
d4 fd 7d 31 c4 20 c9 33 0d 35 90 ca 4f 59 b4 a4 
79 69 44 a8 62 42 d1 f2 c2 3f 9b ad dc 43 d7 af 
a8 e6 d0 d0 71 dd 75 49 b6 f2 f8 4d 3f 83 6a d9 
02 c5 20 62 61 82 dc 66 64 db e5 c5 82 73 5e 64 
75 0e 0c 08 7f 73 f4 8a 94 b9 39 aa c4 9a c3 28 
21 57 cc f4 aa f4 bd 70 c5 4c f8 83 15 79 70 6b 
1f c9 96 4a cc 94 12 f5 06 87 6f a7 13 40 eb 29 
2a d8 34 59 85 42 a7 80 58 56 cf 86 63 41 54 e5 
85 13 6c 7b c2 80 60 a2 68 56 07 62 0d a3 dd f2 
51 b3 46 cd 3b 49 c2 4d 7b 09 b8 36 86 a5 78 bb 
3f f7 76 cc e0 57 2d 26 3c ee a4 57 67 02 a8 0c 
fb c0 e5 37 d6 01 2d 1d 6e 0f fe 02 6e 1f a2 f3 
3f 25 2e b0 5f 87 d3 7e 3e e0 23 ef f0 8e 6d ba 
7f 70 0b 9a 2f 7f 4d f2 53 de 31 6a 58 c0 9c 79 
2f 88 d0 78 53 15 ce 7a d4 74 bc 1a 3f 9a 13 d6 
8d f8 85 94 5b 7b 46 84 20 c2 65 62 32 a6 04 1d 
02 03 01 00 01 a3 53 30 51 30 1f 06 03 55 1d 23 
04 18 30 16 80 14 1e e2 11 cc 19 ce 42 d1 de 80 
32 09 2d 08 cf 75 d6 d7 94 df 30 0f 06 03 55 1d 
11 04 08 30 06 82 04 6f 63 33 31 30 1d 06 03 55 
1d 25 04 16 30 14 06 08 2b 06 01 05 05 07 03 01 
06 08 2b 06 01 05 05 08 02 02 30 0d 06 09 2a 86 
48 86 f7 0d 01 01 0c 05 00 03 82 02 01 00 61 92 
26 2a c0 4f d3 8e 1c 2e b5 9f fb e0 e4 d3 53 e3 
ef 3d e0 70 4f e5 68 18 30 56 f9 79 42 92 f1 eb 
0d d8 64 d5 02 00 94 8b 06 86 d6 f7 b8 75 b0 1e 
9e 5d eb 6c 5f 61 c4 66 b4 08 17 71 3e 8f b1 9a 
10 45 07 f2 e8 33 2d 92 8a 07 99 5f 57 95 b8 3a 
ee 70 6f 8d 7b fb 57 27 78 9d 5b 50 87 f9 8d 63 
b7 34 b6 80 5d 9e 02 b3 53 8b 26 71 a5 c0 6e 2f 
99 eb 95 ca 8d b3 64 25 10 5b 6e 59 b5 9e be 30 
2c 8a e4 86 10 35 32 bb 37 4d 38 fb 49 3f 91 14 
11 49 13 ea 75 ad ba 47 b0 23 6c 7c 3c 7a a5 a9 
e9 43 61 d4 d8 49 dd 41 05 0f de 56 2a 48 6c ed 
22 57 b7 12 b6 dd 86 84 c0 40 12 ea cd 3c 9a b1 
ac 2f ed 51 78 22 08 ba e7 82 33 77 d6 42 60 62 
1f d0 13 b1 27 4b f3 29 48 1e e3 74 1c d5 a0 bc 
69 7c 85 ef 5c 10 18 b1 39 1e 5c 9b 69 7e 1c 31 
5f dd 73 4c 7e ee 20 7c f4 81 27 33 5b 80 71 2e 
d3 c5 2b de e9 b0 1c 9f bb 71 26 aa d4 6e e1 f7 
dc 73 dd ea 4d 00 5c 9a f9 ca ec a1 fb 28 dd e6 
c5 e5 02 4b 5e 87 88 92 a6 ec 03 93 d5 58 45 8a 
e5 b6 8f f0 f9 66 1b 10 2f 32 df 88 56 ef 47 67 
1f 13 56 04 d0 cd 69 57 d2 e1 44 86 f5 69 3b a5 
df 2f 56 c1 65 51 96 ca e7 b9 7d b5 9f d1 13 2b 
eb e4 fa 5b 38 80 0f b6 95 17 cf bf b9 a2 69 1d 
34 13 e5 72 67 ca bd 95 45 4f ff 7f 7e 08 63 c1 
b2 e2 58 0c 6a 74 f2 41 9d 90 91 96 08 ba f4 cc 
51 b7 43 1b 8d 9d 3e 35 96 94 11 73 87 d9 e1 79 
7c 3b ba a5 87 cb e6 d2 1c 69 21 40 61 9c 55 7c 
b2 47 0a 26 01 45 8c b2 4c 45 3d 70 db c6 90 9e 
6d 89 fe d8 f4 55 e9 f4 83 98 30 34 da 95 08 89 
94 b0 32 9b 44 26 ea a6 fb 91 1f d1 21 34 93 96 
39 4e 73 ae 37 95 9c 46 82 3d a0 65 cb fc 3e 00 
42 d5 4c 6d f8 50 7c a3 36 29 ab da b6 1f 

          CKA_CERTIFICATE_TYPE: CKC_X_509
                    CKA_ISSUER: /C=US/O=strongSwan/CN=Root CA

             CKA_SERIAL_NUMBER: 
02 08 57 9c ad 22 f6 f8 fc cc 

                   CKA_SUBJECT: /C=US/O=strongSwan/CN=860109a4-6e61-42c6-84fa-f3c319ce2feb

                        CKA_ID: 
33 

                CKA_MODIFIABLE: TRUE
Object 1
                   Object size: 797
                     CKA_CLASS: CKO_PUBLIC_KEY
                     CKA_TOKEN: TRUE
                   CKA_PRIVATE: FALSE
                     CKA_LABEL: 860109a4-6e61-42c6-84fa-f3c319ce2feb
                  CKA_KEY_TYPE: CKK_RSA
                   CKA_SUBJECT: /C=US/O=strongSwan/CN=860109a4-6e61-42c6-84fa-f3c319ce2feb

                        CKA_ID: 
33 

                   CKA_ENCRYPT: TRUE
                      CKA_WRAP: TRUE
                    CKA_VERIFY: TRUE
            CKA_VERIFY_RECOVER: TRUE
                    CKA_DERIVE: TRUE
                   CKA_MODULUS: 
d4 fd 7d 31 c4 20 c9 33 0d 35 90 ca 4f 59 b4 a4 
79 69 44 a8 62 42 d1 f2 c2 3f 9b ad dc 43 d7 af 
a8 e6 d0 d0 71 dd 75 49 b6 f2 f8 4d 3f 83 6a d9 
02 c5 20 62 61 82 dc 66 64 db e5 c5 82 73 5e 64 
75 0e 0c 08 7f 73 f4 8a 94 b9 39 aa c4 9a c3 28 
21 57 cc f4 aa f4 bd 70 c5 4c f8 83 15 79 70 6b 
1f c9 96 4a cc 94 12 f5 06 87 6f a7 13 40 eb 29 
2a d8 34 59 85 42 a7 80 58 56 cf 86 63 41 54 e5 
85 13 6c 7b c2 80 60 a2 68 56 07 62 0d a3 dd f2 
51 b3 46 cd 3b 49 c2 4d 7b 09 b8 36 86 a5 78 bb 
3f f7 76 cc e0 57 2d 26 3c ee a4 57 67 02 a8 0c 
fb c0 e5 37 d6 01 2d 1d 6e 0f fe 02 6e 1f a2 f3 
3f 25 2e b0 5f 87 d3 7e 3e e0 23 ef f0 8e 6d ba 
7f 70 0b 9a 2f 7f 4d f2 53 de 31 6a 58 c0 9c 79 
2f 88 d0 78 53 15 ce 7a d4 74 bc 1a 3f 9a 13 d6 
8d f8 85 94 5b 7b 46 84 20 c2 65 62 32 a6 04 1d 

              CKA_MODULUS_BITS: 2048
           CKA_PUBLIC_EXPONENT: 
01 00 01 

                CKA_MODIFIABLE: TRUE
Object 2
                   Object size: 815
                     CKA_CLASS: CKO_PRIVATE_KEY
                     CKA_TOKEN: TRUE
                   CKA_PRIVATE: TRUE
                     CKA_LABEL: 860109a4-6e61-42c6-84fa-f3c319ce2feb
                  CKA_KEY_TYPE: CKK_RSA
                   CKA_SUBJECT: /C=US/O=strongSwan/CN=860109a4-6e61-42c6-84fa-f3c319ce2feb

                        CKA_ID: 
33 

                 CKA_SENSITIVE: TRUE
                   CKA_DECRYPT: TRUE
                    CKA_UNWRAP: TRUE
                      CKA_SIGN: TRUE
              CKA_SIGN_RECOVER: TRUE
                    CKA_DERIVE: FALSE
                   CKA_MODULUS: 
d4 fd 7d 31 c4 20 c9 33 0d 35 90 ca 4f 59 b4 a4 
79 69 44 a8 62 42 d1 f2 c2 3f 9b ad dc 43 d7 af 
a8 e6 d0 d0 71 dd 75 49 b6 f2 f8 4d 3f 83 6a d9 
02 c5 20 62 61 82 dc 66 64 db e5 c5 82 73 5e 64 
75 0e 0c 08 7f 73 f4 8a 94 b9 39 aa c4 9a c3 28 
21 57 cc f4 aa f4 bd 70 c5 4c f8 83 15 79 70 6b 
1f c9 96 4a cc 94 12 f5 06 87 6f a7 13 40 eb 29 
2a d8 34 59 85 42 a7 80 58 56 cf 86 63 41 54 e5 
85 13 6c 7b c2 80 60 a2 68 56 07 62 0d a3 dd f2 
51 b3 46 cd 3b 49 c2 4d 7b 09 b8 36 86 a5 78 bb 
3f f7 76 cc e0 57 2d 26 3c ee a4 57 67 02 a8 0c 
fb c0 e5 37 d6 01 2d 1d 6e 0f fe 02 6e 1f a2 f3 
3f 25 2e b0 5f 87 d3 7e 3e e0 23 ef f0 8e 6d ba 
7f 70 0b 9a 2f 7f 4d f2 53 de 31 6a 58 c0 9c 79 
2f 88 d0 78 53 15 ce 7a d4 74 bc 1a 3f 9a 13 d6 
8d f8 85 94 5b 7b 46 84 20 c2 65 62 32 a6 04 1d 

           CKA_PUBLIC_EXPONENT: 
01 00 01 

               CKA_EXTRACTABLE: FALSE
                CKA_MODIFIABLE: FALSE

#24 Updated by James Fahrny 6 months ago

I tried to use the leftcert=%module and it did not seem to work. I am assuming that this requires that you still have the PIN: %module "xxxxxx" in ipsec.secrets?

I also was able to use a debugger and will look at more details in the morning. However, I was able to see that the file credential_factory.c is failing in the METHOD "CRED_PRIVATE_KEY". I need to look at this in more detail to see why it is failing.
THANKS!

#25 Updated by Tobias Brunner 6 months ago

Here are the objects on the token:

Thanks. That at least seems to confirm the CKA_ID of 33 hex.

I tried to use the leftcert=%module and it did not seem to work.

Why would you think that's valid syntax? It's exactly the same as in ipsec.secrets (i.e. it starts with %smartcard).

I am assuming that this requires that you still have the PIN: %module "xxxxxx" in ipsec.secrets?

Yes, but wrong syntax again.

However, I was able to see that the file credential_factory.c is failing in the METHOD "CRED_PRIVATE_KEY".

You should focus on the code in the pkcs11 plugin as that's where the failure occurs eventually.

#26 Updated by James Fahrny 6 months ago

My mistake on the syntax and was not what I had. I actually have PIN: %smartcard:33 "XXXXXXXX" in ipsec.secrets and leftcert=%smartcard in the ipsec.conf

I wrote this late last night. Thanks for the pointer on the pkcs11 plugin.

#27 Updated by Tobias Brunner 6 months ago

My mistake on the syntax and was not what I had. I actually have PIN: %smartcard:33 "XXXXXXXX" in ipsec.secrets and leftcert=%smartcard in the ipsec.conf

I see, please note that the keyid/CKA_ID is mandatory (i.e. the leftcert value is still not correct), and that the : actually has to be before PIN (see PinSecret).

#28 Updated by James Fahrny 6 months ago

Thanks for the update on this. I do have the : before PIN.
Does the pin need to be included in the leftcert syntax?
Are single quotation marks or double quotation marks for pin value both allowed?

:PIN %smartcard:33 '1234' or "1234" or just 1234

leftcert=%smartcard:33 '1234' ?

if I add the module to the PIN statement, I assume that it would be the string TOKEN_SD as defined above. Is this correct?

THANKS!

#29 Updated by Tobias Brunner 6 months ago

Does the pin need to be included in the leftcert syntax?

No.

Are single quotation marks or double quotation marks for pin value both allowed?

Both are fine (or none).

if I add the module to the PIN statement, I assume that it would be the string TOKEN_SD as defined above. Is this correct?

Yes, it's the name of the sub-section you configure in the *.plugins.pkcs11.modules section.

#30 Updated by James Fahrny 6 months ago

Thanks for the inputs! I seem to be having a problem with the Pin/passphrase when the SD Toke is accessing the private key in stroke_creds.c. I have created the p12 package on the SD Token with a passphrase. There is also a password to login into the SD Token. In this case, would the ipsec.secrets need to specify both the PIN for the Smartcard based on the CKA ID and also the P12 passphrase to open the package that was loaded onto the SD Token. If yes, does the order of these in ipsec.secrets file matter?

#31 Updated by Tobias Brunner 6 months ago

In this case, would the ipsec.secrets need to specify both the PIN for the Smartcard based on the CKA ID and also the P12 passphrase to open the package that was loaded onto the SD Token.

That there is a PKCS#12 container on the card is irrelevant to strongSwan, it only accesses it via PKCS#11. So make sure your middleware handles this correctly (e.g. decrypts the PKCS#12 container on the fly when the key/certificate is accesses via PKCS#11).

#32 Updated by James Fahrny 5 months ago

Yes, the import tool unwraps the PKCS 12 and stores the objects as pkcs11 objects.
In Openssl_plugin.c. we have two places that are a little unclear:

There is a function called login(ENGINE *engine, chunk_t key_id)
and the code execution ends up at line 359:
DBG1;

The PIN and the engine values are correct but the keyid appears to be NULL.

We then end up in execution at Line 450/451:

key = ENGINE_load_private_key(engine, keyname, NULL, NULL);
ENGINE_finish(engine);
if (!key) {
Line 450: DBG1(DBG_LIB, "failed to load private key with ID '%s' from "
"engine '%s'", keyname, engine_id);
Line 451: return NULL;

}

The strange part to me is that the keyname is correct as an ascii string of the keyid.
The engine ID is 'pkcs11'.
The key is 0.

Do you have any suggestions on what to look for here or in the PKCS 11 plugin for this
failure. I would think that this is a not finding the private key due to the login but want top see what your thoughts are?
THANKS!

#33 Updated by Tobias Brunner 5 months ago

In Openssl_plugin.c. we have two places that are a little unclear:

So you now use the openssl plugin? Not the pkcs11 plugin? For the former you have to configure OpenSSL correctly (i.e. set up an ENGINE in openssl.cnf that can be used via strongSwan), but why switch? I'd recommend you debug this in the pkcs11 plugin.

#34 Updated by James Fahrny 5 months ago

I removed the openssl plugin to possibly eliminate any conflicts that could occur. I added the module name to the ipsec.secrets file:
: PIN %smartcard0@SPYRUS_ROSETTA_SD:38363031303961342d366536312d343263362d383466612d663363333139636532666562 "123456"

I added the CA certificate onto the SD Token.
ca strongswan
cacert=%smartcard:526f6f74204341

I added the leftcert for the smartcard:
leftcert=%smartcard:38363031303961342d366536312d343263362d383466612d663363333139636532666562

The private key is being found now but...

now I am failing with the login to the SD Token:
[CFG] login to 'SPYRUS_ROSETTA_SD':0 failed: FUNCTION_FAILED
[CFG] Login on slot ID 0 failed

The PIN is correct but I am still digging into the login failure.
Any thoughts or things that appear to be wrong?
THANKS

#35 Updated by James Fahrny 5 months ago

This is a very strange problem. The cert/key import tool has the ability to dump the PKCS 11 objects from the SD Token/ This tool uses C_login with the same PIN and it works. I have traced this all the way into the PKCS 11 library and do not see a problem with the PIN. Is it possible that the Session handle does not match and could cause a failure?

Thanks for you help!

#36 Updated by Tobias Brunner 5 months ago

I have traced this all the way into the PKCS 11 library and do not see a problem with the PIN. Is it possible that the Session handle does not match and could cause a failure?

No idea. You have to discuss that with the devs of your PKCS#11 library.

#37 Updated by James Fahrny 5 months ago

Actually the tools from the developer of the PKCS#11 libary work correctly and login with the PIN. Strongswan is unable to login into the SD Token with the same PIN.

#38 Updated by Tobias Brunner 5 months ago

Actually the tools from the developer of the PKCS#11 libary work correctly and login with the PIN. Strongswan is unable to login into the SD Token with the same PIN.

The tools the dev wrote are not relevant. strongSwan uses PKCS#11. Try with e.g. pkcs11-tool and that PKCS#11 library.

#39 Updated by James Fahrny 4 months ago

Lots of successes... C_Login Works now and consistently. I also had some problems with loading the CA cert onto the token and that created some problems since there was no private key included in the p12 package. CA cert is no loaded as a PEM file from a directory. I am now extracting the private key object and building the credentials so things are very close to the completion.
However, I am a problem with the SA on the responder. The Initiator does not seem to have a problem but may be contributing to the issue.
The Initator seems to come up OK and can create an SA connection with the responder.

root@oc03:/usr/local/etc# ipsec statusall
Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.14.0-qcomlt-arm64, aarch64):
uptime: 5 seconds, since Mar 11 22:02:25 2020
malloc: sbrk 2760704, mmap 0, used 708848, free 2051856
worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
loaded plugins: charon pkcs11 aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac gcm attr kernel-netlink resolve socket-default forecast stroke vici updown xauth-generic dhcp counters
Listening IP addresses:
192.168.4.31
192.168.1.156
192.168.3.31
172.20.40.31
Connections:
ux32: %any...192.168.3.32 IKEv2, dpddelay=30s
ux32: local: [C=US, O=strongSwan, CN=860109a4-6e61-42c6-84fa-f3c319ce2feb] uses public key authentication
ux32: cert: "C=US, O=strongSwan, CN=860109a4-6e61-42c6-84fa-f3c319ce2feb"
ux32: remote: [C=US, O=strongSwan, CN=cfa9cb85-3e39-4e6a-a7ee-abba7d9af91f] uses public key authentication
ux32: child: 192.168.50.0/24 === 192.168.50.0/24 TUNNEL, dpdaction=restart
Security Associations (0 up, 1 connecting):
ux321: CONNECTING, %any[%any]...192.168.3.32[%any]
ux321: IKEv2 SPIs: 7959196eb4405344_i* 0000000000000000_r
ux321: Tasks active: IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME

However, the responder comes up and is good at the start before the Initiator is started for the connection. After the initiator is started, the responder goes from a named connection to unnamed connections and MOBIKE seems to come into play which looks like NAT Traversal. NAT-T port is set to 0 on both initiator and responder to get a dynamic allocation of the port.
Is there a way to keep this simple and do a P2P tunnel without the NAT T and MOBIKE?
How can I get the sucessful SA connections on both sides with this NAT travesral issue?
Is there a simple way to just create a P2P config and eliminate the UDP port issues?

Thanks!
James

#40 Updated by Tobias Brunner 4 months ago

ux32: child: 192.168.50.0/24 === 192.168.50.0/24 TUNNEL, dpdaction=restart

Are you sure about these configured subnets? (Same on both ends?)

NAT-T port is set to 0 on both initiator and responder to get a dynamic allocation of the port.

That won't work. How can the two know to which port they should switch after detecting a NAT or when MOBIKE is enabled? It works fine on an initiator, but not on a responder. You can use a custom port on a responder, but you have to configure that explicitly as destination port on the initiator (see NatTraversal).

#41 Updated by James Fahrny 4 months ago

Thanks Tobias! I added the leftikeport to the responder and rightikeport to the Initiator for a custom port (700) This part is all working now. The subnet needs to be the same for both on this first test scenario (192.168.50.0)

For the responder, I am getting the following status:

Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.14.0-qcomlt-arm64, aarch64):
  uptime: 45 seconds, since Mar 13 16:41:21 2020
  malloc: sbrk 2760704, mmap 0, used 726256, free 2034448
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
  loaded plugins: charon pkcs11 aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac gcm attr kernel-netlink resolve socket-default forecast stroke vici updown xauth-generic dhcp counters
Listening IP addresses:
  192.168.4.32
  192.168.3.32
  192.168.1.32
  192.168.50.32
  172.20.40.32
Connections:
        oc31:  %any...192.168.3.31  IKEv2, dpddelay=30s
        oc31:   local:  [C=US, O=strongSwan, CN=cfa9cb85-3e39-4e6a-a7ee-abba7d9af91f] uses public key authentication
        oc31:    cert:  "C=US, O=strongSwan, CN=cfa9cb85-3e39-4e6a-a7ee-abba7d9af91f" 
        oc31:   remote: [C=US, O=strongSwan, CN=860109a4-6e61-42c6-84fa-f3c319ce2feb] uses public key authentication
        oc31:   child:  192.168.50.0/24 === 192.168.50.0/24 TUNNEL, dpdaction=restart
Security Associations (0 up, 1 connecting):
        oc31[1]: CONNECTING, %any[%any]...192.168.3.31[%any]
        oc31[1]: IKEv2 SPIs: 31cf474668b4f96f_i* 0000000000000000_r
        oc31[1]: Tasks active: IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME

For the initiator, I am getting the following status:

Status of IKE charon daemon (strongSwan 5.7.2, Linux 4.14.0-qcomlt-arm64, aarch64):
  uptime: 49 seconds, since Mar 13 16:41:14 2020
  malloc: sbrk 2760704, mmap 0, used 776432, free 1984272
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
  loaded plugins: charon pkcs11 aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf curve25519 xcbc cmac hmac gcm attr kernel-netlink resolve socket-default forecast stroke vici updown xauth-generic dhcp counters
Listening IP addresses:
  192.168.4.31
  192.168.1.156
  192.168.3.31
  172.20.40.31
  192.168.50.31
Connections:
        ux32:  %any...192.168.3.32  IKEv2, dpddelay=30s
        ux32:   local:  [C=US, O=strongSwan, CN=860109a4-6e61-42c6-84fa-f3c319ce2feb] uses public key authentication
        ux32:    cert:  "C=US, O=strongSwan, CN=860109a4-6e61-42c6-84fa-f3c319ce2feb" 
        ux32:   remote: [C=US, O=strongSwan, CN=cfa9cb85-3e39-4e6a-a7ee-abba7d9af91f] uses public key authentication
        ux32:   child:  192.168.50.0/24 === 192.168.50.0/24 TUNNEL, dpdaction=restart
Security Associations (0 up, 1 connecting):
        ux32[1]: CONNECTING, %any[%any]...192.168.3.32[%any]
        ux32[1]: IKEv2 SPIs: c215a119897260a9_i* 0000000000000000_r
        ux32[1]: Tasks active: IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME 

I still am not seeing why the Security Associations are not completing to "up" status?

#42 Updated by Tobias Brunner 4 months ago

The subnet needs to be the same for both on this first test scenario (192.168.50.0)

If you say so.

Not sure if that's intended, but you configured both ends as initiators. And as explained on NatTraversal, you can't use port 500 as source port when connecting to a custom server port.

#43 Updated by James Fahrny 4 months ago

The same subnet is for a mesh type of setup. I definitely did not intend to configure the 192.168.3.32/UX32 as an initiator. I will need to see if I can look at the ipsec.conf.responder ro see if I correct this. OK, I can let the ports be defaults to 500 and 4500 for now.

#44 Updated by James Fahrny 4 months ago

Oh, yes, the auto=add on the responder side config. Thanks.

Also available in: Atom PDF