Last updated on: June 15 2024.

IKEv1 Log Analysis

This page describes how to interpret logging found in /var/log/racoon.log.

If possible, debug2 logs should be enabled to see more detailed logs. Most of the logging described below will not appear at the default log level.

To enable debug2 logs, refer to Enable IPsec Debug.

Refer to the IKEv2 Log Anaysis page for IKEv2 analysis.

Common Log Messages and Meaning

These logs are all generated by racoon, which is why they are found in racoon.log. Not all of the listed messages indicate a problem.


2018-03-20 09:38:16: DEBUG: check and compare ids : value mismatch (IPv4_address)

racoon was unable to match any of the locally configured selectors to that which was proposed.

If racoon was able to match a selector, the log would look like this:

2018-03-12 09:13:04: DEBUG: best sainfo match: loc='1.1.1.0/24', rmt='1.2.1.0/24', peer='ANY', id=0
2018-03-12 09:13:04: DEBUG: selected sainfo: loc='1.1.1.0/24', rmt='1.2.1.0/24', peer='ANY', id=0

2014-06-02 12:39:30: INFO: IPsec-SA expired: ESP/Tunnel 1.1.1.1[0]->2.2.2.2[0] spi=3807031672(0xe2eab178)
2014-06-02 12:39:30: DEBUG: pfkey GETSPI sent: ESP/Tunnel 1.1.1.1[0]->2.2.2.2[0]
2014-06-02 12:39:30: INFO: IPsec-SA expired: ESP/Tunnel 2.2.2.2[0]->1.1.1.1[0] spi=3420199445(0xcbdc1a15)
2014-06-02 12:39:30: DEBUG: no such a SA found: ESP/Tunnel 2.2.2.2[0]->1.1.1.1[0] spi=3420199445(0xcbdc1a15)

The IPsec SA expired. It may have already been replaced. Look for messages like this to see if it was replaced:

2014-06-02 12:39:30: INFO: IPsec-SA established: ESP/Tunnel 1.1.1.1[0]->2.2.2.2[0] spi=4233547948(0xfc56d0ac)
2014-06-02 12:39:30: INFO: IPsec-SA established: ESP/Tunnel 2.2.2.2[0]->1.1.1.1[0] spi=1896834269(0x710f64dd)

2014-06-02 12:39:30: INFO: purged IPsec-SA proto_id=ESP sibling spi=3477116144.
2014-06-02 12:39:30: INFO: purged IPsec-SA proto_id=ESP spi=1479269761.

When an IPsec SA expires or is deleted, the sibling should be expired. The sibling is the ESP SA that carries traffic in the reverse direction to the expired SA and that tunnel (pair of SAs) is fully deleted.


2014-06-02 12:39:30: DEBUG: peer's single bundle:
2014-06-02 12:39:30: DEBUG:  (proto_id=ESP spisize=4 spi=f09440cf spi_p=00000000 encmode=Tunnel reqid=0:0)
2014-06-02 12:39:30: DEBUG:   (trns_id=AES encklen=128 authtype=hmac-sha)
2014-06-02 12:39:30: DEBUG: my single bundle:
2014-06-02 12:39:30: DEBUG:  (proto_id=ESP spisize=4 spi=582bdd81 spi_p=00000000 encmode=Tunnel reqid=30588:30589)
2014-06-02 12:39:30: DEBUG:   (trns_id=AES encklen=128 authtype=hmac-sha)

One part of the IPsec SA negotiation is to compare the encrpytion and authentication algorithms offered by the remote. In this case negotiation would continue because the peer’s bundle matches the BIG-IP’s configuration.


2017-05-01 16:22:25: ERROR: ignore information because the message is too short - 76 byte(s).

An ISAKMP SA is established on the BIG-IP but the other peer has not established the tunnel and is still attempting some part of the negotiation. The peer probably disliked or did not receive the final message from the BIG-IP during phase1 negotiation. In this scenario it is most likely to be that the BIG-IP is the phase1 Responder.


2017-05-01 16:23:18: ERROR: none message must be encrypted

An ISAKMP-SA is established on the BIG-IP but the other peer has not established the tunnel and is attempting to send an unencrypted message using that SPI (ISAKMP cookie). After the SA is established and during parts of the ISAKMP negotiation process, the peers should switch to sending encrypted messages. After that point, any ISAKMP message that arrive and do not have an encrypted payload will result in this error.


2016-06-29 07:43:05: INFO: IPsec-SA request for 216.52.29.202 queued due to no phase1 found.

BIG-IP wants to start a tunnel (is the inititator), an IPsec SA (phase 2) SA placeholder is created if no ISAKMP SA (phase 1) exists. After the ISAKMP SA is created the IPsec SA negotiation can continue.


Top | Flowchart | Contents