|
| 1 | +--- |
| 2 | +title: Release Notes |
| 3 | +owner: Security Engineering |
| 4 | +--- |
| 5 | + |
| 6 | +<strong><%= modified_date %></strong> |
| 7 | + |
| 8 | +This topic contains release notes for the Pivotal Cloud Foundry ® (PCF) IPsec add-on. |
| 9 | + |
| 10 | +## v1.5.31 |
| 11 | + |
| 12 | +### New Features |
| 13 | + |
| 14 | +* **StrongSwan**: This version of the IPsec add-on now uses StrongSwan version 1.5.4. |
| 15 | +* **Supported IAASes**: This version of the IPsec add-on adds support for OpenStack. It has been tested with OpenStack versions x.y.z, using PCF Elastic Runtime version x.y.z, and Ops Manager version x.y.z. The IPsec add-on is now supported on AWS, vSphere, and OpenStack. |
| 16 | +* **Bug Fixes**: This latest release corrects an issue that was discovered that could cause communication between hosts located in the IPsec subnet, and the no-IPsec subnet, to fail. This release includes a more robust implementation of the processing logic that controls the StrongSwan configuration which ensures that communication in a heterogeneous deployment (containing both IPsec and no-IPsec subnets) should always work as intended. |
| 17 | + |
| 18 | +### Known Issues |
| 19 | + |
| 20 | +* **Spurious Configuration Warning**: As part of the upgrade to StrongSwan version 1.5.4, this version of the IPsec add-on will emit a sequence of spurious configuration warning messages. The messages will appear similar to the following: |
| 21 | + |
| 22 | + ``` |
| 23 | + !! Your strongswan.conf contains manual plugin load options for charon. |
| 24 | + !! This is recommended for experts only, see |
| 25 | + !! http://wiki.strongswan.org/projects/strongswan/wiki/PluginLoad |
| 26 | + ``` |
| 27 | + |
| 28 | + These messages are both expected, and harmless. As a caution to end users, the StrongSwan software now emits a warning message when it detects that the installation includes a manually configured set of plug-ins. As a matter of security hygiene best practices, the IPsec add-on has always used a manual (explicit) configuration, and loads a restricted set of StrongSwan plug-ins. Any unused plug-ins are not loaded. The newest version of StrongSwan now issues this warning message when it detects that situation. The actual list of plug-ins in use has been determined to be appropriate for use of StrongSwan in the PCF environment. This warning is expected, and should be ignored. |
| 29 | + |
| 30 | +* **Certificate Verification**: There is a known issue with the CA certificate validation. The IPsec add-on supports credential rotation with no down time. The host instance certificate can be rotated at any time by doing a deployment. In addition, the CA certificate that is used to verify trust in the host certificates can be rotated with no down time by doing multiple deployments. |
| 31 | + <br><br> |
| 32 | + However, because all VMs typically share the same instance certificate, they will trust each other without relying upon the CA certificate. The CA certificate is not actually needed until the operator does a deployment to rotate the instance certificate(s). While that deployment is running, some of the VMs will have received a new instance certificate, while other VMs are still operating using the prior instance certificate. During this time, while the instance certificates are different, the validation of the peer instance certificate will rely upon the common CA certificate in order to establish trust in the counterparty. |
| 33 | + <br><br> |
| 34 | + If the CA certificate is malformed, or otherwise invalid, this problem will remain latent until the time when the instance certificate is being rotated. It is only during that deployment when the operator will discover that the CA certificate is not valid. Of course, as long as the CA certificate is valid, there is no problem. |
| 35 | + <br><br> |
| 36 | + It is recommended that operators use a tool such as OpenSSL to verify that the CA certificate they are choosing to configure is in fact valid, and contains the appropriate details for proper end-entity authentication of the VM in the deployment (such as subjectName, issuerName, and validity dates, etc). |
| 37 | + <br><br> |
| 38 | + Operators can use their favorite certificate management tool to confirm that their certificate matches what they expect. Using OpenSSL, one can issue the command: |
| 39 | + <pre class="terminal"> |
| 40 | + $ openssl x509 -in myCA.crt -text |
| 41 | + </pre> |
| 42 | + If this command produces valid output, then the certificate will be OK when configured for IPsec. |
| 43 | + |
| 44 | +* **MTU Sizing**: 1354 for OpenStack. 1454 for AWS and vSphere. Actual MTU versus expected MTU? |
| 45 | + |
| 46 | +### See Also |
| 47 | +(Need to confirm with CAPI team which versions of PCF have the NFS mounter issue fixed. I.e. they had delivered a story to fix NFS mounter start/stop scripts, and it has been delivered for some version of ERT. It was a known issue in 1.7.x but has been fixed as of 1.7.y. Not sure of exact versions). |
| 48 | + |
| 49 | +This section documents a known issue with monit and the NFS mounter job in PCF version 1.7.x, that may be exacerbated by the installation of IPsec. This is not a problem with the IPsec AddOn release itself. Rather, it is a known issue with the NFS mounter job and the monit stop script that might manifest itself after IPsec is deployed with PCF v1.7. |
| 50 | + |
| 51 | +In some situations, when a monit stop command is issued to the NFS mounter job, it can hang, preventing a shutdown of the PCF cluster. This is due to a known issue with NFS mounter job monit stop script. (Cf. http://serverfault.com/questions/303813/monitoring-nfs-with-monit ). |
| 52 | + |
| 53 | +This problem exists independently of IPsec, and is not being caused by IPsec. |
| 54 | + |
| 55 | +However, because the order of job shutdown is arbitrary, it is possible that when both are installed on the same machine, the IPsec job will be stopped first. After this happens, and the network connectivity for that VM goes away, and the NFS mounter job will lose visibility to the associated storage. This causes the NFS mounter job to hang, and it will block the monit stop from completing. |
| 56 | + |
| 57 | +(Describe manual recovery procedure? Or put that into troubleshooting guide? Solution is to run bosh cck and recreate VM. cf. https://www.pivotaltracker.com/story/show/122237301 ) |
| 58 | + |
| 59 | +This is not an issue in versions of PCF earlier than v1.7, because the earlier versions of PCF does not support the IPsec AddOn. |
| 60 | + |
| 61 | +Versions of PCF after 1.7.y should not see this problem, as the monit stop script for the NFS mounter job has been improved in those later releases (Cf. story in tracker). |
| 62 | + |
| 63 | +Finally, this NFS issue does not apply at all for any operators who are using WebDAV as their CC blobstore. |
| 64 | + |
| 65 | +Not a problem in 1.8 (for either NFS or WebDAV). |
| 66 | + |
| 67 | + |
0 commit comments