Cloud Setup VNS3 VNS3 Management System VNS3 LNKe VNS3 NATe VNS3 PeopleVPN Network Edge Plugins Upgrading IPsec Troubleshooting Guide
IPsec Troubleshooting Guide

Table of Contents

Overview of IPsec

IPsec: Internet Protocol Security

  • IPsec is a set of protocols defined by the IETF, to provide IP security at the network layer.
  • An IPsec based VPN is made up of two parts.
    • Internet Key Exchange protocol (IKE), underlying port UDP 500
    • IPsec protocol (ESP), underlying Protocol 50 or if using “nat-traversal” UDP 4500
  • Basically there is an initial brief interaction where one or each of the devices attempt to discover each other, via the Internet, they then trade Phase 1 (IKE) parameters and attempt to get a Phase 1 (sometimes called IKE or ISAKMP) connection which creates the keys used to encrypt Phase2. They then trade Phase 2 parameters and attempt to create an encrypted Phase 2 (sometimes called IPSec SA or ESP) tunnel connection.
  • They then transport data back and forth as well as maintain the connection with some additional administrative traffic.

IPsec with VNS3

IPsec tunnels negotiated with VNS3 require the following:

  • Policy-based VPN - encapsulates traffic between two sites as defined by a specific policy or ACL. This is used instead of a Route-based VPN that encapsulates traffic based on routes on both sides which can make it easier to administer but downgrades the security.
  • Encapsulating Security Packet (ESP) wire level protocol - encrypting and authenticating of the data flowing over the tunnel. This is used instead of Authenication Header (AH) which only authenticates.
  • Tunnel Mode - encapsulates the entire IP packet for communication over untrusted networks. This is used instead of Transport mode that only encapsulates the IP payload.
  • Internet Key Exchange (IKE) - protocol used to setup the shared security associations (SA) for the IPsec tunnel. This is used instead of manual key exchange.
  • Main Mode - used to setup the IPsec tunnel SAs using IKE. This is used instead of Aggressive mode that requires fewer messages to establish the SA but does so in a less secured manner.
  • Preshared Key (PSK) - used for authentication between two connecting parties. This is used instead of certificates.

IPsec Parameters

IPsec Parameters

  • Endpoint IP Addresses - Of course you need to know the Public IP of your IPsec device and your partner/customer’s IPsec device.
  • Phase 1 and Phase 2 parameters
    • If your Phase 1 and Phase 2 parameters match exactly - there are almost no instances where you will not have a successful connection.
    • If they DO NOT match exactly - even if you get an initial connection - it is highly unlikely you will have a stable, long running connection.
  • Optional Parameters
    • Dead Peer Detection (DPD) which significantly enhance the stability and recovery of your connection in the event of problems in the underlying network connectivity (your LAN, Internet, Cloud Provider, etc..)
    • Compatibility parameters for un-usual situations, sometimes needed by VNS3
  • Other Parameters
    • There are some other, usually older or very vendor specific parameters not supported by VNS3

Phase 1 Parameters

  • NAT-Traversal enabled or not
  • Pre-shared Key (PSK)
  • IKE Peer ID (usually automatic, will cover examples of where not)
  • Phase 1 Algorithm
  • Phase 1 Hash
  • Phase 1 Diffie Hellman Group
  • Phase 1 Lifetime

Native IPsec or NAT-Traversal

  • Device wide setting in VNS3 v3, per Endpoint setting in v4+
  • Initial negotiations occur on UDP 500
  • NAT-T enabled communicates on UDP 4500
  • Native IPsec enabled communicates on Protocol 50 (not port 50)
  • NAT-T has NOTHING to do with nat-ing your traffic. It specifies whether the communication happens via UDP 4500 or Protocol 50

Pre-Shared Key or PSK

  • Pre-shared Key is the easiest form of interoperability.
  • The alternative is certificates for authentication; not interoperable, not supported by VNS3 today.
  • The PSK must be identical on both sides.
  • The number one reason for PSK issues is COPY/PASTE. It often introduces invisible characters. Ideally type them out.

IKE Peer ID

  • VNS3 has the concept of “Local Private IP”.
  • This is a persistent private IP used by NAT-Traversal.
  • VNS3 combines the Local Private IP with IKE Peer ID, and sends the Local Private IP setting as the IKE Peer ID as well.
  • The IKE Peer ID of your connection partner’s IPsec endpoint is the “REMOTE PEER ID”. (Of course your Local Private IP is your partner’s “REMOTE PEER ID”.)
  • You need to be clear on which point of view you are speaking from.

Phase 1

Algorithm

  • Phase 1 is sometimes called ISAKMP or IKE
  • Phase 1 algorithm is the encryption algorithm used for your phase 1
  • Choices are (in order of security):
    • AES256
    • AES128
    • 3DES

Hash

Phase 1 hash parameters in order of security:

  • sha2_512 (VNS3 3.5.1.13 and above)
  • sha2_384 (VNS3 3.5.1.13 and above)
  • sha2_256 (VNS3 3.5.1.13 and above)
  • sha1
  • md5

Diffie Hellman

Phase 1 Diffie Hellman groups in order of security:

  • 18 (VNS3 3.5.1.13 and above)
  • 17 (VNS3 3.5.1.13 and above)
  • 16 (VNS3 3.5.1.13 and above)
  • 15 (VNS3 3.5.1.13 and above)
  • 14 (VNS3 3.5.1.13 and above)
  • 5
  • 2
  • 19, 20, 21, 22, 23 ,24 ,31 (IKEv2 ONLY)

Lifetime

  • Phase 1 lifetime is most commonly done in number of seconds
  • Phase 1 lifetime MUST match connection partner to have a stable connection
  • Phase 1 common lifetimes are:
    • 3600s
    • 28800s
    • 86400s
  • Phase 1 and Phase 2 lifetimes CANNOT be identical on the same endpoint connection.

Phase 2

Parameters

  • Phase 2 Algorithm
  • Phase 2 Hash
  • Perfect Forward Secrecy (PFS) - optional
  • Diffie Hellman Group for PFS - use if PFS used
  • Phase 2 Lifetime
  • Subnet Offered
  • Subnet Requested

Algorithm

  • Phase 2 is sometimes called IPSEC or ESP
  • Phase 2 algorithm is the encryption algorithm used for your phase 2
  • Choices are (in order of security):
    • AES256
    • AES128
    • 3DES

Hash

  • Phase 2 hash parameters in order of security:
    • sha2_512 (VNS3 3.5.1.13 and above)
    • sha2_384 (VNS3 3.5.1.13 and above)
    • sha2_256 (VNS3 3.5.1.13 and above)
    • sha1
    • md5

Lifetime

  • Phase 2 lifetime is most commonly done in number of seconds
  • Phase 2 lifetime MUST match connection partner to have a stable connection
  • Phase 2 common lifetimes are:
    • 3600s
    • 28800s
    • 86400s
  • Phase 1 and Phase 2 lifetimes CANNOT be identical on the same endpoint connection.

Perfect Forward Secrecy (PFS)

  • PFS needs to be enabled, or disabled.
  • Both sides need to agree.
  • When enabled PFS uses a Diffie Hellman Key Exchange which needs an agreed upon group specification.

Diffie Hellman

  • PFS (Perfect Forward Secrecy) Diffie Hellman groups in order of security:
    • 18 (VNS3 3.5.1.13 and above)
    • 17 (VNS3 3.5.1.13 and above)
    • 16 (VNS3 3.5.1.13 and above)
    • 15 (VNS3 3.5.1.13 and above)
    • 14 (VNS3 3.5.1.13 and above)
    • 5

IPsec Parameters

  • Optional Parameters
    • Dead Peer Detection Enabled or Not
    • Dead Peer Detection Action
    • Dead Peer Detection “delay” or “retry” period
    • Dead Peer Detection “timeout” before declaring a peer dead and performing DPD action
  • Other Parameter choices unsupported by VPN3/VNS3
    • Main mode vs. Aggressive (VPN3/VNS3 is “Main” mode only)
    • Authentication Header (VPN3/VNS3 do not support Authentication Header or “AH”)
    • Tunnel vs. Transport Mode (VPN3/VNS3 is “Tunnel” mode only)
    • X509 Certificates vs. PSK (VPN3/VNS3 supports PSK authentication only)

Endpoint and IPsec Configuration

GUI Example Remote Endpoint and Tunnel Setup

The following sections show how to configure an example remote endpoint and IPsec tunnel in VNS3 via the GUI with page numbers referencing the configuration guide.

VNS3 IPsec

Click IPsec under Connections left menu heading.

The IPsec page displays configuration settings needed to negotiate IPsec VPN tunnels, as well as currently configured endpoints and tunnels.

Local Private IP

The Local private IP address is a static and controllable IP that can be used for negotiation and identification purposes and increases interoperability. Some physical network routing and security appliances will need this IP included in their side of a IPsec tunnel configuration as the Peer or IKE ID (Watchguard, Juniper, SonicWall).

Logging

Link to the IPsec log file. Do not enable verbose logging unless directed to do so by Cohesive.

VNS3 IPsec

IPsec Configuration: Define a New Remote Endpoint

To create an IPsec endpoint, click Define new remote endpoint.

Information entered on the Endpoint page should match the configuration of the remote endpoint you will connect to via IPsec.

Enter the following information:

  • Name - enter a name for the endpoint.
  • Public IP - The public IP of the remote endpoint. If the endpoint does not have a public IP enter the public IP of the intermediate device that will be performing NAT.
  • NAT-Traversal - NAT-Traversal encapsulation is no longer a device wide setting. It can be enabled on a Endpoint-by-Endpoint basis. If checked tunnel traffic will be encapsulated in UDP 4500. If unchecked, Native IPsec will be used and tunnel traffic will move over ESP Protocol 50. This setting needs to match the remote Endpoint’s setting.
  • IKEV1/IKEV2 - This toggle chooses whether to use IKEV1 or IKEV2. This setting needs to match the remote device configuration. If using IKEV2, leave NAT-Traversal unchecked as IKEV2 has a NAT auto detect feature.
  • Pre-Shared Key - enter a presider key and keep a record of that key to be entered on the remote IPsec device. We recommend using something simple during initial configuration to avoid any copy/paste errors.
  • NAT IP - if the remote device is behind NAT (there is an intermediary device between the endpoint and the public Internet), enter the remote endpoint’s private IP in this field. If the remote device is publicly accessible.
  • Extra Config Parameters - We recommend connecting to the Controller with tunnels using AES256 encryption and SHA authentication for both IKE and ESP. Extra Parameters syntax can be found on the following page. Please contact Cohesive Networks Support for assistance.

Click Create.

IPsec Configuration: Define a New Remote Endpoint

IPsec Configuration: Define a New Remote Endpoint

IPsec Configuration: Extra Parameters

VNS3’s IPSec subsystem is good at autodiscovery on IKE and ESP choices with a wide range of boxes. We recommend being as specific as possible when entering tunnel parameters. Match the algorithm, hash and DiffieH group for your gateway settings by specifying them in the “Extra Params” text field. We support combinations algorithms 3DES, AES128, or AES256; hashes SHA1, MD5, SHA2_256, or SHA2_512; and DH groups 2, 5, 14, 15, 16, 17, 18.

Example entries for IKE (Phase 1) and ESP (Phase 2) in the extra params box:

phase1=aes128-sha1
phase1=aes256-sha2_256
phase1=3des-md5-dh2
phase1=aes256-sha2_512-dh5
phase2=aes256-sha1
phase2=3des-sha1

PFS Group Extra params entry for PFS Group is technically required only when it must be different from pfs group in phase1. If that is the case, then use:

pfsgroup=dh2
pfsgroup=dh14

IKE and ESP Lifetimes

phase1-lifetime=3600s (default setting on VNS3)
phase2-lifetime=28800s (default setting on VNS3)

Dead Peer Detection - Disabled by default, to enable DPD to attempt to re-connect during periods of no response use the following:

dpdaction=restart (other options are “hold” meaning just wait, or “clear” meaning drop the security association)
dpddelay=30s
dpdtimeout=90s

Other, less frequently used options available are:

connection=bidirectional (default)
Other options are “receive” meaning to not initiate connections, only receive them.

connection-rekey=yes (default)
Other options are “no” meaning no Phase1 or Phase2 re-key operations are done.

compat:some-text This option should only be used at the instruction of Cohesive. It allows underlying parameters of the IPSec, BGP, Routing, Firewall, or SSL VPN subsystems to be passed straight into the environment with no parsing or validation. It is only used in a small fraction of interoperability situations.

IPsec Configuration: Setup a Tunnel

Once an IPsec Endpoint has been defined, you will need to configure the tunnel or VPN Policy that will allow tunneled traffic between two endpoints. This will include what subnet will be advertised behind each side of the connection as well as the authentication and encryption settings used. These configurations must match between the two sides of the connection.

Click New Tunnel.

Enter the Local Subnet that will be advertised behind the VNS3 Controller. In this example we used the Overlay Network Subnet of 172.31.1.0/24.

Enter the Remote Subnet that you wish to connect to your VNS3 Overlay Subnet. This will be provided by the party that is configuring the remote IPsec Endpoint.

Provide a name for the tunnel to allow for easy identification in more complex topologies (required).

External Ping provides a pinging functionality over the IPsec tunnel that can be used in addition to IPsec DPD and Keep Alive settings to ensure the tunnel remains up during low traffic periods.

Enter an IP address of a pingable server on the Remote Subnet specified.

Set the time interval (in seconds) for the ping.

Click Create.

![IPsec Configuration: Setup a Tunnel](https://cohesive-networks.s3.amazonaws.com/docs/images/troubleshooting-ipsec-config-setup-tunnel.png#medium ““IPsec Configuration: Setup a Tunnel)

IPsec Configuration: Connected Tunnel

Your VNS3 Controller IPsec setup is complete.

The next steps will detail setting the IPsec connection from a IPsec extranet device (In our example a Cisco ASA). These steps are often completed by a 3rd party that owns and manages the physical IPsec device.

When negotiating an IPsec connection with a device that is not in your control making sure the IPsec Endpoint and Tunnel configurations match on both sides of the connection is critical to the successful negotiation of the tunnel.

Note the “Configuration Settings” values, you will need these to correctly configure your extranet device.

Use our Connection Spreadsheet to help organize the information to be shared between the two sides of the tunnel.

Once the IPsec connection is live, this guide will detail how to add clients to the created overlay network.

IPsec Configuration: Connected Tunnel

IPsec configuration: VNS3 Application Programing Interface (API)

The following sections show how to configure an example remote endpoint and IPsec tunnel in VNS3 via the API with page numbers referencing the API guide.

VNS3 is fully programable and scriptable via the API, the instructions are available for download here:
http://www.cohesiveft.com/dnld/VNS3_API_v20120521.pdf

The VNS3 3.0 API Tool can be downloaded from here:
ZIP: http://www.cohesiveft.com/dnld/VNS3_API_Tool_20120704.zip
TAR: http://www.cohesiveft.com/dnld/VNS3_API_Tool_20120704.tar.gz

IPsec Configuration: Define a New Remote Endpoint

IPsec Configuration: Define a New Remote Endpoint

IPsec Configuration: Setup a Tunnel

IPsec Configuration: Setup a Tunnel

Some clarifications on VNS3 IPsec Parameters

Allowed Algorithms: 3des, aes128, aes256

Allowed Hashings: sha1, md5, sha2_256, sha2_512

Allowed DH Groups: 2, 5, 14, 15, 16, 17, 18

Phase 1 Combinations VNS3 Config IPSec Params 1

Phase 2 Combinations

  • 3des-sha1
  • 3des-md5
  • 3des-sha2_256
  • 3des-sha2_512
  • aes128-sha1
  • aes128-md5
  • aes128-sha2_256
  • aes128-sha2_512
  • aes256-sha1
  • aes256-md5
  • aes256-sha2_256
  • aes256-sha2_512
  • aes256_gcm (Phase 2 does NOT have a hash/integrity function setting such as sha1, sha2_256, etc.)
  • aes256_ccm (Phase2 only and there is no associated hash/integrity function such as sha1, sha2_256, etc.)

*AES256 with MD5 is not supported; it may appear to work but can be highly unstable. **AES256-SHA1 with DH=2 is not supported; it may appear to work but will be highly unstable.

Allowed pfsgroup settings:

  • The pfsgroup takes a Diffie Hellman group number as its setting; 2, 5, 14, 15, 16, 17, or 18.
  • Do not use DH=2 with a Phase 1 or Phase 2 Algorithm of AES256.
  • Avoid having a different DH group used for Phase 1 than the one used for pfsgroup setting.
    • Many endpoints do not properly shift from using one DH in Phase 1 to a different one in the PFS setting. It will not be documented as not supporting this, but our experience has taught us this is an unnecessary complexity to avoid.

Allowed lifetime settings

  • The lifetime settings for Phase 1 and Phase 2 CANNOT be identical to each other, this causes significant interoperability problems.
  • “Old school” approach is usually for keys to have longer lifetimes than tunnels
  • “New school” approach is many re-key events before a re-tunnel
  • Neither is more right than the other. In theory “new school” is more secure.
  • Lifetimes MUST MATCH IDENTICALLY between the two endpoints or tunnel can become unstable or hang.

Allowed DPD settings

  • DPD must be enabled explicitly in VNS3 or it will not operate.
  • The defaults shown in VNS3 documentation mean a tunnel could be down for 90 seconds before VNS3 will attempt to recover it.
  • Cohesive does not recommend using a dpddelay of less than 10 seconds, and dpdtimeout of less than 30 seconds. Please contact support@cohesive.net if you believe you have an applicable use case requiring shorter durations than this.

Less common settings:
connection, connection-rekey, and compat: are only used in rare circumstances. Please contact support@cohesive.net before attempting to use.

Troubleshooting via the logfiles

IKEv1 Phase 1: IPsec No Negotiation

Pattern Match STATE_MAIN_I1: retransmission;

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: initiating IKEv1 Main Mode connection
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: sent Main Mode request
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: STATE_MAIN_I1: retransmission; will wait 1 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: STATE_MAIN_I1: retransmission; will wait 2 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: STATE_MAIN_I1: retransmission; will wait 4 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: STATE_MAIN_I1: retransmission; will wait 8 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: STATE_MAIN_I1: retransmission; will wait 16 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: STATE_MAIN_I1: retransmission; will wait 32 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1060: STATE_MAIN_I1: 60 second timeout exceeded after 7 retransmits.  No response (or no acceptable response) to our first IKEv1 message

VNS3 controller has an endpoint configuration and a tunnel configuration (policy-based tunnel definition, route-based tunnel definition, or route-based traffic pair) but the remote peer is not responding to the VNS3 negotiation attempts.

Likely Causes
Remote peer does not have a matching IPsec configuration in place OR there is an intermediate firewall DROP action between the VNS3 controller and the remote IPsec peer.

IKEv1 Phase 1: PSK Mismatch

Pattern Match malformed payload in packet

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1068: probable authentication failure (mismatch of pre-shared secrets?): malformed payload in packet

Description
Pre-Shared Keys (PSK) are used to authenticate IPsec tunnel negotiations & are entered on both sides of the tunnel. If there is a mismatch due to incorrect entry or extra/invisible characters from copy/paste, or omission, Phase 1/IKE/ISAKMP will not succeed.

Likely Causes
PSK Mismatch. Verify the PSK is entered correctly. It is recommended something short & easily remembered like ‘test’ is used during initial tunnel configuration.

IKEv1 Phase 1: Parameter Mismatch

Pattern Match NO_PROPOSAL_CHOSEN

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1072: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP2048] refused
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1072: no acceptable Oakley Transform
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1072: sending notification NO_PROPOSAL_CHOSEN to 52.90.9.73:500

Description
The logs above demonstrate a mismatch hash (one side is set to sha1 and the other is set to sha2). Use the same parameters on both devices for Phase 1 negotiation. VNS3 can use an auto-discovery feature that attempts to match the settings of a customer’s remote device but we recommend against it.

Likely Causes
Phase 1 Mismatch on one or more of algorithm, hash, or DH group.

IKEv1 Phase 1: Peer ID Mismatch

Pattern Match INVALID_ID_INFORMATION

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #858: Peer ID is ID_IPV4_ADDR: '192.0.2.254'
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #858: Peer ID '192.0.2.254' mismatched on first found connection and no better connection found
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #858: sending encrypted notification INVALID_ID_INFORMATION to 50.16.83.11:4500

Description
Peer ID is used for authentication and this error will occur if there is a mismatch in IDs configured on VNS3 controller and the remote peer device.

Likely Causes
Other side provided a mismatched IKE Peer ID. Enter the appropriate value in the Peer ID field on VNS3.

IKEv1 Phase 2: Parameter Mismatch

Pattern Match IKE SA established followed by NO_PROPOSAL_CHOSEN

Log Symptom Initiator:

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #868: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #869: initiating Quick Mode IKEv1+PSK+ENCRYPT+TUNNEL+PFS+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES {using isakmp#868 msgid:fa22565b proposal=AES_CBC_256-HMAC_SHA1_96-MODP2048 pfsgroup=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #869: sent Quick Mode request
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #868: ignoring informational payload NO_PROPOSAL_CHOSEN, msgid=00000000, length=12

Responder:

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1096: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1096: the peer proposed: 100.100.101.0/24 -<all>-> 100.100.102.0/24
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1097: no acceptable Proposal in IPsec SA
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1097: sending encrypted notification NO_PROPOSAL_CHOSEN to 52.90.9.73:4500

Description
IKEv1 uses NO_PROPOSAL_CHOSEN error for parameter mismatch for both Phase 1 and Phase 2 Security Association (SA) negotiations. In this case we see the NO_PROPOSAL_CHOSEN error is preceded by a log message that includes “IKE SA established” that indicates a successful Phase 1 negotiation. Therefore the error is indicating a problem with the Phase 2 parameters.

Likely Causes
Mismatch of Phase 2 algorithm or hash.

IKEv1 Phase 2: Tunnel Definition / Traffic Selector Mismatch

Pattern Match IKE SA established followed by INVALID_ID_INFORMATION

Log Symptom

Initiator:

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #868: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #869: initiating Quick Mode IKEv1+PSK+ENCRYPT+TUNNEL+PFS+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES {using isakmp#868 msgid:fa22565b proposal=AES_CBC_256-HMAC_SHA1_96-MODP2048 pfsgroup=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #869: sent Quick Mode request
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #868: ignoring informational payload INVALID_ID_INFORMATION, msgid=00000000, length=12

Responder:

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1189: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1189: the peer proposed: 10.100.101.0/24 -<all>-> 10.100.102.0/24
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1190: responding to Quick Mode proposal {msgid:939146c5}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1190:     us: 100.100.101.0/24===192.0.2.254[50.16.83.11]  them: 52.90.9.73===100.100.102.0/24
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #858: sending encrypted notification INVALID_ID_INFORMATION to 50.16.83.11:4500

Description
IKEv1 uses INVALID_ID_INFORMATION error for Peer ID mismatch in Phase 1 and tunnel/traffic selector mismatch in Phase 2 Security Association (SA) negotiations. In this case we see the INVALID_ID_INFORMATION error is preceded by a log message that includes “IKE SA established” that indicates a successful Phase 1 negotiation. Therefore the error is indicating a problem with the tunnel definition / traffic selectors.

Likely Causes
Mismatch of tunnel definition / traffic selectors between the VNS3 controller and remote peer device.

IKEv1: Successful Negotiation

Pattern Match IPsec SA established

Log Symptom Initiator:

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #926: sent Main Mode I3
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #926: Peer ID is ID_IPV4_ADDR: '50.16.83.11'
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #926: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #927: initiating Quick Mode IKEv1+PSK+ENCRYPT+TUNNEL+PFS+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES {using isakmp#926 msgid:939146c5 proposal=AES_CBC_256-HMAC_SHA2_256_128-MODP2048 pfsgroup=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #927: sent Quick Mode request
Oct 10 09:00:00:000000: is_up conn=cftconn_1_C1_2 perf=100.100.101.0/24 local=100.100.102.0/24
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #927: IPsec SA established tunnel mode {ESPinUDP=>0xfbb5931b <0x00f05f81 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATD=50.16.83.11:4500 DPD=passive}

Responder:

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1189: sent Main Mode R2
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1189: Peer ID is ID_IPV4_ADDR: '52.90.9.73'
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1189: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1189: the peer proposed: 100.100.101.0/24 -<all>-> 100.100.102.0/24
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1190: responding to Quick Mode proposal {msgid:939146c5}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1190:     us: 100.100.101.0/24===192.0.2.254[50.16.83.11]  them: 52.90.9.73===100.100.102.0/24
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1190: sent Quick Mode reply, inbound IPsec SA installed, expecting confirmation tunnel mode {ESPinUDP=>0x00f05f81 <0xfbb5931b xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATD=52.90.9.73:4500 DPD=active}
Oct 10 09:00:00:000000: is_up conn=cftconn_1_C2_1 perf=100.100.102.0/24 local=100.100.101.0/24
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1190: IPsec SA established tunnel mode {ESPinUDP=>0x00f05f81 <0xfbb5931b xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATD=52.90.9.73:4500 DPD=active}

Description
All parameters match on both the VNS3 controller and remote peer device allowing the IKEv1 tunnel to negotiate.

Likely Causes
Good planning, communication, and coordination between the administrators of the VNS3 controller and remote peer device.

IKEv1 Phase 2: Successful Rekey

Pattern Match Initiator: sent Quick Mode request, to replace followed by IPsec SA established

Responder: IPsec SA established

Log Symptom

Initiator:

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #953: initiating Quick Mode IKEv1+PSK+ENCRYPT+TUNNEL+PFS+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES to replace #952 {using isakmp#951 msgid:afdc7392 proposal=AES_CBC_256-HMAC_SHA2_256_128-MODP2048 pfsgroup=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #953: sent Quick Mode request, to replace #952
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #953: IPsec SA established tunnel mode {ESPinUDP=>0x5eed33a1 <0xcf86dcab xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATD=50.16.83.11:4500 DPD=passive}

Responder:

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1241: the peer proposed: 100.100.101.0/24 -<all>-> 100.100.102.0/24
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1243: responding to Quick Mode proposal {msgid:afdc7392}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1243:     us: 100.100.101.0/24===192.0.2.254[50.16.83.11]  them: 52.90.9.73===100.100.102.0/24
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1243: sent Quick Mode reply, inbound IPsec SA installed, expecting confirmation tunnel mode {ESPinUDP=>0xcf86dcab <0x5eed33a1 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATD=52.90.9.73:4500 DPD=active}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1243: IPsec SA established tunnel mode {ESPinUDP=>0xcf86dcab <0x5eed33a1 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATD=52.90.9.73:4500 DPD=active}

Description
IKEv2 IPsec tunnel is appropriately replaced before the old Security Association (SA) is destroyed. Can check the periodicity of the rekeys to confirm Phase 2 lifetimes match.

Likely Causes
Good planning, communication, and coordination between the administrators of the VNS3 controller and remote peer device.

IKEv1 Dead Peer Detection (DPD) Action

Pattern Match DPD action

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1253: DPD action - restarting all connections that share this peer
Oct 10 09:00:00:000000: "cftconn_1_C2_1": terminating SAs using this connection
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1254: deleting state (STATE_QUICK_R2) aged 900.540683s and sending notification
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1254: ESP traffic information: in=7KB out=8KB
Oct 10 09:00:00:000000: is_down conn=cftconn_1_C2_1 perf=100.100.102.0/24 local=100.100.101.0/24

Description
Dead Peer Detection (DPD) is used to determine if a remote peer device is available and responding. When configured, VNS3 sends DPD R_U_THERE messages on the configured periodicity (default delay is 30s) and will take action (default action is restart) in the event no responses are received after a configured interval (default timeout is 3 messages or 90s). This log message will appear when there is an issue with the in-path network or the remote device stops responding to the VNS3 controller for another reason.

Likely Causes
DPD events are typically caused by in-path network issues at the connecting party’s edge but can be caused by other connectivity issues.

IKEv2 IKE_SA_INIT (Phase 1) Failure: Remote Device Not Responding

Pattern Match STATE_V2_PARENT_I1: retransmission;

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1": IKE SA proposals:
Oct 10 09:00:00:000000: "cftconn_1_C2_1":   1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048
Oct 10 09:00:00:000000: "cftconn_1_C2_1": Child SA proposals:
Oct 10 09:00:00:000000: "cftconn_1_C2_1":   1:ESP=AES_CBC_256-HMAC_SHA2_256_128-NONE-ENABLED+DISABLED
Oct 10 09:00:00:000000: "cftconn_1_C2_1": added IKEv2 connection
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: initiating IKEv2 connection
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: sent IKE_SA_INIT request
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: STATE_V2_PARENT_I1: retransmission; will wait 0.5 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: STATE_V2_PARENT_I1: retransmission; will wait 1 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: STATE_V2_PARENT_I1: retransmission; will wait 2 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: STATE_V2_PARENT_I1: retransmission; will wait 4 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: STATE_V2_PARENT_I1: retransmission; will wait 8 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: STATE_V2_PARENT_I1: retransmission; will wait 16 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: STATE_V2_PARENT_I1: retransmission; will wait 32 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1: STATE_V2_PARENT_I1: 60 second timeout exceeded after 7 retransmits.  No response (or no acceptable response) to our first IKEv2 message

Description
VNS3 controller has an endpoint configuration and a tunnel configuration (policy-based tunnel definition, route-based tunnel definition, or route-based traffic pair) but the remote peer is not responding to the VNS3 negotiation attempts.

Likely Causes
Remote peer does not have a matching IPsec configuration in place OR there is an intermediate firewall DROP action between the VNS3 controller and the remote IPsec peer.

IKEv2 IKE SA INIT (Phase 1) Failure: Remote Device Configuration is Incomplete or IKE Version Mismatch

Pattern Match

NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1": IKE SA proposals:
Oct 10 09:00:00:000000: "cftconn_1_C2_1":   1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048
Oct 10 09:00:00:000000: "cftconn_1_C2_1": Child SA proposals:
Oct 10 09:00:00:000000: "cftconn_1_C2_1":   1:ESP=AES_CBC_256-HMAC_SHA2_256_128-NONE-ENABLED+DISABLED
Oct 10 09:00:00:000000: "cftconn_1_C2_1": added IKEv2 connection
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: initiating IKEv2 connection
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: sent IKE_SA_INIT request
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: STATE_V2_PARENT_I1: retransmission; will wait 0.5 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: STATE_V2_PARENT_I1: retransmission; will wait 1 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: STATE_V2_PARENT_I1: retransmission; will wait 2 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: STATE_V2_PARENT_I1: retransmission; will wait 4 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: STATE_V2_PARENT_I1: retransmission; will wait 8 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: STATE_V2_PARENT_I1: retransmission; will wait 16 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: STATE_V2_PARENT_I1: retransmission; will wait 32 seconds for response
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #96: STATE_V2_PARENT_I1: 60 second timeout exceeded after 7 retransmits.  No response (or no acceptable response) to our first IKEv2 message

Description
VNS3 controller has an endpoint configuration and a tunnel configuration (policy-based tunnel definition, route-based tunnel definition, or route-based traffic pair) but the remote peer is responding to the VNS3 negotiation attempts with NO_PROPOSAL_CHOSEN error that does not contain the matching negotiation parameters (Payloads SA, KE, and Ni).

Likely Causes
Remote peer is responding to the VNS3 IKEv2 initiation packet but the remote configuration is incomplete (e.g. VNS3 Peer details but no tunnel definition) OR the remote peer is sending an IKEv1 response.

IKEv2 IKE SA INIT (Phase 1) Failure: Parameter Mismatch

Pattern Match

no local proposal matches remote proposals 1:IKE

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #118: no local proposal matches remote proposals 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP2048
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #118: responding to IKE_SA_INIT message (ID 0) from 52.90.9.73:500 with unencrypted notification NO_PROPOSAL_CHOSEN
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #118: encountered fatal error in state STATE_V2_PARENT_R0
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #118: deleting state (STATE_V2_PARENT_R0) aged 0.000147s and NOT sending notification
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #118: deleting IKE SA but connection is supposed to remain up; schedule EVENT_REVIVE_CONNS

Description
Both VNS3 and remote peer are exchanging negotiation packets but there is a mismatch in IKE Init (Phase1) negotiation.

Likely Causes
Phase 1 parameter mismatch between the VNS3 controller and remote peer device configurations.

IKEv2 IKE AUTH (Phase 2) Failure: PSK Mismatch

Pattern Match

AUTHENTICATION_FAILED

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #668: sent IKE_SA_INIT request
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #667: processing decrypted IKE_AUTH request: SK{IDi,AUTH,SA,TSi,TSr}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #667: WARNING: '50.16.83.11' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #667: authentication failed: computed hash does not match hash received from peer ID_IPV4_ADDR '52.90.9.73'
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #667: responding to IKE_AUTH message (ID 1) from 52.90.9.73:4500 with encrypted notification AUTHENTICATION_FAILED
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #667: encountered fatal error in state STATE_V2_PARENT_R1
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #667: deleting state (STATE_V2_PARENT_R1) aged 0.009206s and NOT sending notification
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #667: deleting IKE SA but connection is supposed to remain up; schedule EVENT_REVIVE_CONNS
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #668: WARNING: '50.16.83.11' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #668: sent IKE_AUTH request {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #668: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED

Description
Both VNS3 and remote peer are exchanging negotiation packets but an AUTHENTICATION_FAILED messages is received before an IKE SA is established.

Likely Causes
Mismatch of Pre-shared Secret (PSK) between the VNS3 controller and remote peer device.

IKEv2 IKE AUTH (Phase 2) Failure: Peer ID Mismatch

Pattern Match

AUTHENTICATION_FAILED

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #668: sent IKE_SA_INIT reply {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #668: processing decrypted IKE_AUTH request: SK{IDi,AUTH,SA,TSi,TSr}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #668: Peer ID '50.16.83.11' mismatched on first found connection and no better connection found
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #668: responding to IKE_AUTH message (ID 1) from 50.16.83.11:4500 with encrypted notification AUTHENTICATION_FAILED

Description
Both VNS3 and remote peer are exchanging negotiation packets but an AUTHENTICATION_FAILED error message is received before an IKE SA is established. There is added detail in the log messages that indicates the Peer ID mismatch.

Likely Causes
Mismatch of Peer IDs used for authentication on the VNS3 controller and remote peer device.

IKEv2 IKE AUTH (Phase 2) Failure: Tunnel Definition / Traffic Selector Mismatch

Pattern Match Initiator: IKE_AUTH response rejected Child SA with TS_UNACCEPTABLE

Responder: No IKEv2 connection found with compatible Traffic Selectors

Log Symptom Initiator:

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #529: sent IKE_SA_INIT request
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #529: WARNING: '52.90.9.73' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #529: sent IKE_AUTH request {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #529: WARNING: '52.90.9.73' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #529: initiator established IKE SA; authenticated using authby=secret and peer ID_IPV4_ADDR '50.16.83.11'
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #530: IKE_AUTH response rejected Child SA with TS_UNACCEPTABLE

Responder:

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #636: sent IKE_SA_INIT reply {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #636: processing decrypted IKE_AUTH request: SK{IDi,AUTH,SA,TSi,TSr}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #636: WARNING: '50.16.83.11' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #636: responder established IKE SA; authenticated using authby=secret and peer ID_IPV4_ADDR '52.90.9.73'
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #636: WARNING: '50.16.83.11' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #637: No IKEv2 connection found with compatible Traffic Selectors

Description
Both VNS3 and remote peer are exchanging negotiation packets and successfully establish an IKE SA (Phase 1) but there is a mismatch in tunnel definition / traffic selectors for the encryption domains configured on the VNS3 controller and remote peer device.

Likely Causes
Mismatch of tunnel definition / traffic selectors / encryption domains between the two connecting devices.

IKEv2 IKE AUTH (Phase 2) Failure: Parameter Mismatch

Pattern Match Initiator: IKE_AUTH response rejected Child SA with NO_PROPOSAL_CHOSEN

Responder: no local proposal matches remote proposals 1:ESP

Log Symptom Initiator:

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #612: sent IKE_SA_INIT request
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #612: WARNING: '50.16.83.11' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #612: sent IKE_AUTH request {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #612: WARNING: '50.16.83.11' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #612: initiator established IKE SA; authenticated using authby=secret and peer ID_IPV4_ADDR '52.90.9.73'
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #613: IKE_AUTH response rejected Child SA with NO_PROPOSAL_CHOSEN

Responder:

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #514: sent IKE_SA_INIT reply {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #509:00:00:000000: SK{IDi,AUTH,SA,TSi,TSr}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #509:00:00:000000: '52.90.9.73' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #514: responder established IKE SA; authenticated using authby=secret and peer ID_IPV4_ADDR '50.16.83.11'
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #509:00:00:000000: '52.90.9.73' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #515: no local proposal matches remote proposals 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=ENABLED;ESN=DISABLED
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #515: IKE_AUTH responder matching remote ESP/AH proposals failed, responder SA processing returned NO_PROPOSAL_CHOSEN

Description
Both VNS3 and remote peer are exchanging negotiation packets and successfully establish an IKE SA (Phase 1) but there is a mismatch in IKE Auth (Phase 2) negotiation.

Likely Causes
Phase 2 parameter mismatch between the VNS3 controller and remote peer device configurations.

IKEv2: Successful Negotiation

Pattern Match

rubik_pluto_updown: is_up

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #808: sent IKE_SA_INIT request
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #808: WARNING: '52.90.9.73' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #808: sent IKE_AUTH request {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #808: WARNING: '52.90.9.73' PSK length of 7 bytes is too short for PRF HMAC_SHA2_256 in FIPS mode (16 bytes required)
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #808: initiator established IKE SA; authenticated using authby=secret and peer ID_IPV4_ADDR '50.16.83.11'
Oct 10 09:00:00:000000: is_up conn=cftconn_1_C1_2 perf=100.100.101.0/24 local=100.100.102.0/24
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #809: initiator established Child SA using #808; IPsec tunnel [100.100.102.0-100.100.102.255:0-65535 0] -> [100.100.101.0-100.100.101.255:0-65535 0] {ESPinUDP/ESN=>0xe01f59e4 <0xb558df31 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATD=50.16.83.11:4500 DPD=passive}
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #810: new Child SA:
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #810:   1:ESP=AES_CBC_256-HMAC_SHA2_256_128-MODP2048-ENABLED+DISABLED
Oct 10 09:00:00:000000: "cftconn_1_C1_2" #810: proposal 1:ESP=AES_CBC_256-HMAC_SHA2_256_128-MODP2048-ENABLED SPI=0ac1cf0d chosen from remote proposals 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048;ESN=ENABLED;ESN=DISABLED[first-match]
Oct 10 09:00:00:000000: responder established Child SA using #808; IPsec tunnel [100.100.102.0-100.100.102.255:0-65535 0] -> [100.100.101.0-100.100.101.255:0-65535 0] {ESPinUDP/ESN=>0x0ac1cf0d <0xa349a188 xfrm=AES_CBC_256-HMAC_SHA2_256_128-MODP2048 NATD=50.16.83.11:4500 DPD=passive}

Description
All parameters match on both the VNS3 controller and remote peer device allowing the IKEv2 tunnel to negotiate.

Likely Causes
Good planning, communication, and coordination between the administrators of the VNS3 controller and remote peer device.

IKEv2: Successful Rekey

Pattern Match

rekeyed Child SA

Log Symptom

Initiator:

Oct 10 09:00:00:000000: "cftconn_1_C1_2" #825: initiator rekeyed Child SA #824 using #822; IPsec tunnel [100.100.102.0-100.100.102.255:0-65535 0] -> [100.100.101.0-100.100.101.255:0-65535 0] {ESPinUDP/ESN=>0x6571524e <0x3e2941d2 xfrm=AES_CBC_256-HMAC_SHA2_256_128-MODP2048 NATD=50.16.83.11:4500 DPD=passive}

Responder:

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1030: responder rekeyed Child SA #1029 using #1027; IPsec tunnel [100.100.101.0-100.100.101.255:0-65535 0] -> [100.100.102.0-100.100.102.255:0-65535 0] {ESPinUDP/ESN=>0x3e2941d2 <0x6571524e xfrm=AES_CBC_256-HMAC_SHA2_256_128-MODP2048 NATD=52.90.9.73:4500 DPD=passive}

Description
IKEv2 IPsec tunnel is appropriately replaced before the old Security Association (SA) is destroyed. Can check the periodicity of the rekeys to confirm Phase 2 lifetimes match.

Likely Causes
Good planning, communication, and coordination between the administrators of the VNS3 controller and remote peer device.

IKEv2: Liveness Action (Dead Peer Detection - DPD)

Pattern Match

liveness action

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1032: liveness action - restarting all connections that share this peer
Oct 10 09:00:00:000000: "cftconn_1_C2_1": terminating SAs using this connection
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1032: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 94.291375s and sending notification
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1033: ESP traffic information: in=278B out=1KB
Oct 10 09:00:00:000000: is_down conn=cftconn_1_C2_1 perf=100.100.102.0/24 local=100.100.101.0/24

Description
IKEv2 liveness is very similar to IKEv1 Dead Peer Detection which is used to determine if a remote peer device is available and responding. When configured, VNS3 sends liveness checks on the configured periodicity (default delay is 30s) and will take action (default action is restart) in the event no responses are received after a configured interval (default timeout is 3 messages or 90s). This log message will appear when there is an issue with the in-path network or the remote device stops responding to the VNS3 controller for another reason.

Likely Causes
Liveness events are typically caused by in-path network issues at the connecting party’s edge but can be caused by other connectivity issues.

General Errors/Issues: Tunnel Drop

Pattern Match

rubik_pluto_updown: is_down

Log Symptom

Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1241: received Delete SA(0x48c3c68e) payload: deleting IPsec State #1244
Oct 10 09:00:00:000000: "cftconn_1_C2_1" #1244: deleting state (STATE_QUICK_I2) aged 146.517279s and sending notification
Oct 10 09:00:00:000000: ESP traffic information: in=1KB out=1KB
Oct 10 09:00:00:000000: is_down conn=cftconn_1_C2_1 perf=100.100.102.0/24 local=100.100.101.0/24

Description
When a tunnel goes from connected to not connected.

Likely Causes
There are a number of reason a connected tunnel will drop including but not limited to: VNS3 controller tunnel restart, VNS3 controller endpoint reset, VNS3 controller endpoint configuration update, in-path network interruption, remote device update, remote device configuration change, remote device vpn-idle-timeout behavior.

General Errors/Issues: Flapping Tunnel

Log Symptom
IPSEC SA established - but it keeps repeating significantly faster than the SALIFETIME or phase2-lifetime settings.

Description
IPsec tunnels connect via public Internet. As a result these connections can experience problems due to problems with intervening vendors, public cloud’s edge, user’s edge and/or user’s internal routing. HOWEVER, if the IPsec SA is being re-established more frequently than every ten minutes seek help from Cohesive Networks support immediately.

Likely Causes
Underlying network problems. Phase 1 or Phase 2 lifetime settings mismatch.

Additional Details Tunnels “flapping” (unexpected up/down events) can be caused by a number of factors but typically are the result of two issues:

  • Significant packet loss on the intervening Internet route between the IPsec peers. Rare in USA/Europe, much more likely in Singapore and South America.
  • Successfully connected but you do not have IDENTICAL configurations. IPSec interoperability is tricky. With vendor interoperability you need to be even more precise.
    • IKE lifetime or SA/IPsec lifetime are not set to the same values on each end of the tunnel respectively. These should be set to the same values for both ends to ensure coordinated re-key events.
    • The IKE and SA lifetimes used have identical values for IKE and SA lifetime. For example both IKE lifetime and SA lifetime are set to 28800 seconds. This can create a situation where IKE and SA re-key events happen simultaneously resulting in a hung tunnel where each side is using a different key set. They need to be different values.
    • There is a slight mismatch of the cryptographic algorithm family. While the initial negotiation of a tunnel using values like aes128 on one side and aes192 on the other appears successful, the resulting tunnel is unstable.
    • The remote IPsec device is End-of-Lifed and does not follow the most recent IPsec standard. If the IPsec device is 5 years old or NEWER - there should be no issue. If the IPsec device has been End-of-Lifed by its vendor or is on a very old software version a completely stable connection might not be possible. This is not a VNS3 issue, a stable connection would likely not be possible to any vendor.

General Errors/Issues: NAT-Traversal / Native IPsec Mismatch

Example 1

Log Symptom

STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP/NAT=>0x3f2d7d97 <0xc720352d xfrm=AES_256-HMCA_SHA1 NATOA=none NATD=none DPD=none}

Description
It will appear that there has been a successful Phase 2 connection shown with “IPsec SA established”

However, NAT-Traversal encapsulation is required when connecting IPsec tunnels to some Cloud Edge devices (AWS EC2 is the most common environment with this requirement). A tunnel can be successfully negotiated without NAT-Traversal to EC2 but the EC2 edge will block all traffic. As a result the tunnel will show Connected but nothing will pass through the tunnel.

VNS3, when NAT-Traversal is enabled will appear to negotiate given the terms of the remote gateway. If the remote gateway DOES NOT offer a connection with NAT-Traversal, then VNS3 will accept the connection without it.

The solution depends on if VNS3 is running in a cloud that will accept native IPsec (Protocol 50) traffic. If it does then the solution is to disable NAT-T on the VNS3 Controller. If it does not, then the solution is to make the remote gateway use NAT-T.

In the case where VNS3 is running with NAT-T disabled such as can be done when using AWS VPC feature, then VNS3 will NOT enable NAT-T even if the other side requests it.

The solution depends on if VNS3 is running in a cloud that will accept native IPsec (Protocol 50) traffic. If it does then the solution is to disable NAT-T on the VNS3 manager. If it does not, then the solution is to make the remote gateway use NAT-T.

Likely Causes
NAT-Traversal not enabled on remote gateway but is enabled on VNS3 NAT-Traversal disabled on VNS3, but remote gateway has it enabled.

Example 2

Log Symptom

STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP/NAT=>0x3f2d7d97 <0xc720352d xfrm=AES_256-HMCA_SHA1 NATOA=none NATD=107.23.96.102 DPD=none}

Notice that the NATD= field has the public ip address of the remote gateway the connection is with.

Description Here you see a Phase 2 connection success, and it appears that NAT-T was successfully negotiated. Yet, traffic is not flowing.

VNS3 clients running the OpenVPN agent receive route pushes when they connect to the VNS3 manager. If the tunnel came up AFTER this initial connection, then no route push will be received until the OpenVPN agent has been restarted. This will prevent traffic from being received by the VNS3 client machine.

This can be seen using the Network Sniffer to see traffic being sent to the VNS3 client - but no response coming back. Restart the OpenVPN agent on the VNS3 client and re-test. Or ask Cohesive Networks Support for info on the VNS3 routing agent.

Also, the VNS3 clients have had their OpenVPN agent restarted and are showing a route (netstat -nr will show this) to the remote gateway’s subnets.
Using the network sniffer on TUN0 interface will show no traffic. Using the network sniffer on ETH0 interface will show no data traffic, just negotiation traffic.
Firewall (possibly on remote gateway, but sometimes in the network path to the remote subnets) needs to be modified.
OR VNS3 Firewall has blocking entries. Check these on the Network Firewall page in the Web UI.

Likely Causes
Connected clients do not have route to the connected datacenter.
Firewall on remote gateway or VNS3 firewall not allowing traffic.

General Errors/Issues: Other Boxes

  • Cisco ASA lack of “interesting traffic” means no tunnel completion
  • Cisco ASA idle connection timeout defaults to closing tunnel every 30 minutes
  • Cisco ASA 8.4(2) - 8.4(4) have many bugs that cause interoperability problems
  • Firebox Watchguard needs VNS3 static LAN IP as IKE Peer ID (usually 192.0.2.254 or something like that)
  • Checkpoint does not follow NAT-T standards must be used in VPC with Native IPsec / Protocol 50/ESP
  • General care and attention to version age & EOL status. With EOL’d software, there can be interop issues due to the age of the IPsec standards used.

Updated on 10 Oct 2023

Table of Contents