Authentication

Contains the unique name of this entry. You assign this name to the connections in the Connection list in the "Authentication" field.

Sets the authentication method for the local identity. Possible values are:

PSK: Pre-shared key:
RSA-Signature: Use of digital certificates with private RSA key and RSA signature scheme
Digital signature: Use of configurable authentication methods with digital certificates as per RFC 7427. This procedure is an extensible and flexible authentication technique that allows padding and hash algorithms to be configured freely.
ECDSA-256, ECDSA-384, ECDSA-521: Use of Elliptic Curve Digital Signature Algorithm (ECDSA) according to RFC 4754 for authentication. ECDSA signatures are generally smaller than RSA signatures with comparable cryptographic strength. ECDSA keys and certificates also have significantly smaller file sizes than RSA-based keys and certificates. Furthermore, ECDSA operations are generally faster on most devices. The following methods are supported in IKEv2.
- ECDSA with SHA-256 on the P-256 curve
- ECDSA with SHA-384 on the P-384 curve
- ECDSA with SHA-512 on the P-521 curve
Note:
When using OpenSSL, the following predefined curves must be used as parameters for ECDSA in IKEv2:
- prime256v1 with ECDSA-256
- secp384r1 with ECDSA-384
- secp521r1 with ECDSA-512
Note: The following restrictions apply when using ECDSA:
- ECDSA-based certificates currently cannot be generated by the LCOS‘s own CA. Similarly, it is not possible to obtain certificates automatically by means of SCEP. ECDSA certificates must be generated using an external application such as OpenSSL or XCA and then loaded into the device.

The device uses the authentication method configured here when connecting to the remote site. The method must match with a corresponding configuration at the remote site. It is possible to use different authentication methods for the local and remote authentication. For example, the headquarters can identify itself by RSA signature, while branch offices or clients use PSK authentication.

The profile name of the local digital signature profile that is used.

Defines the ID type of the local identity. The device interprets the entry under "Local identifier" accordingly. Possible entries are:

No identity: No identity is transmitted.
IPv4 address: The device uses an IPv4 address as a local ID.
IPv6 address: The device uses an IPv6 address as a local ID.
Domain name (FQDN): The device uses a domain name as a local ID.
E‑mail address (FQUN): The device uses an e‑mail address as a local ID.
ASN.1 Distinguished Name: The device uses a distinguished name as a local ID (e.g. "CN=client01.example.com,O=test,C=DE").
Key ID (group name): The device uses the group name as a local ID. You can set any group name.

Contains the local identity. The significance of this entry depends on the setting under "Local identifier type".

Contains the password of the local identity. The device uses this password to authenticate at the remote site. The local and remote password can be identical or different.

Sets the authentication method for the remote identity. Possible values are:

PSK: Pre-shared key:
RSA-Signature: Use of digital certificates with private RSA key and RSA signature scheme
Digital signature: Use of configurable authentication methods with digital certificates as per RFC 7427. This procedure is an extensible and flexible authentication technique that allows padding and hash algorithms to be configured freely.
ECDSA-256, ECDSA-384, ECDSA-521: Use of Elliptic Curve Digital Signature Algorithm (ECDSA) according to RFC 4754 for authentication. ECDSA signatures are generally smaller than RSA signatures with comparable cryptographic strength. ECDSA keys and certificates also have significantly smaller file sizes than RSA-based keys and certificates. Furthermore, ECDSA operations are generally faster on most devices. The following methods are supported in IKEv2.
- ECDSA with SHA-256 on the P-256 curve
- ECDSA with SHA-384 on the P-384 curve
- ECDSA with SHA-512 on the P-521 curve
Note:
When using OpenSSL, the following predefined curves must be used as parameters for ECDSA in IKEv2:
- prime256v1 with ECDSA-256
- secp384r1 with ECDSA-384
- secp521r1 with ECDSA-512
Note: The following restrictions apply when using ECDSA:
- ECDSA-based certificates currently cannot be generated by the LCOS‘s own CA. Similarly, it is not possible to obtain certificates automatically by means of SCEP. ECDSA certificates must be generated using an external application such as OpenSSL or XCA and then loaded into the device.
EAP: Extensible Authentication Protocol AP is not a specific authentication mechanism, but rather a framework for various authentication methods such as TLS (authentication by certificate) or MSCHAP (authentication by username/password). EAP authentication is handled by an external RADIUS server, such as the LANCOM RADIUS server, FreeRADIUS or Microsoft Network Policy Server (NPS). The VPN gateway merely acts as a mediator between the client and the RADIUS server. The VPN gateway must authenticate itself to the client using a certificate with a valid RSA signature. The RADIUS server must also have a valid certificate. The necessary certificates can be generated, for example, with the LANCOM SCEP CA in the router. After generation, the appropriate certificate containers are imported into the VPN gateway and into the RADIUS server. To use the IKEv2 EAP authentication feature on LANCOM routers, you will need the VPN-25 Option or a router with 25 or more VPN tunnels. Check whether the router supports IKEv2 EAP in the LCOS Status menu under Status > Software-Info > IKEv2-EAP-License. See also EAP and IEEE 802.1X.

The device uses the authentication method configured here when connecting to the remote site. The method must match with a corresponding configuration at the remote site. It is possible to use different authentication methods for the local and remote authentication. For example, the headquarters can identify itself by RSA signature, while branch offices or clients use PSK authentication.

The profile name of the remote digital signature profile.

Specify an EAP profile if the method for the Remote authentication was set to EAP. The EAP profiles are specified under EAP profiles.

Displays the ID type that the device expects from the remote identifier. The device interprets the entry under "Remote identifier" accordingly. Possible entries are:

No identity: The device accepts any ID from the remote device. The device to ignores entries in the "Remote identifier" field.
IPv4 address: The device expects an IPv4 address as the remote ID.
IPv6 address: The device expects an IPv6 address as the remote ID.
Domain name (FQDN): The device expects a domain name as the remote ID.
E‑mail address (FQUN): The device expects an e‑mail address as the remote ID.
ASN.1 Distinguished Name: The device expects a distinguished name as a remote ID (e.g. "CN=client01.example.com,O=test,C=DE").
Key ID (group name): The device expects the group name as the remote ID.

Contains the remote identity. The significance of this entry depends on the setting under "Remote identifier type".

Contains the password of the remote identity.

Redundant VPN scenarios allow the use of alternative remote identities. Here you configure additional remote identities from the table Extended settings > Identity list.

Specify the local VPN certificate used by the device for outbound connections. The corresponding VPN certificates "VPN1" to "VPN9" have to be configured under Certificates > SCEP client in the Certificate table.

This option determines whether the device checks that the specified remote identity is included in the received certificate.

With this setting you enable the real-time check of a X.509 certificate via OCSP, which checks the validity of the remote station's certificate. In order to use the OCSP check for individual VPN connections, you must first enable the global OCSP client for VPN connections and then create profile lists of the valid certificate authorities used by the device to perform the real-time check.

This setting enables the checking of an X.509 certificate by certificate revocation list (CRL), which checks the validity of the remote station's certificate.

Important: You should only switch this off if you are checking by other means, e.g. with OSCP.