Common problems

Table 1 lists common problems in establishing security associations.
Table 1. Establishing security associations problems
Problem Symptom Cause/response
Cannot send or receive packets on UDP ports 500 or 4500 Message EZD1065I was issued.

When filter logging is active, message EZD0815I is issued, showing packets to UDP port 500 or UDP port 4500 that were denied.

 The IKE daemon communicates using UDP ports 500 and 4500 for IPv4. The IKE daemon communicates using UDP port 500 for IPv6. See Steps for verifying IP routing to a destination when not using policy-based routing to verify that the IKE daemon is running and bound to ports 500 and 4500.

A filter rule must be configured to permit inbound UDP traffic from any source port to destination ports 500 and 4500. A filter rule must be configured to permit outbound UDP traffic from source ports 500 and 4500 to any destination port. Use the ipsec -f display command to confirm there is a filter rule installed in the stack that permits receiving traffic from any source UDP port to destination UDP ports 500 and 4500. Also confirm that there is a filter rule that permits receiving traffic from source UDP ports 500 and 4500 to any destination port. Activate filter logging for these rules so that you can observe packets sent on source ports 500 and 4500 and received on destination ports 500 and 4500 in the syslog.

For information about the ipsec command, see z/OS Communications Server: IP System Administrator's Commands. See z/OS Communications Server: IP Configuration Guide for general information about configuring IP filters.
Pre-shared key mismatch Message EZD0965I was issued. If IKE is using pre-shared key mode authentication and it cannot interpret a decrypted message that it has received, then message EZD0965I is issued, indicating a likely pre-shared key mismatch. In main mode, the responder gets the message upon receipt of message 5. In aggressive mode, the initiator gets the message upon receipt of message 2. EZD0965I can also be issued if IKE receives a corrupted message even though the pre-shared keys match. If the remote peer cannot decrypt the message that was sent by IKE because of a pre-shared key mismatch, the local symptom is that IKE retransmits the first encrypted message of the exchange. Review the pre-shared key configuration on the local and remote system and ensure that the keys match.
Tip: The keys might be represented differently (for example, ASCII or EBCDIC) on the local and remote system.
Failure accessing local certificate repository One of the following messages was issued:
  • EZD0990I
  • EZD1030I
For the IKE daemon to support RSA signature mode authentication using a local certificate repository, the daemon must be able to access certificates on the SAF key ring. IKE issues message EZD0990I to indicate that RSA signature mode is supported or EZD1030I if RSA signature mode is not supported for a given stack using the key ring. See the messages to determine the appropriate response. The key ring is specified on the KeyRing parameter in the IkeConfig statement. When configuring with the IBM® Configuration Assistant for z/OS® Communications Server GUI, the key ring is specified on the key ring database field on the IPSec: IKE Daemon Settings panel.
Failure accessing the network security services (NSS) server One of the following messages was issued:
  • EZD1136I
  • EZD1137I
  • EZD1138I
  • EZD1905
 For the IKE daemon to support digital signature mode authentication using IPsec certificate services, it must be able to connect to a network security server. IKE issues the following messages:
  • EZD1136I to indicate that it has connected to a network security server
  • EZD1137I to indicate that it is not connected to a network security server.
  • EZD1138I to indicate that it is connecting to a network security server.

For the IKE daemon to support digital signature mode authentication for IKEv2 security association activation, IPSec certificate services must be provided by a z/OS V1R12 or later NSS server. If the IKE daemon is not connected to an NSS server, or it is not configured for certificate services, or the NSS is not V1R12 or later, EZD1905 is issued for each IKEv2 SA activation attempt that requires digital signature mode authentication.

The network security services server is specified on the NetworkSecurityServer and NetworkSecurityServerBackup parameters on the IkeConfig statement. When configuring with the IBM Configuration Assistant for z/OS Communications Server GUI, the network security server is specified on the server setting in the NSS perspective.
RSA signature authentication failure - missing certificate in the local certificate repository Message EZD1037I was issued. Check the syslog to determine whether message EZD1037I was issued. If the IKE daemon cannot locate a certificate that is needed for RSA signature mode authentication, message EZD1037I is issued.
  • Display the certificates on the SAF key ring.
  • Ensure that all the certificates on the key ring that are to be used by the IKE daemon include a digital signature.
  • If you are using RACF®, make sure that the trust status of the certificates is TRUST or HIGHTRUST.
Use the IKE daemon IkeSyslogLevel 64 to display the contents of the IKE daemon's certificate caches and ensure that the certificates that you want are included in the caches.
RSA signature authentication failure because of identity mismatch One of the following messages was issued:
  • EZD0981I
  • EZD1075I
 Check the syslog to determine whether message EZD0981I or EZD1075I was issued. If the identity that is contained within a received certificate does not match the identity that is configured on the RemoteSecurityEndPoint statement, message EZD0981I is issued. If the peer detects such a mismatch, it might send an "Invalid ID information" notification. If IKE receives such a notification, message EZD1075I is issued. See the messages to determine the appropriate response.
RSA signature authentication failure because of a local certificate verification or authentication failure One of the following messages was issued:
  • EZD0902I
  • EZD0903I
Check the syslog to determine whether message EZD0902I or EZD0903I was issued. If the certificate that is received from a peer cannot be verified, message EZD0902I is issued. If the certificate that is received from the peer cannot be authenticated, message EZD0903I is issued.

See the messages to determine the appropriate response. Activate IkeSyslogLevel 64 to get additional diagnostic information that relates to RSA signature mode authentication. The IKE daemon syslog level is set in the IkeSyslogLevel parameter in the IkeConfig statement.

When configuring with the IBM Configuration Assistant for z/OS Communications Server GUI, the IKE Daemon Syslog settings are accessed from the IPSec: IKE Daemon Settings panel. IKE maintains a separate cache for Certificate Authority (CA) certificates and security endpoint certificates. When IkeSyslogLevel 64 is active, the contents of the certificate caches are displayed when they are built or rebuilt.

See z/OS Communications Server: IP Configuration Reference for information about setting the IkeSyslogLevel, or see the online help in the IBM Configuration Assistant for z/OS Communications Server.

Tip: The name of the key ring is case-sensitive.
RSA signature authentication failure - IPsec certificate services failure Message EZD1139I was issued. Check the syslog to determine whether message EZD1139I was issued.

The EZD1139I message will be issued if the network security server failed to locate a certificate, could not verify a digital signature, or could not create a digital signature for RSA signature mode authentication.

See the messages to determine the appropriate response.

Failure to locate phase 1 policy Message EZD0917I was issued. In order for IKE to establish a phase 1 SA, it must first locate an applicable phase 1 policy.

KeyExchangeRules encapsulate phase 1 policy for IKE. KeyExchangeRules are classified according to a 4-tuple that is comprised of LocalSecurityEndpoint Location, LocalSecurityEndpoint Identity, RemoteSecurityEndpoint Location, and RemoteSecurityEndpoint Identity. When IKE needs to locate a KeyExchangeRule statement, it performs a search of the configured KeyExchangeRules statements, supplying specific values or Any for each parameter of the classification 4-tuple.

When configuring with the IBM Configuration Assistant for z/OS Communications Server the following are configured in each Connectivity Rule:
  • Local Security End Point Location
  • Local Security End Point Identity
  • Remote Security End Point Location
  • Remote Security End Point Identity
  • Key Exchange Settings
It is also possible in the GUI to configure a single Local Security End Point Location and Identity for an entire TCP/IP stack.

If IKE fails to locate an applicable KeyExchangeRule statement, message EZD0917I is issued that lists the classification 4-tuple. Use the pasearch -v k -r command to review the configured KeyExchangeRules statement. If there is no KeyExchangeRule statement that corresponds to the classification 4-tuple that is given on the EZD0917I message, configure a new KeyExchangeRule statement as needed.

See the messages for EZD0917I for more information.
IKE version mismatch Message EZD1753I was issued. The IKE daemon sent an IKEv2 initiation request to an IKEv1 peer, and it responded with an IKEv1 message, probably a rejection of the request. The local policy must have HowToInitiate IKEv2, but the peer does not support IKEv2. Change the value on HowToInitiate to Main or Aggressive, to cause the IKE daemon to use IKEv1 flows for tunnel initiation. Alternatively, have the peer IKE node initiate the tunnel. z/OS IKED accepts either IKEv1 or IKEv2 initiation requests, as long as the other attributes being negotiated are properly configured.
Phase 1 policy mismatch Message EZD1093I or EZD1075I was issued. The ISAKMP initiator and responder must agree on phase 1 policy to successfully complete negotiation of a phase 1 security association. If the IKE daemon rejects the phase 1 policy that is proposed by an ISAKMP peer, it issues message EZD1021I, which indicates the KeyExchangeRule and KeyExchangeAction statements that were in effect when the mismatch occurred. Message EZD1093I is issued, which indicates why the mismatch occurred.

When configuring with the IBM Configuration Assistant for z/OS Communications Server, the Key Exchange Settings are set in each Connectivity Rule.

If the IKE daemon proposes phase 1 policy that the ISAKMP peer rejects, the ISAKMP peer should send a notification message to the IKE daemon. If the IKE daemon receives such a notification, it issues message EZD1075I. For more information, see the EZD1075I message documentation in z/OS Communications Server: IP Messages Volume 2 (EZB, EZD). If the peer is a z/OS IKE daemon, it issues the EZD1021I and EZD1093I messages as described above. If the peer is not a z/OS IKE daemon, consult the documentation for the ISAKMP peer product to determine why it rejected the proposal.

In the case of a mismatch, a No proposal chosen notification is expected from the peer.
Failure to locate phase 2 policy Message EZD1795I was issued In order for IKE to establish a phase 2 SA, it must first locate an applicable phase 2 policy. Phase 2 policy for the IKE daemon is comprised of IpFilterRule and IpDynVpnAction statements. The first step in locating a phase 2 policy for the IKE daemon is to locate an IpFilterRule statement that matches the traffic to be protected and includes a reference to an IpDynVpnAction statement. If IKE cannot find an applicable IpFilterRule statement, message EZD1795I is issued, which indicates the traffic that was to be protected.

When configuring with the IBM Configuration Assistant for z/OS Communications Server, the Connectivity Rules are used to locate the phase 2 policies. The Connectivity Rules contain the local and remote data end points, and which type of traffic is protected by Security Levels implementing dynamic tunnels.

See the messages to determine the appropriate response. See Steps for verifying IP security and defensive filter operation, supplying the IP traffic characteristics identified on the EZD1795I message.
Phase 2 policy mismatch Message EZD1022I, EZD1093I, or EZD1075I was issued. The ISAKMP initiator and responder must agree on phase 2 policy to successfully complete negotiation of a phase 2 security association. If the IKE daemon rejects the phase 2 policy that is proposed by an ISAKMP peer, it issues message EZD1022I, which indicates the IpFilterRule and IpDynVpnAction statements that were applied. When configuring with the IBM Configuration Assistant for z/OS Communications Server, the Connectivity Rules are used to locate the phase 2 policies. The Connectivity Rules contain the local and remote data end points, and which type of traffic is protected by Security Levels implementing dynamic tunnels. Message EZD1093I is issued indicating why the mismatch occurred.

Check the syslog to determine whether message EZD1075I was issued. If the IKE daemon proposes a phase 2 policy that the ISAKMP peer rejects, the ISAKMP peer should send a notification message to the IKE daemon. If the IKE daemon receives such a notification, it issues message EZD1075I. Review the diagnostic data at the ISAKMP peer to determine why the peer rejected the proposal. See the EZD1075I message documentation for more information.

In the case of a mismatch, a No proposal chosen notification is expected from the peer.
AES encryption/decryption failure Message EZD0918 or EZD1109 was issued. If IKE is using AES for phase1 or phase2 encryption and decryption, it calls Integrated Cryptographic Service Facility (ICSF) to do the actual cryptography. If ICSF has not been started the cryptography cannot be performed, and IKE cannot encrypt or decrypt messages using AES. This can happen any time during an informational exchange, any time during a phase 2 exchange, in message 5 of main mode if acting as the initiator, or in message 6 of main mode if acting as the responder.

The return and reason codes for an ICSF failure are output in message EZD0918 (encryption) or message EZD1109 (decryption). If the return code is C(12) and the reason code is 0, this normally means that ICSF has not been started and therefore cannot perform the necessary cryptography. Ensure that ICSF is started so that the IKE daemon can perform AES cryptography.

If the return code is C(12) and the reason code is 8, this normally means that the installed version of ICSF does not support AES. The Security Level Feature of ICSF is required (FMID HCR7706 or higher) for AES support.
Parent topic: Problems establishing security associations