Last updated on: June 16 2024.

IKE-Peer

This page explains IKE Peer (ike-peer) options and lists common mistakes.

Configuration Elements

To view the configuration in tmsh, use the tmsh list net ipsec ike-peer command.

Screenshot from the BIG-IP web UI.

The following table lists each setting as seen in the web UI, with the tmsh parameter’s name.

Element tmsh Neg* Explanation
Name
No Arbitrary name of peer.
Partition / Path
No Partition that the peer is created in.
Description
No Arbitrary description.
Remote Address
No Host
IP of the remote peer. This is not actually negotiated, but you must
declare a remote endpoint for the tunnel to work. The anonymous ike-peer
profile does exist for situations where you want to respond to any
ISAKMP initiator.
State
No Enabled
Version
Yes IKE(v1) or IKEv2 or both
Authentication Algorithm
Yes Must match with peer.
Encryption Algorithm
Yes Must match with peer.
Perfect Forward Secrecy
Yes Must match with peer.
Lifetime
Yes Does not have to match peer configuration.
Authentication Method
Yes Must match with peer. A certificate can be used if "RSA Signature" is selected. ECDSA is also supported in version 12.
Preshared Key
Yes You see this if Preshared Key is selected as the Authentication Method. Otherwise you'd have to select a certificate.
Verify Preshared Key
-
Mode
Yes Main or aggressive. Aggressive is faster but weaker from a security standpoint. Everyone should use Main Mode.
NAT Traversal
Yes Support
for NAT-D (NAT detection) is declared and if both hosts support it then
they check whether a NAT is in-path. If a NAT is detected, after phase1
is complete then phase2 will negotiate over UDP port 4500. If one peer
declared NAT-D support but the other does not, negotiation can still be
successful, but a NAT will not be detected.
Passive
?
Presented ID Type
Yes This
is declared but in general phase1 will not fail unless the other peer
is told to check what has been sent. There are a variety of name-based
options for IKEv1 but commonly an IP address is used. Mandatory for
IKEv2.
Presented ID
Yes Override or Automatic (IKEv1 only).
Presented ID Value
Yes By default the BIG-IP will send the localhost 127.0.01 address. This is not necessarily the actual IP of the remote peer.
Verified ID Type
Yes This section tells the BIG-IP to check the remote peer's declared ID. Mandatory for IKEv2.
Verified ID
Yes Override or Automatic (IKEv1 only).
Verified ID Value
Yes The host IP declared by the remote peer. This is not necessarily the actual IP of the remote peer.
Proxy Support
Yes This is always negotiated and changing this value will always lead to a tunnel negotiation failure.
DPD Delay
No DPD support is declared but not negotiated. The endpoints do not have to agree on the delay either.
Replay Window Size
?

*Neg = Negotiated.

  • “Yes” means that SA negotiation can fail if the peers disagree.

  • “No” means not part of SA negotiation or does not cause a negotiation failure.

Common Configuration Problems

Mismatched encryption and authentication algorithms are a common problem. The BIG-IP allows the user to configure different algorithms on the ike-peer and the ipsec-policy. Some vendors expect them to be the same.

When IKEv2 is used the PFS setting is inherited from the ike-peer config. While it is possible to configure PFS in the ipsec-policy, the ike-peer value will be used.

Top | Flowchart | Contents