IKE Identity

In IKE, each party must ensure it is communicating with the correct peer. One aspect of this validation is the identity information included in IKE. Each router tells the other its own local identity and they each validate it against the stored remote identity. If they do not match, the peer is rejected.

From within config-ipsec-crypto-ike mode, use the identity local and identity remote commands to configure local and remote identity information. In either case, the identity command enters config-ike-identity mode.

IKE requires both local and remote identities. The local identity is sent to the remote peer during the exchange. The remote identity is used to validate the identity received from the peer during the exchange.

Note

For site-to-site tunnels the remote ID corresponds to a single peer, whereas for remote access IPsec there can be many peers.

For remote access IPsec the remote IKE ID is typically %any (with a type of none) so TNSR can accept connections from clients no matter which ID they present. Clients vary in how they send the ID, some allow the user to set a specific value, others assume the value (e.g. IP address or EAP username). Given the lack of uniformity in client behavior, the best practice is to allow any remote identifier from remote access clients. When using EAP, the client identity is validated as part of authentication, so this does not present a significant security concern.

In config-ike-identity, the following commands are available:

type <name>:

Sets the type of identity value. The following types are available:

address:

IPv4 or IPv6 address in the standard notation for either (e.g. 192.0.2.3 or 2001:db8:1:2::3)

This is the most common type, with the value set to the address on TNSR used as the local-address for the IPsec tunnel.

dn:

An X.509 distinguished name, such as a certificate subject (e.g. /CN=ipsec-auth-1/C=US/ST=Texas/L=Austin/O=Netgate/OU=Engineering)

email:

Email address (e.g. user@example.com).

fqdn:

A fully qualified domain name (e.g. host.example.com)

key-id:

An arbitrary string used as an identity

none:

Automatically interpret the type based on the value

value <text>:

The identity value, in a format corresponding to the chosen type.

Note

The local identity type and value must both be supplied to the administrator of the remote peer so that it can properly identify this endpoint.

Warning

When using site-to-site certificate authentication the type and value of the identity configuration must match values present in the certificate in order for the IPsec daemon to locate, match, and validate the correct certificate entries. In most cases this means using the certificate subject (DN) of each peer, but can also work with Subject Alternative Name (SAN) entries if they are present in the certificate data.

Identity Example

First configure the local identity of this firewall. The identity is an IP address, using the same value as the local address of the IPsec tunnel.

tnsr(config-ipsec-crypto-ike)# identity local
tnsr(config-ike-identity)# type address
tnsr(config-ike-identity)# value 203.0.113.2
tnsr(config-ike-identity)# exit

Next, configure the remote identity. The remote peer has also chosen to use an IP address, the value of which is the remote address used for the IPsec tunnel.

tnsr(config-ipsec-crypto-ike)# identity remote
tnsr(config-ike-identity)# type address
tnsr(config-ike-identity)# value 203.0.113.25
tnsr(config-ike-identity)# exit