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. Maximum number of minutes the IKE SA life can live for. | |
| 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.0.1 address. If an IP address, it does not have to be an address that exists on the BIG-IP, however the remote peer must be configured to expect the address (the remote peer's own "verified ID"). | |
| 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.