4.211. openswan

BZ#703473

Openswan did not handle protocol and port configuration correctly if the ports were defined and the host was defined with its hostname instead of its IP address. This update solves this issue, and Openswan now correctly sets up policies with the correct protocol and port under such circumstances.

BZ#703985

Prior to this update, very large security label strings received from a peer were being truncated. The truncated string was then still used. However, this truncated string could turn out to be a valid string, leading to an incorrect policy. Additionally, erroneous queuing of on-demand requests of setting up an IPsec connection was discovered in the IKEv2 (Internet Key Exchange) code. Although not harmful, it was not the intended design. This update fixes both of these bugs and Openswan now handles the IKE setup correctly.

BZ#704548

Previously, Openswan failed to set up AH (Authentication Header) mode security associations (SAs). This was because Openswan was erroneously processing the AH mode as if it was the ESP (Encrypted Secure Payload) mode and was expecting an encryption key. This update fixes this bug and it is now possible to set up AH mode SAs properly.

BZ#711975

IPsec connections over a loopback interface did not work properly when a specific port was configured. This was because incomplete IPsec policies were being set up, leading to connection failures. This update fixes this bug and complete policies are now established correctly.

BZ#737975

Openswan failed to support retrieving Certificate Revocation Lists (CRLs) from HTTP or LDAP CRL Distribution Points (CDPs) because the flags for enabling CRL functionality were disabled on compilation. With this update, the flags have been enabled and the CRL functionality is available as expected.

BZ#737976

Openswan failed to discover some certificates. This happened because the README.x509 file contained incorrect information on the directories to be scanned for certification files and some directories failed to be scanned. With this update, the file has been modified to provide accurate information.

BZ#738385

The Network Manager padlock icon was not cleared after a VPN connection terminated unexpectedly. This update fixes the bug and the padlock icon is cleared when a VPN connection is terminated as expected.

BZ#742632

Openswan sent wrong IKEv2 (Internet Key Exchange) ICMP (Internet Control Message Protocol) selectors to an IPsec destination. This happened due to an incorrect conversion of the host to network byte order. This update fixes this bug and Openswan now sends correct ICMP selectors.

BZ#749605

The Pluto daemon terminated unexpectedly with a segmentation fault after an IP address had been removed from one end of an established IPsec tunnel. This occurred if the other end of the tunnel attempted to reuse the particular IP address to create a new tunnel as the previous tunnel failed to close properly. With this update, such tunnel is closed properly and the problem no longer occurs.

BZ#737973

On run, the "ipsec barf" and "ipsec verify" commands load new kernel modules, which influences the system configuration. This update adds the "iptable-save" command, which uses only iptables and does not load kernel modules.

BZ#786434

The Openswan IKEv2 implementation did not correctly process an IKE_SA_INIT message containing an INVALID_KE_PAYLOAD Notify Payload. With this fix, Openswan now sends the INVALID_KE_PAYLOAD notify message back to the peer so that IKE_SA_INIT can restart with the correct KE payload.

BZ#786435

Previously, Openswan sometimes generated a KE payload that was 1 byte shorter than specified by the Diffie-Hellman algorithm. Consequently, IKE renegotiation failed at random intervals. An error message in the following format was logged:

next payload type of ISAKMP Identification Payload has an unknown value

This update checks the length of the generated key and if it is shorter than required, leading zero bytes are added.

Bug Fixes

BZ#813192

Openswan incorrectly processed traffic selector messages proposed by the responder (the endpoint responding to an initiated exchange) if the traffic selectors were confined to a subset of the initially proposed traffic selectors. As consequence, Openswan set up CHILD security associations (SAs) incorrectly. With this update, Openswan initiates a new connection for the reduced set of traffic selectors, and sets up IKE CHILD SAs accordingly.

BZ#813194

Openswan incorrectly processed traffic selector messages proposed by the initiator (the endpoint which started an exchange) if the traffic selectors were confined to a subset of the initially proposed traffic selectors. As a consequence, Openswan set up CHILD SAs incorrectly. With this update, Openswan initiates a new connection for the reduced set of traffic selectors, and sets up IKE CHILD SAs accordingly.

BZ#813355

When processing an IKE_AUTH exchange and the RESERVED field of the IKE_AUTH request or response messages was modified, Openswan did not ignore the field as expected according to the IKEv2 RFC5996 specification. Consequently, the IKE_AUTH messages were processed as erroneous messages by Openswan and the IKE_AUTH exchange failed. With this update, Openswan has been modified to ignore reserved fields as expected and IKE_AUTH exchanges succeed in this scenario.

BZ#813356

When processing an IKE_SA_INIT exchange and the RESERVED field of the IKE_SA_INIT request or response messages was modified, Openswan did not ignore the field as expected according to the IKEv2 RFC5996 specification. Consequently, IKE_SA_INIT messages with reserved fields set were processed as erroneous messages by Openswan and the IKE_SA_INIT exchange failed. With this update, Openswan has been modified to ignore reserved fields as expected and IKE_SA_INIT exchanges succeed in this scenario.

BZ#813357

Previously, Openswan did not behave in accordance with the IKEv2 RFC5996 specification and ignored IKE_AUTH messages that contained an unrecognized Notify payload. This resulted in IKE SAs being set up successfully. With this update, Openswan processes any unrecognized Notify payload as an error and IKE SA setup fails as expected.

BZ#813360

When processing an INFORMATIONAL exchange, the responder previously did not send an INFORMATIONAL response message as expected in reaction to the INFORMATIONAL request message sent by the initiator. As a consequence, the INFORMATIONAL exchange failed. This update corrects Openswan so that the responder now sends an INFORMATIONAL response message after every INFORMATIONAL request message received, and the INFORMATIONAL exchange succeeds as expected in this scenario.

BZ#813362

When processing an INFORMATIONAL exchange with a Delete payload, the responder previously did not send an INFORMATIONAL response message as expected in reaction to the INFORMATIONAL request message sent by the initiator. As a consequence, the INFORMATIONAL exchange failed and the initiator did not delete IKE SAs. This updates corrects Openswan so that the responder now sends an INFORMATIONAL response message and the initiator deletes IKE SAs as expected in this scenario.

BZ#813364

When the responder received an INFORMATIONAL request with a Delete payload for a CHILD SA, Openswan did not process the request correctly and did not send the INFORMATIONAL response message to the initiator as expected according to the RFC5996 specification. Consequently, the responder was not aware of the request and only the initiator's CHILD SA was deleted. With this update, Openswan sends the response message as expected and the CHILD SA is deleted properly on both endpoints.

BZ#813366

Previously, Openswan did not respond to INFORMATIONAL requests with no payloads that are used for dead-peer detection. Consequently, the initiator considered the responder to be a dead peer and deleted the respective IKE SAs. This update modifies Openswan so that an empty INFORMATIONAL response message is now sent to the initiator as expected, and the initiator no longer incorrectly deletes IKE SAs in this scenario.

BZ#813372

When processing an INFORMATIONAL exchange and the RESERVED field of the INFORMATIONAL request or response messages was modified, Openswan did not ignore the field as expected according to the IKEv2 RFC5996 specification. Consequently, the INFORMATIONAL messages were processed as erroneous by Openswan, and the INFORMATIONAL exchange failed. With this update, Openswan has been modified to ignore reserved fields as expected and INFORMATIONAL exchanges succeed in this scenario.

BZ#813378

When the initiator received an INFORMATIONAL request with a Delete payload for an IKE SA, Openswan did not process the request correctly and did not send the INFORMATIONAL response message to the responder as expected according to the RFC5996 specification. Consequently, the initiator was not aware of the request and only the responder's IKE SA was deleted. With this update, Openswan sends the response message as expected and the IKE SA is deleted properly on both endpoints.

BZ#813379

IKEv2 requires each IKE message to have a sequence number for matching a request and response when re-transmitting the message during the IKE exchange. Previously, Openswan incremented sequence numbers incorrectly so that IKE messages were processed in the wrong order. As a consequence, any messages sent by the responder were not processed correctly and any subsequent exchange failed. This update modifies Openswan to increment sequence numbers in accordance with the RFC5996 specification so that IKE messages are matched correctly and exchanges succeed as expected in this scenario.

BZ#813565

Openswan did not ignore the minor version number of the IKE_SA_INIT request messages as required by the RFC5996 specification. Consequently, if the minor version number of the request was higher than the minor version number of the IKE protocol used by the receiving peer, Openswan processed the IKE_SA_INIT messages as erroneous and the IKE_SA_INIT exchange failed. With this update, Openswan has been modified to ignore the Minor Version fields of the IKE_SA_INIT requests as expected and the IKE_SA_INIT exchange succeeds in this scenario.

BZ#814600

Older versions of kernel required the output length of the HMAC hash function to be truncated to 96 bits therefore Openswan previously worked with 96-bit truncation length when using the HMAC-SHA2-256 algorithm. However, newer kernels require the 128-bit HMAC truncation length, which is as per the RFC4868 specification. Consequently, this difference could cause incompatible SAs to be set on IKE endpoints due to one endpoint using 96-bit and the other 128-bit output length of the hash function. This update modifies the underlying code so that Openswan now complies with RFC4868 and adds support for the new kernel configuration parameter, sha2_truncbug. If the "sha2_truncbug" parameter is set to "yes", Openswan now passes the correct key length to the kernel, which ensures interoperability between older and newer kernels.

Bug Fix

BZ#983451

The openswan package for Internet Protocol Security (IPsec) contains two diagnostic commands, "ipsec barf" and "ipsec look", that can cause the iptables kernel modules for NAT and IP connection tracking to be loaded. On very busy systems, loading such kernel modules can result in severely degraded performance or lead to a crash when the kernel runs out of resources. With this update, the diagnostic commands do not cause loading of the NAT and IP connection tracking modules. This update does not affect systems that already use IP connection tracking or NAT as the iptables and ip6tables services will already have loaded these kernel modules.