Tip

This is the documentation for the 24.06 version. Looking for the documentation of the latest version? Have a look here.

IPsec Keys¶

Inside config-ipsec-tunnel mode, the following commands are available for IPsec key management.

crypto config-type (ike|manual):

Configures the type of key management TNSR will use for this tunnel.

ike:: Internet Key Exchange (IKE). The most common method of key management. IPsec tunnels utilize IKE to dynamically handle key exchange when both parties are negotiating a security association.
manual:: Static key management.

crypto ike:

Enters IKE config-ipsec-crypto-ike mode to configure IPsec IKE behavior, which is the bulk of the remaining work for most IPsec tunnels.

IKE Configuration¶

Inside config-ipsec-crypto-ike mode, the following commands are available to configure basic IKE behavior:

authentication (local|remote):

Configures IKE authentication and enters config-ike-auth mode.

child <name>:

Configures Security Associations and enters ike-child mode.

dpd-interval <x>:

Optional time to wait between sending Dead Peer Detection (DPD) polls, given in seconds within the range 0-65535.

identity (local|remote):

Configures IKE identity validation and enters config-ike-identity mode.

key-renewal (reauth|rekey):

Controls the method used to update keys on an established IKE security association (SA) before the lifetime expires.

reauth:: TNSR performs a full teardown and re-establishment of IKE and child SAs.
rekey:: Inline rekeying while SAs stay active. Only available in IKEv2.

lifetime <x>:

Sets the maximum time for this IKE session to be valid, in seconds within the range 120..214783647. Default value is 14400 seconds (4 hours). Commonly set to 28800 seconds (8 hours). This value should be longer than the IKE child lifetime, discussed later.

mobike:

Enables the MOBIKE mobility/multihoming extension. This extension allows IKEv2 to handle multi-homed clients and clients which roam between different IP addresses. This is primarily used with remote access clients so IPsec sessions can switch remote addresses while maintaining an active connection.

Enable this feature when remote peers must change addresses dynamically.

proposal <name>:

Configures a new IKE proposal and enters config-ike-proposal mode.

remote-access address-pools (ipv4-range|ipv6-range) <first-addr> to <last-addr>:

Configures IPv4 or IPv6 address pools for use with remote access IPsec. The first and last addresses given must be of the given address family and should lie within the prefix defined on the IPIP interface.

Note

The IPsec daemon limits the possible size of an address pool to around 2^31 addresses. If a /64 IPv6 prefix range is defined for the pool, it may be truncated down to a /97 or smaller.

remote-access address-pools radius:

Indicates that the IPsec daemon should allocate addresses for connecting remote access clients based on RADIUS reply attributes (framed-ip-address, framed-ipv6-address).

Note

This can only be used when a remote access tunnel is configured for EAP-RADIUS.

This feature can work together with IPv4 and IPv6 address-pool entries as needed. When address pools are configured, addresses returned by RADIUS take priority, but if the RADIUS server does not return an address in the access-accept response, then clients are allocated addresses from the configured pools. This logic is applied for IPv4 and IPv6 independently.

remote-access dns resolver <num> address <address>:

Configures a list of individual DNS server IP addresses which are passed to connecting remote access IPsec clients. Each entry must have a unique ID <num> value.

udp-encapsulation:

Forces UDP encapsulation for IKE, also known as NAT Traversal or NAT-T.

Under normal conditions, UDP encapsulation will be automatically activated when NAT is detected and automatically disabled otherwise. With udp-encapsulation set, UDP encapsulation is forcefully enabled.

Note

UDP encapsulation cannot be disabled, it can only be automatically controlled or forcefully enabled.

unique-id-policy (keep|never|no|replace):

Controls how the IPsec daemon treats new connections with an identifier which matches an existing connection. In most cases a new connection is intended to replace an older connection, but certain use cases may require multiple connections from the same remote identifier, such as remote access clients.

keep:

The new connection is rejected and the existing connection remains active.

This ensures new connections do not interfere with existing sessions but if a client must make a new connection the old connection must terminate or timeout before a new connection can establish.

never:

Never enforce peer identifier uniqueness.

The new connection is always allowed and INITIAL_CONTACT notifications are ignored. This allows a single user to connect multiple clients without interrupting their existing sessions.

no:

Do not enforce peer ID uniqueness unless initial contact notify received. This is the default behavior.

The new connection is accepted and the old connection is replaced only if the peer sends an INITIAL_CONTACT notification.

replace:

The new connection is accepted by the IPsec daemon and it replaces the old connection, which is disconnected.

This allows clients to reconnect when they need to do so, but if a single user has two separate clients attempting to connect at the same time they could repeatedly disconnect each other.

version <x>:

Instructs TNSR to use either IKEv1 or IKEv2. Use 2 for IKEv2, which is more secure, or 1 for IKEv1 which is more common and more widely supported.

Additional config-ipsec-crypto-ike mode commands are available to configure other aspects of the IPsec tunnel, such as proposals, identity, and authentication. These are covered next.

IKE Example¶

This example tells TNSR to use IKE for key management, and then sets the tunnel to IKEv2 and a lifetime of 8 hours.

tnsr(config-ipsec-tunnel)# crypto config-type ike
tnsr(config-ipsec-tunnel)# crypto ike
tnsr(config-ipsec-crypto-ike)# version 2
tnsr(config-ipsec-crypto-ike)# lifetime 28800

Additional IKE Configuration¶

The remainder of the IKE configuration is covered in the following sections.