Next
IKE Authentication
Previous
IKE Proposal
In IKE, each party must ensure it is communicating with the correct peer. Oneaspect of this validation is the identity information included in IKE. Eachrouter tells the other its own local identity and they each validate it againstthe stored remote identity. If they do not match, the peer is rejected.
From within config-ipsec-crypto-ike mode, use the identity local andidentity 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 theremote peer during the exchange. The remote identity is used to validate theidentity received from the peer during the exchange.
Note
For site-to-site tunnels the remote ID corresponds to a single peer, whereasfor remote access IPsec there can be many peers.
For remote access IPsec the remote IKE ID is typically %any (with a typeof none) so TNSR can accept connections from clients no matter which IDthey present. Clients vary in how they send the ID, some allow the user toset a specific value, others assume the value (e.g. IP address or EAPusername). Given the lack of uniformity in client behavior, the best practiceis to allow any remote identifier from remote access clients. When using EAP,the client identity is validated as part of authentication, so this does notpresent 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.3or2001:db8:1:2::3)This is the most common type, with the value set to the address on TNSRused as the
local-addressfor 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 administratorof the remote peer so that it can properly identify this endpoint.
Warning
When using site-to-site certificate authentication the type and value of theidentity configuration must match values present in the certificate inorder for the IPsec daemon to locate, match, and validate the correctcertificate 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 IPaddress, using the same value as the local address of the IPsec tunnel.
tnsr(config-ipsec-crypto-ike)# identity localtnsr(config-ike-identity)# type addresstnsr(config-ike-identity)# value 203.0.113.2tnsr(config-ike-identity)# exit
Next, configure the remote identity. The remote peer has also chosen to use anIP address, the value of which is the remote address used for the IPsec tunnel.
tnsr(config-ipsec-crypto-ike)# identity remotetnsr(config-ike-identity)# type addresstnsr(config-ike-identity)# value 203.0.113.25tnsr(config-ike-identity)# exit
