IKE authentication¶

Authentication basics ¶

Configuring IKE authentication consists in:

choosing the local and remote authentication methods (pre-shared keys, certificate signatures or an EAP method),
specifying the local (and optionally remote) authentication identity,
configuring keys, certificates or contact information of a RADIUS server.

The authentication methods of the local and remote IKE peer may be asymmetric: For example, the local host may authenticate by certificate and the remote peer by EAP.

The methods used to authenticate the local and remote peer are specified in the ike-policy-template and may be overridden in the VPN ike-policy:

vsr running ike# vpn vpn-hq
vsr running vpn vpn-hq# ike-policy
vsr running ike-policy# local-auth-method certificate
vsr running ike-policy# remote-auth-method eap-mschapv2
vsr running ike-policy# ..
vsr running vpn vpn-hq#

If unspecified, the default authentication method is pre-shared-key.

The local IKE identity is defined in the VPN:

vsr running vpn vpn-hq# local-id server@6wind.com

If unspecified, the local IKE identity defaults to:

the IKE connection local address for pre-shared key
the certificate subject for certificate authentication

When using certificate authentication, the IKE identity must be contained in the certificate, either as subject or as subjectAltName.

Optionally, the remote IKE identity may be specified. It indicates which identity to expect for the authentication round. If initiating an IKE negotiation, it will also be used to choose the right pre-shared key, and will be specified as the responder identity (IDr) in the IKE_AUTH exchange:

vsr running vpn vpn-hq# remote-id client1@6wind.com

Wildcards are supported, to filter the identity presented by the peer. However in this case, if initiating an IKE negotiation, the actual remote identity remains unknown.

vsr running vpn vpn-hq# remote-id *@6wind.com

By default, if EAP authentication is used, the client EAP identity is its IKE identity, however a different identity may be used with the local-eap-id or remote-eap-id commands. See EAP authentication for more details.

Identity encoding ¶

IKE supports several types of identities, the most frequent of which are IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN, DER_ASN1_DN, KEY_ID.

The type and the value of an identity string (or an identity filter) is usually properly guessed.

The special values %any, %any6, 0.0.0.0, :: or * are synonyms that match any identity (whatever its type).

The Virtual Service Router supports all types of standard and custom identity types. When needed, it is possible to explicitly specify the type and encoding of an identity.

Pre-shared key authentication ¶

Configuration ¶

Pre-shared keys are secret symmetric keys shared by two IKE peers. They are configured in the pre-shared-key list.

When using pre-shared key authentication for the local host or remote peer authentication, the shared key must be declared as follows:

vsr running ike# pre-shared-key hq-secgw
vsr running pre-shared-key hq-secgw#! id secgw.6wind.net
vsr running pre-shared-key hq-secgw#! secret 0seaJ31RfzHNRvUSH0oUYg7znTW0I=
vsr running pre-shared-key hq-secgw# ..
vsr running ike#

vsr running ike# show config
ike
    (...)
    pre-shared-key hq-secgw
        id secgw.6wind.net
        secret 0seaJ31RfzHNRvUSH0oUYg7znTW0I=
        ..

Each pre-shared key is identified by this name and is composed of two parts, a secret key and optional IKE identity filters (a list of IKE identities).

The secret key itself, secret, may be encoded either:

as a sequence of characters delimited by double-quotes,

secret "this is a weak password"

as an hexadecimal binary value, prefixed by 0x:

secret 0xd2c79a277d517f31cd46f5121f4a14620ef39d35b4

as a base64 binary value, prefixed by 0s:

secret 0seaJ31RfzHNRvUSH0oUYg7znTW0I=

The optional IKE identity filter list id, specifies for which local and remote peers this key must be used. To authenticate a connection between two hosts, the entry that most specifically matches the local and remote IKE identity is used.

Wildcards are supported in the identity list for some types of identity filters:

for an IPV4_ADDR or IPV6_ADDR: a subnet or range is supported (e.g.: 10.125.0.0/24, fd00:125::/64 or 10.125.0.1-10.125.0.10)
for an FQDN: a leading * is supported. The identifier end must exactly match the rest of the string (e.g.: *.6wind.com, *.fr, *core or fqdn:*)
for a USER_FQDN: a leading * is supported. The identifier end must exactly match the rest of the string (e.g.: *@6wind.com or userfqdn:*.fr)
for a KEY_ID, no wildcard is supported, the identifier must match exactly.

The special value %any matches any value, including the case when the identity is unknown (which is frequent for the remote identity when initiating an IKE connection).

A pre-shared key with no identity filter is identical to a pre-shared key with the sole filter %any, and is used as the default pre-shared key.

To authenticate the local host by pre-shared keys, the local-auth-method must be set to pre-shared-key in the ike-policy-template used by the VPN:

vsr running ike# ike-policy-template ikepsk local-auth-method pre-shared-key
vsr running ike# vpn vpn-hq ike-policy template ikepsk

Or overridden in the VPN ike-policy:

vsr running ike# vpn vpn-hq ike-policy local-auth-method pre-shared-key

Similarly, to authenticate the remote peer by pre-shared keys, the remote-auth-method must be set to pre-shared-key in the ike-policy-template used by the VPN, or overridden in the VPN ike-policy.

Pre-shared key is the default authentication method.

Pre-shared key selection ¶

Pre-shared keys are used to sign IKE messages and authenticate the sender. During the IKE_AUTH exchange, the sender of an IKE message must select the right pre-shared key to authenticate oneself based on the local and remote identities of the peers.

The local and remote identities of the IKE peers may be specified in the VPN configuration with local-id and remote-id, but these configuration fields are optional.

By default, the local identity is the IKE connection local address, and the remote identity is unknown (as initiator) or learnt from the remote peer (as responder).

A peer always specifies its own identity in the IKE authentication exchange, however it only specifies the remote identity if it knows it.

The pre-shared key definitions are made of a secret key and an optional list of identity filters. To authenticate oneself to the remote peer, the local host selects the pre-shared key whose identity filters best match the local and remote identity. The selection algorithm favors the match score of the remote identity. An unknown identity only matches the value %any in the pre-shared key identity filters.

The match score of the local or remote identity is evaluated as follows:

ID_MATCH_NONE = 0: the identity matches no filter
ID_MATCH_ANY = 1: the identity matches the %any filter
ID_MATCH_MAX_WILDCARDS = 2 : the identity matches a filter with maximum allowed wildcards
ID_MATCH_ONE_WILDCARD = 19: the identity matches a filter match with only one wildcard
ID_MATCH_PERFECT = 20: the identity perfectly matches a filter

The selection algorithm scans all pre-shared key definitions.

For each entry, it evaluates the match scores of the local and remote identities against the identity filters.

if none of the identities match any filter, the pre-shared key is discarded,
else if there is no candidate pre-shared key yet, the entry becomes the new best candidate,
else if the remote-id score is greater than the current candidate, the entry becomes the new best candidate,
else if the remote-id score is equal but the local-id score is greater than the current candidate, the entry becomes the new best candidate,
else the entry is discarded.

Once all identities are scanned (or a perfect match for both identities is found), the best candidate (if any) is selected.

Examples (this configuration is not a production example, it is only designed to explain the match score calculation and selection algorithm):

ike
    (...)
    pre-shared-key key1
        id left.6wind.net
        secret 0seaJ31RfzHNRvUSH0oUYg7znTW0I=
        ..
    pre-shared-key key2
        id left.6wind.net
        id right.6wind.net
        secret 0sVgdJmXQL6ahBHL6g1itReEwG9f8=
        ..
    pre-shared-key key3
        id left.6wind.net
        id %any
        secret 0s1+jaqJgz9FnCwgz8pZN1YYOZMwc=
        ..
    pre-shared-key key4
        id *.6wind.net
        secret 0sJVlRQ2RXE2YVruc8avbn5tnyYSU=
        ..
    pre-shared-key key5
        id down.6wind.net
        secret 0sRmKobO5hlvoZlmGSyvyYKkUG/uQ=
        ..
    pre-shared-key key6
        secret 0sBVlHg3bis8/4KwdxLtBUo8YsfMQ=
        ..

   vpn myvpn
        local-address 10.125.0.1
        remote-address 10.175.0.2
        local-id left.6wind.net
        (...)

case 1: The local host, with identity left.6wind.net is the initiator of a negotiation to a remote host. The identity of the remote host is right.6wind.net, but the initiator does not know it, it will only discover it in the IKE_AUTH response. The initiator must chose the pre-shared key to authenticate oneself.

The local host hence looks up for a pre-shared key for local-id left.6wind.net and remote-id %any:

key	`local-id` match score	`remote-id` match score
key1	ID_MATCH_PERFECT (20)	ID_MATCH_NONE (0)
key2	ID_MATCH_PERFECT (20)	ID_MATCH_NONE (0)
key3	ID_MATCH_PERFECT (20)	ID_MATCH_ANY (1)
key4	ID_MATCH_ONE_WILDCARD (19)	ID_MATCH_NONE (0)
key5	ID_MATCH_NONE (0)	ID_MATCH_NONE (0)
key6	ID_MATCH_ANY (1)	ID_MATCH_ANY (1)

key5 does not match at all, it is discarded. All other pre-shared keys have at least one identifier match so remain in the race.

key3 and key6 have the best remote-id score (1), but key3 has a better local-id score (20), so key3 will be selected.

case 2: the local host is the responder. It received an IKE_AUTH request with initiator-id right.6wind.net and no responder-id, but the configuration specifies that the local-id is left.6wind.net. It must chose the pre-shared key to authenticate oneself.

The local host hence looks up for a pre-shared key for local-id left.6wind.net and remote-id right.6wind.net. The match scores are now different from the previous case:

key	`local-id` match score	`remote-id` match score
key1	ID_MATCH_PERFECT (20)	ID_MATCH_NONE (0)
key2	ID_MATCH_PERFECT (20)	ID_MATCH_PERFECT (20)
key3	ID_MATCH_PERFECT (20)	ID_MATCH_ANY (1)
key4	ID_MATCH_ONE_WILDCARD (19)	ID_MATCH_NONE (0)
key5	ID_MATCH_NONE (0)	ID_MATCH_NONE (0)
key6	ID_MATCH_ANY (1)	ID_MATCH_ANY (1)

This time, key2 has the best remote-id score (20), so it is selected.

As a conclusion, when IKE negotiations must be established with different peers with individual pre-shared keys, the best situation is when the remote peer identity is known, and specified in the pre-shared key id filters.

As a responder, this remote-id will anyway be learnt during the negotiation.

As an initiator, this remote-id must be specified in the VPN configuration, otherwise the device has no way to choose the right pre-shared key.

Example:

 pre-shared-key keypeer1
     id peer1.6wind.net
     secret 0seaJ31RfzHNRvUSH0oUYg7znTW0I=
     ..
 pre-shared-key keypeer2
     id peer2.6wind.net
     secret 0sVgdJmXQL6ahBHL6g1itReEwG9f8=
     ..

vpn vpn-peer1
    (...)
    local-address 10.125.0.1
    remote-address 10.175.0.2
    local-id me.6wind.net
    remote-id peer1.6wind.net

vpn vpn-peer2
    (...)
    local-address 10.125.0.1
    remote-address 10.185.0.3
    local-id me.6wind.net
    remote-id peer2.6wind.net

In a less ideal situation, as an initiator, if the remote-id is not known in advance, then the pre-shared keys can only be selected based on the local-id, which implies to use a different local-id for each VPN, and to specify it in the pre-shared keys id filters.

Example:

 pre-shared-key keypeer1
     id myid1.6wind.net
     secret 0seaJ31RfzHNRvUSH0oUYg7znTW0I=
     ..
 pre-shared-key keypeer2
     id myid2.6wind.net
     secret 0sVgdJmXQL6ahBHL6g1itReEwG9f8=
     ..

vpn vpn-peer1
    (...)
    local-address 10.125.0.1
    remote-address 10.175.0.2
    local-id myid1.6wind.net

vpn vpn-peer2
    (...)
    local-address 10.125.0.1
    remote-address 10.185.0.3
    local-id myid2.6wind.net

Pre-shared key verification ¶

During the IKE_AUTH exchange, the receiver of an IKE message must select the right pre-shared key to verify the signature of the message and authenticate the peer.

The IKE message contains at least the remote peer identity and optionally the local identity (otherwise it is considered unknown).

The signature verification procedure will check the signature against all pre-shared keys whose identity filters match the local-id or remote-id, until it finds one that produces the same signature (success) or all matching pre-shared keys have been tested, to no avail (failure). The pre-shared key is not necessarily the one with the best identity match.

Certificate authentication ¶

Certificate authentication performs authentication via public key cryptography.

Contrarily to pre-shared keys, certificates do not imply that the IKE peers exchange secret keys beforehand. To authenticate remote peers, an IKE endpoint simply needs to trust the certificate authority who delivered and signed the remote peers’ certificates.

Certificates enable to easily deploy a large number of IKE clients without maintaining and distributing a large list of secret keys (one for each pair of IKE peers) or weakening the system by using a single secret key shared between all IKE peers. It also avoids to modify the configuration of each peer when a new one is added.

Each IKE peer owns a digital certificate and a private key. The certificate embeds identity information and the matching public key. The certificate is delivered and signed by a Certificate Authority (CA), whose public key is stored in a CA certificate. The CA certificate enables to validate the authenticity of all certificates that it delivered.

Like for bank cards, CAs may also revoke a valid certificate before its expiration, for example in case of disclosure of the public key or the departure of an employee. To proceed, the CA may deliver a signed certificate revocation list (CRL), that lists revoked certificates.

Certificates, private keys and CRLs are stored in the Privacy Enhanced Mail (PEM) format in the global certificate store, or in the IKE configuration.

Certificates defined in the global certificate store ¶

All certificates stored in the global store are available to IKE, in all VRFs.

Additionally, CA certificates and local certificates may be locally defined in the IKE context. Locally defined certificates supersede certificates from the global store with the same name.

All CA certificates are trusted, all certificate/private-key pairs may be used to identify the host. However, it is possible to restrict the list of authorized certificates on a per-VPN basis.

The examples below use locally-defined certificates.

Local host authentication by certificate ¶

The local host certificate and private key must be installed in the certificate list:

vsr running ike# certificate secgw-a
vsr running certificate secgw-a#! certificate "====-BEGIN CERTIFICATE=====
... MIIB9jCCAV8CAQMwDQYJKoZIhvcNAQEEBQAwUzETMBEGA1UEChMKNldJTkQgUy5B
... LjEOMAwGA1UEBxMFUGFyaXMxCzAJBgNVBAYTAkZSMR8wHQYDVQQDExZIZWFkcXVh
... cnRlcnMgQXV0aG9yaXR5MB4XDTE4MDkxOTEzMjM1MloXDTE5MDkxOTEzMjM1Mlow
... NDELMAkGA1UEBhMCRlIxEzARBgNVBAoTCjZXSU5EIFMuQS4xEDAOBgNVBAMTB1Nl
... Y0dXLUEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOuCfHphepTnllpX/emq
... IMjW35RAm3TSSHSgDvBm/QtBHgJgLd53ANGbRQ7olinx7jA+CrbrBM9BdEXdR7So
... Q9++munDep/Eb9vu55mMm/leZ8xnV4jIDjLmHCP/AMPNYzKVJHPCElDIbLsbvHIq
... 8A6CYaQOi7NkOrkRY9q3LiEzAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAdSmnAN5+
... eRh7WuxuAlSGJh1PWb3NzrSKcbJnMPMz1qCqVhvQiGTQNIE5rpr6AlJN7LZV/wvS
... ng4yIizgehU0fluNfAroTEOoxq06m39YZPoY6mUNk82kRq3YTEx+j9EizRjePHzk
... jfYhCQITZa0atkjpfI143bO/k1NVC9exBv0=
... ====-END CERTIFICATE====-"
vsr running certificate secgw-a#! private-key "====-BEGIN PRIVATE KEY=====
... MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBAOuCfHphepTnllpX
... /emqIMjW35RAm3TSSHSgDvBm/QtBHgJgLd53ANGbRQ7olinx7jA+CrbrBM9BdEXd
... R7SoQ9++munDep/Eb9vu55mMm/leZ8xnV4jIDjLmHCP/AMPNYzKVJHPCElDIbLsb
... vHIq8A6CYaQOi7NkOrkRY9q3LiEzAgMBAAECgYB7IBoiBUqIBNeXXf9ypS5Esgnr
... wSdFGRcmWfPVfZJ3ytB8n3n7n62+5/VfyPuQ7FoBwL3rSc2W6Xp3eCuf6ISquXy8
... zNIB2EY4dzXWpzA9E8+0nZiO8dzFyphM0BFN44pwSazrgD0ZSnXQbxzFBwm5+VvC
... cxSpR/A+53bxDklAIQJBAPnMBvgHdtZATV4rzUN42l//McSGgba1GklICul5rIk/
... GhkGLVLgRaxsJoM3myV7lwA/7jJwXX3ypnJEO2uODXECQQDxW6JTUK5N2/0idS1i
... +Y/cEhgv0c7e3zTvTK3qe5t6Q1A2+1n6mpjk4iRSAfsiEMudnUFIBqbCpyZ1/GeV
... 2JbjAkAPau1fL67BCJT94/w2VuY7mJesxpSI/2KQ9VZfFLh2fCOTOdNgUyFZxA8Y
... eD0mMhue01NTX6YVmP12/gkg2VKxAkAUMkLHDf1H7pykAYImwhNTqv/zIG9bHvpi
... +9uhv24nMPLJZwcEfWNF49Z+NkQ5eYZQThRkXoodx7bkMJbKZzFZAkEA+R+jxmK/
... /XiiT7zizYaWW5x/PQrGvpfOehmlcp11+uO3ILDolNqD7gde98P9Rlc2xXF++K8I
... 3yyFFRutrqwKjw==
... ====-END PRIVATE KEY====-"
vsr running certificate secgw-a# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    certificate secgw-a
        certificate "====-BEGIN CERTIFICATE=====
MIIB9jCCAV8CAQMwDQYJKoZIhvcNAQEEBQAwUzETMBEGA1UEChMKNldJTkQgUy5B
LjEOMAwGA1UEBxMFUGFyaXMxCzAJBgNVBAYTAkZSMR8wHQYDVQQDExZIZWFkcXVh
cnRlcnMgQXV0aG9yaXR5MB4XDTE4MDkxOTEzMjM1MloXDTE5MDkxOTEzMjM1Mlow
NDELMAkGA1UEBhMCRlIxEzARBgNVBAoTCjZXSU5EIFMuQS4xEDAOBgNVBAMTB1Nl
Y0dXLUEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOuCfHphepTnllpX/emq
IMjW35RAm3TSSHSgDvBm/QtBHgJgLd53ANGbRQ7olinx7jA+CrbrBM9BdEXdR7So
Q9++munDep/Eb9vu55mMm/leZ8xnV4jIDjLmHCP/AMPNYzKVJHPCElDIbLsbvHIq
8A6CYaQOi7NkOrkRY9q3LiEzAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAdSmnAN5+
eRh7WuxuAlSGJh1PWb3NzrSKcbJnMPMz1qCqVhvQiGTQNIE5rpr6AlJN7LZV/wvS
ng4yIizgehU0fluNfAroTEOoxq06m39YZPoY6mUNk82kRq3YTEx+j9EizRjePHzk
jfYhCQITZa0atkjpfI143bO/k1NVC9exBv0=
====-END CERTIFICATE====-"
        private-key "====-BEGIN PRIVATE KEY=====
MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBAOuCfHphepTnllpX
/emqIMjW35RAm3TSSHSgDvBm/QtBHgJgLd53ANGbRQ7olinx7jA+CrbrBM9BdEXd
R7SoQ9++munDep/Eb9vu55mMm/leZ8xnV4jIDjLmHCP/AMPNYzKVJHPCElDIbLsb
vHIq8A6CYaQOi7NkOrkRY9q3LiEzAgMBAAECgYB7IBoiBUqIBNeXXf9ypS5Esgnr
wSdFGRcmWfPVfZJ3ytB8n3n7n62+5/VfyPuQ7FoBwL3rSc2W6Xp3eCuf6ISquXy8
zNIB2EY4dzXWpzA9E8+0nZiO8dzFyphM0BFN44pwSazrgD0ZSnXQbxzFBwm5+VvC
cxSpR/A+53bxDklAIQJBAPnMBvgHdtZATV4rzUN42l//McSGgba1GklICul5rIk/
GhkGLVLgRaxsJoM3myV7lwA/7jJwXX3ypnJEO2uODXECQQDxW6JTUK5N2/0idS1i
+Y/cEhgv0c7e3zTvTK3qe5t6Q1A2+1n6mpjk4iRSAfsiEMudnUFIBqbCpyZ1/GeV
2JbjAkAPau1fL67BCJT94/w2VuY7mJesxpSI/2KQ9VZfFLh2fCOTOdNgUyFZxA8Y
eD0mMhue01NTX6YVmP12/gkg2VKxAkAUMkLHDf1H7pykAYImwhNTqv/zIG9bHvpi
+9uhv24nMPLJZwcEfWNF49Z+NkQ5eYZQThRkXoodx7bkMJbKZzFZAkEA+R+jxmK/
/XiiT7zizYaWW5x/PQrGvpfOehmlcp11+uO3ILDolNqD7gde98P9Rlc2xXF++K8I
3yyFFRutrqwKjw==
====-END PRIVATE KEY====-"
        ..

Then the local-auth-method must be set to certificate in the ike-policy-template used by the VPN (or overridden in the VPN ike-policy).

Finally, the list of certificate candidates to use for authentication is specified in the VPN certificate command. The certificate used for authentication is selected based on the received certificate request payloads. If no appropriate CA can be located, the first certificate is used.

The IKE id used by the local host must be stored in its certificate, in the subjectName or in the subjectAltNames section.

vsr running ike# vpn siteA-roadw
vsr running vpn siteA-roadw#! ike-policy
vsr running ike-policy#! template iketemp1
vsr running ike-policy#! local-auth-method certificate
vsr running ike-policy#! ..
vsr running vpn siteA-roadw#! ipsec-policy template ipsectemp1
vsr running vpn siteA-roadw# certificate secgw-a
vsr running vpn siteA-roadw# ..
vsr running ike#

vsr running ike# show config
ike
    (...)
    vpn siteA-roadw
        ike-policy
            template iketemp1
            local-auth-method certificate
            ..
        ipsec-policy
            template ipsectemp1
            ..
        certificate secgw-a
        ..
    ..

Remote peer authentication by certificate ¶

The certificate authority that issued the certificates that remote peers will present must be declared in the certificate-authority list:

vsr running ike# certificate-authority hq-authority
vsr running certificate-authority hq-authority# certificate "====-BEGIN CERTIFICATE=====
... MIIC2zCCAkSgAwIBAgIJAJpUB7T8zBYBMA0GCSqGSIb3DQEBBAUAMFMxEzARBgNV
... BAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcTBVBhcmlzMQswCQYDVQQGEwJGUjEfMB0G
... A1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhvcml0eTAeFw0xODA5MTkxMzE5MTNaFw0x
... ODEwMTkxMzE5MTNaMFMxEzARBgNVBAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcTBVBh
... cmlzMQswCQYDVQQGEwJGUjEfMB0GA1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhvcml0
... eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA2mWsQQ14SSkx0Qp5eXXHMkAV
... OEyIJVD3dVPrcQkeCUR38KPrA8Dmlt/KLTrTfat6+/wxS1HywCLYR3U1+CrEQmR+
... kC/NgcNC+QqXyevb+2LTT606oHMQ6XckWIDhhD6JszN0dtcAci1SMgaKIoaoxElu
... TwIdDBkj8W7gnpn84k8CAwEAAaOBtjCBszAMBgNVHRMEBTADAQH/MB0GA1UdDgQW
... BBSN5H+zxbYDk/kVJuqimYsT2oDGDTCBgwYDVR0jBHwweoAUjeR/s8W2A5P5FSbq
... opmLE9qAxg2hV6RVMFMxEzARBgNVBAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcTBVBh
... cmlzMQswCQYDVQQGEwJGUjEfMB0GA1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhvcml0
... eYIJAJpUB7T8zBYBMA0GCSqGSIb3DQEBBAUAA4GBAEvu9Rj1dUcQsFywseZdZcC7
... 9jxhHtml1naxqDp/krPG/GJiSiCypQOGjbcXlRa2NOtLU7DwZTKH3S3fw8TBIAen
... 7vbQFLUtzrZ07TW4wnmtBtGd7GVqAZVIoUnkldVHhHL6hGy2DM+3e8+lptx8+tb6
... U/7s2V3Bm/HkQRq8+Gji
... ====-END CERTIFICATE====-"
vsr running certificate-authority hq-authority# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    certificate-authority hq-authority
        certificate "====-BEGIN CERTIFICATE=====
MIIC2zCCAkSgAwIBAgIJAJpUB7T8zBYBMA0GCSqGSIb3DQEBBAUAMFMxEzARBgNV
BAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcTBVBhcmlzMQswCQYDVQQGEwJGUjEfMB0G
A1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhvcml0eTAeFw0xODA5MTkxMzE5MTNaFw0x
ODEwMTkxMzE5MTNaMFMxEzARBgNVBAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcTBVBh
cmlzMQswCQYDVQQGEwJGUjEfMB0GA1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhvcml0
eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA2mWsQQ14SSkx0Qp5eXXHMkAV
OEyIJVD3dVPrcQkeCUR38KPrA8Dmlt/KLTrTfat6+/wxS1HywCLYR3U1+CrEQmR+
kC/NgcNC+QqXyevb+2LTT606oHMQ6XckWIDhhD6JszN0dtcAci1SMgaKIoaoxElu
TwIdDBkj8W7gnpn84k8CAwEAAaOBtjCBszAMBgNVHRMEBTADAQH/MB0GA1UdDgQW
BBSN5H+zxbYDk/kVJuqimYsT2oDGDTCBgwYDVR0jBHwweoAUjeR/s8W2A5P5FSbq
opmLE9qAxg2hV6RVMFMxEzARBgNVBAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcTBVBh
cmlzMQswCQYDVQQGEwJGUjEfMB0GA1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhvcml0
eYIJAJpUB7T8zBYBMA0GCSqGSIb3DQEBBAUAA4GBAEvu9Rj1dUcQsFywseZdZcC7
9jxhHtml1naxqDp/krPG/GJiSiCypQOGjbcXlRa2NOtLU7DwZTKH3S3fw8TBIAen
7vbQFLUtzrZ07TW4wnmtBtGd7GVqAZVIoUnkldVHhHL6hGy2DM+3e8+lptx8+tb6
U/7s2V3Bm/HkQRq8+Gji
====-END CERTIFICATE====-"
        ..
vsr running ike#

Then to authenticate the remote peer by certificates, the remote-auth-method must be set to certificate in the ike-policy-template used by the VPN (or overridden in the VPN ike-policy).

Finally, the CA certificates to trust for the authentication of the remote peer must be specified in the VPN remote-ca-certificate list.

The IKE id used by the remote peer must be stored in its certificate, in the subjectName or in the subjectAltNames section.

vsr running ike# vpn siteA-roadw
vsr running vpn siteA-roadw#! ike-policy
vsr running ike-policy#! template iketemp1
vsr running ike-policy#! remote-auth-method certificate
vsr running ike-policy#! ..
vsr running vpn siteA-roadw#! ipsec-policy template ipsectemp1
vsr running vpn siteA-roadw# remote-ca-certificate hq-authority
vsr running vpn siteA-roadw# ..
vsr running ike#

vsr running ike# show config
ike
    (...)
    vpn siteA-roadw
        ike-policy
            template iketemp1
            remote-auth-method certificate
            ..
        ipsec-policy
            template ipsectemp1
            ..
        remote-ca-certificate hq-authority
        ..
    ..

Manage revocation of remote peer certificates ¶

Using certificates usually implies to handle certificate revocations.

To manually add a CRL, in PEM format:

vsr running ike# certificate-authority hq-authority
vsr running certificate-authority hq-authority# crl "====-BEGIN X509 CRL=====
... MIIByjCCATMCAQEwDQYJKoZIhvcNAQEEBQAwUzETMBEGA1UEChMKNldJTkQgUy5B
... LjEOMAwGA1UEBxMFUGFyaXMxCzAJBgNVBAYTAkZSMR8wHQYDVQQDExZIZWFkcXVh
... cnRlcnMgQXV0aG9yaXR5Fw0xODA5MTkxMzI2MTlaFw0xODEwMTkxMzI2MTlaMBQw
... EgIBARcNMTgwOTE5MTMyMzM0WqCBlTCBkjCBgwYDVR0jBHwweoAUjeR/s8W2A5P5
... FSbqopmLE9qAxg2hV6RVMFMxEzARBgNVBAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcT
... BVBhcmlzMQswCQYDVQQGEwJGUjEfMB0GA1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhv
... cml0eYIJAJpUB7T8zBYBMAoGA1UdFAQDAgEBMA0GCSqGSIb3DQEBBAUAA4GBAAtY
... 3gXNIMwMjH6rafv9wI5qrDCwOp7KNdcrZbNuV/RURJ9mle8EPJ01PJSnxPMuIuzX
... VGbgjRxagWAQLlj4bkhHiqiezThi0D5xTSmmmXEZ52oK5GVDjElWU9OZeK1vssLL
... PK9DsxuURw0RP32iv6l68qwaPdI4tR0K8wcVXPn9
... ====-END X509 CRL====-"
vsr running certificate-authority hq-authority# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    certificate-authority hq-authority
        certificate (...)
        crl "====-BEGIN X509 CRL=====
MIIByjCCATMCAQEwDQYJKoZIhvcNAQEEBQAwUzETMBEGA1UEChMKNldJTkQgUy5B
LjEOMAwGA1UEBxMFUGFyaXMxCzAJBgNVBAYTAkZSMR8wHQYDVQQDExZIZWFkcXVh
cnRlcnMgQXV0aG9yaXR5Fw0xODA5MTkxMzI2MTlaFw0xODEwMTkxMzI2MTlaMBQw
EgIBARcNMTgwOTE5MTMyMzM0WqCBlTCBkjCBgwYDVR0jBHwweoAUjeR/s8W2A5P5
FSbqopmLE9qAxg2hV6RVMFMxEzARBgNVBAoTCjZXSU5EIFMuQS4xDjAMBgNVBAcT
BVBhcmlzMQswCQYDVQQGEwJGUjEfMB0GA1UEAxMWSGVhZHF1YXJ0ZXJzIEF1dGhv
cml0eYIJAJpUB7T8zBYBMAoGA1UdFAQDAgEBMA0GCSqGSIb3DQEBBAUAA4GBAAtY
3gXNIMwMjH6rafv9wI5qrDCwOp7KNdcrZbNuV/RURJ9mle8EPJ01PJSnxPMuIuzX
VGbgjRxagWAQLlj4bkhHiqiezThi0D5xTSmmmXEZ52oK5GVDjElWU9OZeK1vssLL
PK9DsxuURw0RP32iv6l68qwaPdI4tR0K8wcVXPn9
====-END X509 CRL====-"
        ..
    ..

To add a CRL distribution point, specify the LDAP or HTTP URI. CRLs must be encoded in DER binary format on the distribution server.

vsr running ike# certificate-authority hq-authority
vsr running certificate-authority hq-authority# crl-uri ldap://hq-authority.6wind.net
vsr running certificate-authority hq-authority# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    certificate-authority hq-authority
        certificate (...)
        crl (...)
        crl-uri ldap://hq-authority.6wind.net
        ..
    ..

Note

IKE service can use certificates that exist in the local database just by providing the certificate’s name. Note also that the service is refreshing those certificates whenever an update is made.

See also

Check certificates management commands for more details about how certificates are managed in the local database.

Set the revocation check policy of peer certificates ¶

The revocation check policy may be configured on a per-VPN basis. It is defined in the ike-policy-template and may be overridden in the vpn ike-policy.

vsr running ike# ike-policy-template iketemp1
vsr running ike-policy-template iketemp1# revocation if-url
vsr running ike-policy-template iketemp1# ..
vsr running ike#

See also

The command reference for the supported revocation policies.

Parsing and matching Distinguished Names ¶

During the authentication exchange, the IKE peers exchange their identities. In the case of certificate authentication, the identity is usually the subject of the certificate, hence a DN, a binary structure made itself of one or more RDNs.

Example: the DN /C=FR/O=6WIND/CN=uCPE842384 is composed of the following RDNs:

C=FR (Country France)
O=6WIND (Organization 6WIND)
CN=uCPE842384 (CommonName uCPE842384)

It is possible to restrict the identities of the peer accepted by a VPN, by setting the remote-id field. This field is a filter, that defines the expected RDNs, and possibly includes wildcards:

vsr running ike# vpn siteA-roadw
vsr running vpn siteA-roadw# vpn siteA-roadw
vsr running vpn siteA-roadw# remote-id /C=FR/O=6WIND/CN=*
vsr running vpn siteA-roadw# ..
vsr running ike# commit
vsr running ike#

There are several policies to match the DNs in a remote-id. The policy can be configured in the IKE global options:

vsr running ike# global-options
vsr running global-options# dn-matching relaxed
vsr running global-options# ..
vsr running ike# commit
vsr running ike#

Example: the VPN configuration specifies remote-id /C=FR/O=6WIND/CN=*. Here are examples of identities that would be accepted or refused depending on the dn-matching policy:

strict: the number, type, order and value of all RDNs must match. This is the default behavior.
- /C=FR/O=6WIND/CN=uCPE842384 accepted
- /CN=uCPE842384/C=FR/O=6WIND refused (different order)
- /C=FR/O=6WIND/OU=R&D/CN=uCPE842384 refused (additional RDN)
- /O=6WIND/CN=uCPE842384 refused (missing RDN)
- /C=FR/O=acme/CN=uCPE842384 refused (wrong Organization value)
reordered: the number, type and value of all RDNs must match, but the RDNs may appear in different order.
- /C=FR/O=6WIND/CN=uCPE842384 accepted
- /CN=uCPE842384/C=FR/O=6WIND accepted (different order)
- /C=FR/O=6WIND/OU=R&D/CN=uCPE842384 refused (additional RDN)
- /O=6WIND/CN=uCPE842384 refused (missing RDN)
- /C=FR/O=acme/CN=uCPE842384 refused (wrong Organization value)
relaxed: the type and value of all RDNs have to match. The IKE identity may contain more RDNs than the filter.
- /C=FR/O=6WIND/CN=uCPE842384 accepted
- /CN=uCPE842384/C=FR/O=6WIND accepted (different order)
- /C=FR/O=6WIND/OU=R&D/CN=uCPE842384 accepted (additional RDN)
- /O=6WIND/CN=uCPE842384 refused (missing RDN)
- /C=FR/O=acme/CN=uCPE842384 refused (wrong Organization value)

The wildcard value * is accepted for any RDN. It requires the presence of the RDN, whatever its value. It applies to the full RDN, not to a part of it. For example, /CN=uCPE* does NOT match all Common Names starting with uCPE, it only matches the value uCPE*.

See also

The command reference for the supported DN matching policies.

Showing the certificate cache ¶

The IKE service maintains a cache of certificates.

It includes certificates from the local IKE configuration and certificate repository, as well as certificates dynamically discovered during IKE negotiations (for example peer certificates or CA certificates).

To dump brief information about the certificates in the cache, use the following command:

vsr> show ike certificate
List of X.509 End Entity Certificates

  subject:   C=FR, O=6WIND, CN=dut
  issuer:    C=FR, O=6WIND, CN=root CA
  validity:  not-before: Sun Dec 10 11:32:06 2023
  validity:  not-after:  Wed Dec  9 11:32:06 2026
  serial:    6d:6f:6d:b2:fe:84:5e:ea
  altNames:  dut.6wind.com
  has-private-key: true

  subject:   C=FR, O=6WIND, CN=router
  issuer:    C=FR, O=6WIND, CN=root CA
  validity:  not-before: Sun Dec 10 11:32:06 2023
  validity:  not-after:  Wed Dec  9 11:32:06 2026
  serial:    1b:04:2d:ea:a2:be:6f:f9
  altNames:  router.6wind.com
  has-private-key: false

List of X.509 CA Certificates

  subject:   C=FR, O=6WIND, CN=root CA
  issuer:    C=FR, O=6WIND, CN=root CA
  validity:  not-before: Mon Dec 11 11:36:52 2023
  validity:  not-after:  Thu Dec 10 11:36:52 2026
  serial:    27:68:53:23:b3:cc:e1:c2
  has-private-key: false

Add the pem keyword to additionally output each certificate in PEM format:

vsr> show ike certificate pem
List of X.509 End Entity Certificates

  subject:   C=FR, O=6WIND, CN=dut
  issuer:    C=FR, O=6WIND, CN=root CA
  validity:  not-before: Sun Dec 10 11:32:06 2023
  validity:  not-after:  Wed Dec  9 11:32:06 2026
  serial:    6d:6f:6d:b2:fe:84:5e:ea
  altNames:  dut.6wind.com
  has-private-key: true
====-BEGIN CERTIFICATE=====
MIIDGTCCAgGgAwIBAgIIbW9tsv6EXuowDQYJKoZIhvcNAQELBQAwLzELMAkGA1UE
BhMCRlIxDjAMBgNVBAoTBTZXSU5EMRAwDgYDVQQDEwdyb290IENBMB4XDTIzMTIx
MDExMzIwNloXDTI2MTIwOTExMzIwNlowKzELMAkGA1UEBhMCRlIxDjAMBgNVBAoT
BTZXSU5EMQwwCgYDVQQDEwNkdXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC6+z5FX0xwmzFa2NsbS6Bigv2gz7buDa/JDrIxccH/Xu8qkTBc60keabgl
yTOzlkiEKUAFNDCdK2nN24lXZm85zbrqKiDmZGF5cjCZGXSRReFO8+0XpG7aclsn
nmlxtwOEO+xfoTgE3Ra5vDf6IwhonDKjIgZcXAZOik8XmwDxmnDq5rkipZkuHXkr
+rcF6kx8w85rpCe9qIzFwUP8miU3q5RrOK0HmFYD3+FY3cQ+8jfnhmWs8Y97rYKr
Bmk8hYimhpEawG8wTXh9yxbgz9IzNlIRA6M4idUNPTuui6QUk5XkrP164IB6xhiC
XdO7T/lDkDU538K5nzVwp7RUkqilAgMBAAGjPTA7MB8GA1UdIwQYMBaAFFaAHXqd
bfXbAPmCCam13K1ZsRPiMBgGA1UdEQQRMA+CDWR1dC42d2luZC5jb20wDQYJKoZI
hvcNAQELBQADggEBAJUQRbZNRiJrBOsDR/Qgws13ZoFO9ft5dwsir3hN957ogpNt
SOnkmmLlu5RGxJscCayrbOpN7OeYSh9VAEvYpG7mmZJnwHYIvHLavaug0oPsvLm/
c8bCpAoK8afpMswYB3/y8U7UhhE0dn4mjrwWOXd9c3zxoE67e1T72H2YTDZ03IVF
UdyyIMwSZ+9O2u+0JQJE9jzTIqsSmidMelfw3vpuzsTyhDfkMCT2OEiyr0DYR+FP
YeznGnXipTMQpmoqPHdKMghec8rP3bX4d+3xs1U7IvuSnF4rMoHd6o2wiGHsJMl3
Znpr4LZc8z/Ke0Ummjo3Lr3Lzli2F79/Z0hab6Y=
====-END CERTIFICATE=====

(...)

Use the details keyword to display detailed information about each certificate:

vsr> show ike certificate details
List of X.509 End Entity Certificates

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 7885642088090722026 (0x6d6f6db2fe845eea)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = FR, O = 6WIND, CN = root CA
        Validity
            Not Before: Dec 10 11:32:06 2023 GMT
            Not After : Dec  9 11:32:06 2026 GMT
        Subject: C = FR, O = 6WIND, CN = dut
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ba:fb:3e:45:5f:4c:70:9b:31:5a:d8:db:1b:4b:
                    a0:62:82:fd:a0:cf:b6:ee:0d:af:c9:0e:b2:31:71:
                    c1:ff:5e:ef:2a:91:30:5c:eb:49:1e:69:b8:25:c9:
                    33:b3:96:48:84:29:40:05:34:30:9d:2b:69:cd:db:
                    89:57:66:6f:39:cd:ba:ea:2a:20:e6:64:61:79:72:
                    30:99:19:74:91:45:e1:4e:f3:ed:17:a4:6e:da:72:
                    5b:27:9e:69:71:b7:03:84:3b:ec:5f:a1:38:04:dd:
                    16:b9:bc:37:fa:23:08:68:9c:32:a3:22:06:5c:5c:
                    06:4e:8a:4f:17:9b:00:f1:9a:70:ea:e6:b9:22:a5:
                    99:2e:1d:79:2b:fa:b7:05:ea:4c:7c:c3:ce:6b:a4:
                    27:bd:a8:8c:c5:c1:43:fc:9a:25:37:ab:94:6b:38:
                    ad:07:98:56:03:df:e1:58:dd:c4:3e:f2:37:e7:86:
                    65:ac:f1:8f:7b:ad:82:ab:06:69:3c:85:88:a6:86:
                    91:1a:c0:6f:30:4d:78:7d:cb:16:e0:cf:d2:33:36:
                    52:11:03:a3:38:89:d5:0d:3d:3b:ae:8b:a4:14:93:
                    95:e4:ac:fd:7a:e0:80:7a:c6:18:82:5d:d3:bb:4f:
                    f9:43:90:35:39:df:c2:b9:9f:35:70:a7:b4:54:92:
                    a8:a5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
           X509v3 Authority Key Identifier:
                56:80:1D:7A:9D:6D:F5:DB:00:F9:82:09:A9:B5:DC:AD:59:B1:13:E2
            X509v3 Subject Alternative Name:
                DNS:dut.6wind.com
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        95:10:45:b6:4d:46:22:6b:04:eb:03:47:f4:20:c2:cd:77:66:
        81:4e:f5:fb:79:77:0b:22:af:78:4d:f7:9e:e8:82:93:6d:48:
        e9:e4:9a:62:e5:bb:94:46:c4:9b:1c:09:ac:ab:6c:ea:4d:ec:
        e7:98:4a:1f:55:00:4b:d8:a4:6e:e6:99:92:67:c0:76:08:bc:
        72:da:bd:ab:a0:d2:83:ec:bc:b9:bf:73:c6:c2:a4:0a:0a:f1:
        a7:e9:32:cc:18:07:7f:f2:f1:4e:d4:86:11:34:76:7e:26:8e:
        bc:16:39:77:7d:73:7c:f1:a0:4e:bb:7b:54:fb:d8:7d:98:4c:
        36:74:dc:85:45:51:dc:b2:20:cc:12:67:ef:4e:da:ef:b4:25:
        02:44:f6:3c:d3:22:ab:12:9a:27:4c:7a:57:f0:de:fa:6e:ce:
        c4:f2:84:37:e4:30:24:f6:38:48:b2:af:40:d8:47:e1:4f:61:
        ec:e7:1a:75:e2:a5:33:10:a6:6a:2a:3c:77:4a:32:08:5e:73:
        ca:cf:dd:b5:f8:77:ed:f1:b3:55:3b:22:fb:92:9c:5e:2b:32:
        81:dd:ea:8d:b0:88:61:ec:24:c9:77:66:7a:6b:e0:b6:5c:f3:
        3f:ca:7b:45:26:9a:3a:37:2e:bd:cb:ce:58:b6:17:bf:7f:67:
        48:5a:6f:a6

(...)

You can filter the certificates by specifying their subject DN:

vsr> show ike certificate subject "C=FR, O=6WIND, CN=dut"
List of X.509 End Entity Certificates

  subject:   C=FR, O=6WIND, CN=dut
  issuer:    C=FR, O=6WIND, CN=root CA
  validity:  not-before: Sun Dec 10 11:32:06 2023
  validity:  not-after:  Wed Dec  9 11:32:06 2026
  serial:    6d:6f:6d:b2:fe:84:5e:ea
  altNames:  dut.6wind.com
  has-private-key: true

Or a SAN:

vsr> show ike certificate subject router.6wind.com
List of X.509 End Entity Certificates

  subject:   C=FR, O=6WIND, CN=router
  issuer:    C=FR, O=6WIND, CN=root CA
  validity:  not-before: Sun Dec 10 11:32:06 2023
  validity:  not-after:  Wed Dec  9 11:32:06 2026
  serial:    1b:04:2d:ea:a2:be:6f:f9
  altNames:  router.6wind.com
  has-private-key: false

Flushing the certificate cache ¶

The certificates dynamically learn during IKE negotiations may be flushed from the cache.

To flush dynamically learnt certificates from the cache, use the following command:

vsr> flush ike certificate
Successfully flushed certificates

After this command, dynamically learnt certificates are deleted; locally configured certificates remain in the cache:

vsr> show ike certificate
List of X.509 End Entity Certificates

  subject:   C=FR, O=6WIND, CN=dut
  issuer:    C=FR, O=6WIND, CN=root CA
  validity:  not-before: Sun Dec 10 11:32:06 2023
  validity:  not-after:  Wed Dec  9 11:32:06 2026
  serial:    6d:6f:6d:b2:fe:84:5e:ea
  altNames:  dut.6wind.com
  has-private-key: true

List of X.509 CA Certificates

  subject:   C=FR, O=6WIND, CN=root CA
  issuer:    C=FR, O=6WIND, CN=root CA
  validity:  not-before: Mon Dec 11 11:36:52 2023
  validity:  not-after:  Thu Dec 10 11:36:52 2026
  serial:    27:68:53:23:b3:cc:e1:c2
  has-private-key: false

Showing the CRL cache ¶

The IKE service maintains a cache of CRLs.

It includes CRLs from the local IKE configuration, as well as CRLs dynamically discovered during IKE negotiations (for example downloaded CRLs).

To dump brief information about the CRLs in the cache, use the following command:

vsr> show ike crl
  issuer:    C=FR, O=6WIND, CN=root CA
  update:    last: Mon Dec 11 12:39:28 2023
  update:    next: Tue Dec 26 12:39:28 2023
  serial:    02
  2 revoked certificates
    ba:dc:0f:fe: Mon Dec 11 12:39:28 2023, reason superseded
    ff:42: Mon Dec 11 12:38:12 2023, reason key-compromise

Add the pem keyword to additionally output each CRLs in PEM format:

vsr> show ike crl pem
  issuer:    C=FR, O=6WIND, CN=root CA
  update:    last: Mon Dec 11 12:39:28 2023
  update:    next: Tue Dec 26 12:39:28 2023
  serial:    02
  2 revoked certificates
    ba:dc:0f:fe: Mon Dec 11 12:39:28 2023, reason superseded
    ff:42: Mon Dec 11 12:38:12 2023, reason key-compromise
====-BEGIN X509 CRL=====
MIIB9TCB3gIBATANBgkqhkiG9w0BAQsFADAvMQswCQYDVQQGEwJGUjEOMAwGA1UE
ChMFNldJTkQxEDAOBgNVBAMTB3Jvb3QgQ0EXDTIzMTIxMTEyMzkyOFoXDTIzMTIy
NjEyMzkyOFowSjAkAgUAutwP/hcNMjMxMjExMTIzOTI4WjAMMAoGA1UdFQQDCgEE
MCICAwD/QhcNMjMxMjExMTIzODEyWjAMMAoGA1UdFQQDCgEBoC8wLTAfBgNVHSME
GDAWgBRWgB16nW312wD5ggmptdytWbET4jAKBgNVHRQEAwIBAjANBgkqhkiG9w0B
AQsFAAOCAQEAJQmb6O8W8ISwIZOcYf0cRTrm1jszw5geGJAsgjwPkHFEb75bWTKk
743XfLCvPdN5GkXQPWUzVxKm5Cg7+ZVgbY0qEBPwyZY3Iil4+ac55Zwr/G9G2vbn
7++Jn02XR0uD+Dly9nhxUI+0HRywJZqs68zYrab6B3eiHLneD8gMl1hqCDbot1tO
5cl6H7nF+ElU5YsRnkYHFaJfkY+GhKXWre6oTiDKAGzn/C4clERmAsX0qtOsuuNW
GO4KwxMfV4JfbL1l1SRjUzMXB2nW7kvkfNno2lnavv/nrw1+pDBOomivNYIy04ZJ
tqOG0575jk+b1wyELeD8up6jbeZG+FSdoA==
====-END X509 CRL=====

Use the details keyword to display detailed information about each CRL:

vsr> show ike crl details
Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = FR, O = 6WIND, CN = root CA
        Last Update: Dec 11 12:39:28 2023 GMT
        Next Update: Dec 26 12:39:28 2023 GMT
        CRL extensions:
            X509v3 Authority Key Identifier:
                56:80:1D:7A:9D:6D:F5:DB:00:F9:82:09:A9:B5:DC:AD:59:B1:13:E2
            X509v3 CRL Number:
                2
Revoked Certificates:
    Serial Number: BADC0FFE
        Revocation Date: Dec 11 12:39:28 2023 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Superseded
    Serial Number: FF42
        Revocation Date: Dec 11 12:38:12 2023 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Key Compromise
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        25:09:9b:e8:ef:16:f0:84:b0:21:93:9c:61:fd:1c:45:3a:e6:
        d6:3b:33:c3:98:1e:18:90:2c:82:3c:0f:90:71:44:6f:be:5b:
        59:32:a4:ef:8d:d7:7c:b0:af:3d:d3:79:1a:45:d0:3d:65:33:
        57:12:a6:e4:28:3b:f9:95:60:6d:8d:2a:10:13:f0:c9:96:37:
        22:29:78:f9:a7:39:e5:9c:2b:fc:6f:46:da:f6:e7:ef:ef:89:
        9f:4d:97:47:4b:83:f8:39:72:f6:78:71:50:8f:b4:1d:1c:b0:
        25:9a:ac:eb:cc:d8:ad:a6:fa:07:77:a2:1c:b9:de:0f:c8:0c:
        97:58:6a:08:36:e8:b7:5b:4e:e5:c9:7a:1f:b9:c5:f8:49:54:
        e5:8b:11:9e:46:07:15:a2:5f:91:8f:86:84:a5:d6:ad:ee:a8:
        4e:20:ca:00:6c:e7:fc:2e:1c:94:44:66:02:c5:f4:aa:d3:ac:
        ba:e3:56:18:ee:0a:c3:13:1f:57:82:5f:6c:bd:65:d5:24:63:
        53:33:17:07:69:d6:ee:4b:e4:7c:d9:e8:da:59:da:be:ff:e7:
        af:0d:7e:a4:30:4e:a2:68:af:35:82:32:d3:86:49:b6:a3:86:
        d3:9e:f9:8e:4f:9b:d7:0c:84:2d:e0:fc:ba:9e:a3:6d:e6:46:
        f8:54:9d:a0

You can filter the CRLs by specifying their issuer DN:

vsr> show ike crl issuer "C=FR, O=6WIND, CN=root CA"
  issuer:    C=FR, O=6WIND, CN=root CA
  update:    last: Mon Dec 11 12:39:28 2023
  update:    next: Tue Dec 26 12:39:28 2023
  serial:    02
  2 revoked certificates
    ba:dc:0f:fe: Mon Dec 11 12:39:28 2023, reason superseded
    ff:42: Mon Dec 11 12:38:12 2023, reason key-compromise

Flushing the CRL cache ¶

The CRLs dynamically learn during IKE negotiations may be flushed from the cache.

To flush dynamically learnt CRLs from the cache, use the following command:

vsr> flush ike crl
Successfully flushed CRLs

After this command, dynamically learnt CRLs are deleted; locally configured CRLs remain in the cache.

EAP authentication ¶

EAP is typically used by a VPN concentrator accepting IKE connections, to authenticate remote clients via external methods (legacy methods such as EAP-MD5 or EAP-MSCHAPv2, mobile network methods such as EAP-SIM or EAP-AKA…). The authentication methods are usually asymmetric: the server is authenticated by pre-shared keys or a certificate, and the clients by EAP.

Local and remote peer EAP authentication ¶

Local and remote EAP keys may be stored in a local database. They are similar to pre-shared keys, but are used by EAP authentication methods. They are configured in the eap-key list.

These keys are looked up to authenticate IKE peers if the local-auth-method or remote-auth-method is set to eap-md5 or eap-mschapv2.

vsr running ike# eap-key user1key
vsr running eap-key user1key#! id user1@6wind.com
vsr running pre-shared-key user1key#! secret EAPpassword1
vsr running pre-shared-key user1key# ..
vsr running ike#

vsr running ike# show config
ike
    (...)
    eap-key user1key
        id user1@6wind.com
        secret EAPpassword1
        ..

Like pre-shared keys, EAP keys are assigned a name and are composed of two parts, a secret key and optional EAP identity filters (a list of EAP identities).

The encodings and selection rules are the same as for pre-shared keys, except that the EAP ID is taken into account instead of the IKE ID.

By default, the local identity used for the EAP authentication is the IKE identity (set by the local-id command, or by default the connection IKE address), but a specific EAP identity may be specified with the following command:

vsr running vpn vpn-to-hq# local-eap-id client1@6wind.com

Warning

If defined, the local-eap-id is only taken into account if the server initiates an EAP-Identity exchange and asks for an EAP identity. Otherwise, the IKE identity is used.

On the EAP client side, to authenticate the local host by EAP keys, the local-auth-method must be set to the right EAP method eap-mschapv2 or eap-md5 in the ike-policy-template used by the VPN:

vsr running ike# ike-policy-template ikepsk local-auth-method eap-mschapv2
vsr running ike# vpn vpn-hq ike-policy template ikepsk

Or overridden in the VPN ike-policy:

vsr running ike# vpn vpn-hq ike-policy local-auth-method eap-mschapv2

Similarly, on the EAP server side, to authenticate the remote peer by pre-shared keys, the remote-auth-method must be set to eap-mschapv2 or eap-md5 in the ike-policy-template used by the VPN, or overridden in the VPN ike-policy.

To filter the expected client EAP identity, the following command can be used:

vsr running vpn vpn-to-hq# remote-eap-id client1@6wind.com

Note

The special value %any makes the server initiate an EAP-Identity exchange and ask the client for its EAP identity.

Remote peer authentication by EAP via RADIUS ¶

On the server side, the EAP authentication of remote peers can be delegated to one or more RADIUS servers, the IKE daemon then acts as a simple proxy.

This delegation of EAP authentication to RADIUS servers is configured by selecting eap-radius as the remote authentication method, and by declaring one or more EAP RADIUS servers in the eap-radius list.

Select eap-radius as the remote authentication method in the VPN IKE policy:

vsr running ike# vpn mytunnel
vsr running vpn mytunnel#! ike-policy
vsr running ike-policy#! template basic_policy
vsr running ike-policy#! remote-auth-method eap-radius
vsr running ike-policy#! ..
vsr running vpn mytunnel#! ..
vsr running ike#!

Configure an EAP RADIUS server. The minimal parameters are the server IP address and an authentication secret.

vsr running ike# eap-radius
vsr running eap-radius# server server-tnr
vsr running server server-tnr#! address 10.200.0.1
vsr running server server-tnr#! secret testing123
vsr running server server-tnr# ..
vsr running eap-radius# ..

Show the EAP RADIUS server configuration:

vsr running ike# show config eap-radius
eap-radius
    nas-identifier 6WINDvsr
    auth-port 1812
    sockets 1
    retransmit-tries 4
    retransmit-timeout 2.0
    retransmit-base 1.4
    server server-tnr
        address 10.200.0.1
        secret testing123
        ..
    ..

A RADIUS server may be in a VRF different from the IKE daemon, typically in a corporate network instead of the public network. It can be specified in the server configuration:

vsr running ike# eap-radius
vsr running eap-radius# server server-tnr
vsr running server server-tnr# address 10.200.0.1
vsr running server server-tnr# vrf private
vsr running server server-tnr# ..
vsr running eap-radius# ..

Since RADIUS exchanges are synchronous, it is recommended to enable parallel exchanges by setting the sockets parameter: it specifies the number of concurrent requests that can be sent to a RADIUS server (each from a different local UDP port).

A common parameter exists:

vsr running ike# eap-radius sockets 5

This can be overridden by a per-server parameter:

vsr running ike# eap-radius server server-tnr sockets 5

Similarly, a source IP may be specified either globally or per-server:

vsr running ike# eap-radius source 10.200.0.6
vsr running ike# eap-radius server server-tnr source 10.200.0.12

Remote peer authentication by PSK via RADIUS ¶

Pre-shared keys used for authentication can be stored by one or more RADIUS servers as 6WIND vendor attributes and retrieved on demand by the IKE daemon.

When authenticating an IKE SA an Access-Request message will be sent to one of the configured RADIUS servers, using the configured password and the IKE SA remote-id as the username. The pre-shared key is then obtained by way of a vendor attribute attached to the Access-Accept response from the RADIUS server. Specifically an ike:psk-remote 6WIND-AVPair attribute.

See also

6WIND Vendor-Specific attributes

This authentication method applies to all VPN IKE policies that use pre-shared keys as an authentication method, but is only enabled if both a password and at least one RADIUS server are configured. It also only applies if the peer’s remote-id is a domain name (ID_FQDN), an email address (ID_RFC822_ADDR) or an IPv4 address (ID_IPV4_ADDRESS). These IKE identities are converted to strings (dot-decimal notation for IPv4 addresses) to serve as the username for the RADIUS authentication.

Configure a RADIUS server. The minimal parameters are the server IP address and an authentication secret.

vsr running ike# psk-radius
vsr running psk-radius# server server-tnr
vsr running server server-tnr#! address 10.200.0.1
vsr running server server-tnr#! secret testing123
vsr running server server-tnr#! ..
vsr running psk-radius#!

Configure a password for RADIUS user authentication:

vsr running psk-radius#! password GlobalUserPassword
vsr running psk-radius# ..

Note

This password is used only for RADIUS user authentication and is common to all RADIUS users. IKE authentication will be done using the PSK provided through the relevant RADIUS attributes as previously described.

Show the RADIUS server configuration:

vsr running ike# show config psk-radius
psk-radius
    password radiuspassword
    nas-identifier 6WINDvsr
    auth-port 1812
    sockets 1
    retransmit-tries 4
    retransmit-timeout 2.0
    retransmit-base 1.4
    server server-tnr
        address 10.200.0.1
        secret testing123
        ..
    ..

A RADIUS server may be in a VRF different from the IKE daemon, typically in a corporate network instead of the public network. It can be specified in the server configuration:

vsr running ike# psk-radius
vsr running psk-radius# server server-tnr
vsr running server server-tnr# address 10.200.0.1
vsr running server server-tnr# vrf private
vsr running server server-tnr# ..
vsr running psk-radius# ..

Since RADIUS exchanges are synchronous, it is recommended to enable parallel exchanges by setting the sockets parameter: it specifies the number of concurrent requests that can be sent to a RADIUS server (each from a different local UDP port).

A common parameter exists:

vsr running ike# psk-radius sockets 5

This can be overridden by a per-server parameter:

vsr running ike# psk-radius server server-tnr sockets 5

Similarly, a source IP may be specified either globally or per-server:

vsr running ike# psk-radius source 10.200.0.6
vsr running ike# psk-radius server server-tnr source 10.200.0.12

See also

RADIUS attribute support

A FreeRADIUS configuration example ¶

Using PSK RADIUS authentication requires that the RADIUS server be configured to send 6WIND vendor attributes. How this can be done will depend on the RADIUS implementation, but an example using the FreeRADIUS implementation is provided here.

A dictionary will be necessary for FreeRADIUS to recognize and use 6WIND vendor attributes. Here is the complete 6WIND vendor dictionary for FreeRADIUS:

VENDOR 6WIND 7336
BEGIN-VENDOR 6WIND
ATTRIBUTE 6WIND-AVPair 1 string
END-VENDOR 6WIND

You may then create users and configure the attributes for each. Here is how a user making use of PSK authentication via RADIUS might be configured for FreeRADIUS:

user1@example.com   Cleartext-Password := "GlobalUserPassword"
   Framed-IP-Address = 10.0.0.1,
   6WIND-AVPair = "ike:psk-remote=user1psk"

See also

RADIUS attribute support