| 738086 |
When a base configuration is reloaded, the box is reset, and VLANs are removed. To create network objects, at least one VLAN is required. Workaround: Manually create a VLAN if no VLAN is present.
|
| 739549 |
When choosing to deploy L2 outbound and L2 inbound deployment modes, the user can configure a default gateway under System Settings. Workaround: Gateway and SNAT settings are globally configured but ignored for L2 deployments.
|
| 755037 |
If there is an intermittent static state of any iAppLX application, it takes 2 minutes for REST storage to get replicated on the secondary blade. Therefore, the changes will be lost if you modify and deploy a config during this period. |
| 759592 |
HTTP traffic cannot pass when SSL Orchestrator is configured in Inbound mode. For example, if you configure a virtual with 0.0.0.0:0/0 any policy, the HTTPS traffic successfully passes, but the HTTP traffic fails. On the server side, the BIG-IP sends a client "Hello" on port 80 to the server. It should instead be a plain text GET request. This results in causing a failure. |
| 814245 |
When you refresh the high availability (HA) status pages of both devices simultaneously, the 'Overall Status'/'Peer HA Verification response' may be displayed as bad even though it is good. Workaround: Click the Refresh button after a while (around 10 seconds), and the status page will show "good" if everything else is working fine.
|
| 830781 |
When downgrading one device after an upgrade was performed, the High Availability (HA) status page may show the wrong BIG-IP version for that device. For example, after two HA devices upgrade to BIG-IP 15.1.0 and SSL Orchestrator 7.0, if the user downgrades one of the devices back to 14.x.x and SSL Orchestrator 5.x, the other device's HA status page (introduced in 7.0) may show the wrong BIG-IP version for the downgraded device. For the 15.1.0-7.0 device, the framework gives SSL Orchestrator the wrong BIG-IP version for its peer. Workaround: Re-establish HA from scratch. In addition, upgrade the downgraded device to the same version as its peer.
|
| 833209 |
SSL Orchestrator non-L2 Wire VLAN is filtered out on the Interception Rule screen. For the L2 wire box for L2 topologies, all the VLANs that are not virtual wired enabled are filtered out. This occurs when the following conditions are met:
- The BIG-IP system is L2 virtual wire enabled.
- You are trying to deploy an L2 topology.
- The VLAN is not virtual wire enabled.
As a result, you cannot select the non-virtual wired enabled VLANs on Interception Rules for the L2 wire box.Workaround: None. This is as-designed functionality. For L2 deployment, only virtual wire-enabled VLANs should be used, so other VLANs are getting filtered out.
|
| 852921 |
Certain Viprion chassis, combined with certain blade models with a minimal MAC address pool, do not support inline L2 devices. These particular chassis and blade combinations may result in duplicate source and destination MAC addresses and no traffic flowing to the configured inline L2 services. For example, the following chassis and blade combinations are impacted by this issue: B2250 blade on 2400 chassis; B4300 blade on 4800 chassis; B4450 blade on a 4480 chassis. For further information, review the details provided in the MAC address assignment for interfaces, trunks, and VLANs (11.x and later) article. |
| 869677 |
When the SSL Orchestrator configuration upgrade is pending due to blade high availability (HA) state, and you reset the device trust, the upgrade process resumes and starts deploying the SSL Orchestrator configuration. If device trust is reset, the device becomes a standalone device and triggers the pending configuration upgrade. |
| 872969 |
When a strictness-disabled configuration is modified, and the Preview Merge Config button is clicked, followed by the Cancel button, it takes you back to the main page. It shows the Strictness icon enabled, irrespective of the true status. Workaround: You can either deploy or delete the pending configuration to see the actual state of the Strictness field.
|
| 873173 |
SSL Forward Proxy does not mirror the forged Online Certificate Status Protocol (OCSP) responses to the session database on the standby high availability (HA) device. As a result, the OCSP Responder on the BIG-IP system cannot respond to out-of-band OCSP requests right after a failover event occurs and before the SSL handshake is performed with the backend server. Workaround: The OCSP responses succeed after the new active device performs an SSL handshake to the backend server, which would then re-forge and cache the server certificate and status.
|
| 876341 |
You cannot delete MCP objects inside an app service folder when the folder name has been deleted. For example, the ssloN_name has been removed, but the self IP under the ssloN_name app service folder was still there. Workaround: Create the app service and delete it again.
|
| 876585 |
Modifying iRule on virtual in TMUI does not trigger the proper reconciliation for the SSL Orchestrator UI's Interception Rule page or potential topology page. Workaround: Click the update button for the virtual server on TMUI, which will trigger a quick reconciliation.
|
| 889621 |
When you restore the SSL Orchestrator UCS on only one device in the high availability (HA) configuration and then try to sync the configuration, the operation does not complete successfully. This happens when an SSL Orchestrator HA configuration UCS is restored and synced on only one device. Configuration does not sync on the peer device.Workaround: Restore the UCS on both units. Each unit should have its own UCS file. Note: Do not use the same UCS file to restore on both units unless the UCS is generated using RMA steps.
|
| 892489 |
SSL Orchestrator deployed configuration ends up in an error state after deployment or after upgrade if restnoded or restjavad re-starts during the process. Workaround: Re-deploy the configuration again.
|
| 892497 |
SSL Orchestrator deployment failure and timeout due to high CPU usage. SSL Orchestrator fails to deploy if a deployment is created when CPU usage is very high. Often this ends up in deployment timeout. Workaround: Re-deploy the configuration again.
|
| 897109 |
During certain transitory conditions involving the REST framework (For example, UCS backup/restore), when the REST framework is being restarted, the BIG-IP SSL Orchestrator user interface may become temporarily unavailable or have limited functionality. For example, deploying an SSL Orchestrator topology may result in a "URI path not registered" error. Workaround 1: Refresh the SSL Orchestrator configuration page in the BIG-IP user interface.
Workaround 2: Exit the SSL Orchestrator configuration page in the BIG-IP user interface, and then access the SSL Orchestrator configuration page again before attempting to deploy.
|
| 898993 |
When deploying the SSL Orchestrator after restarting restnoded, a 'RestOperation failed' message appears in the log. |
| 903465 |
If there is an intermittent static state of any iAppLX application, it will take 2 minutes for REST storage to get replicated on the secondary blade. If you modify SSL Orchestrator or any iAppLX application during that time, the configuration changes are lost. You may also get an error: [OrchestratorConfigProcessor] Deployment failed for Error: Unable to PATCH block from BINDING to BINDING state. Saved configuration and failover events occur before REST can replicate the state to a secondary blade. You must make your changes again. Workaround: None. |
| 903885 |
The SSL Orchestrator configuration does not appear on the high availability (HA) standby device when the configuration is pushed from the active device. When the Active peer is forced to standby in a HA group, the alternate active HA peer will display an empty SSL Orchestrator configuration page. The new active device correctly processes the SSL Orchestrator traffic, but the related configuration is unavailable in the web user interface.Workaround: Run the following commands in the active device's terminal to address the issue:
- Delete HA sync (gossip) group device references in the REST framework:
restcurl -X DELETE shared/resolver/device-groups/tm-shared-all-big-ips/devices
- Force REST gossip/sync to update device references:
restcurl -X POST -d '{}' tm/shared/bigip-failover-state
|
| 904141 |
SSL Orchestrator: On vCMP chassis Blade failover during upgrade or deployment may cause deployment or upgrade failure. On vCMP chassis, when blade failover occurs during an SSL Orchestrator RPM upgrade or SSL Orchestrator configuration deployment, the upgrade and deployment may end up in an error state. Workaround: Re-deploying the non-upgraded configuration or configuration in error will resolve the problem.
|
| 905113 |
In a rare scenario, some configs are duplicated after the RPM upgrade in a high availability (HA) environment. Workaround: Delete the SSL Orchestrator config and make sure it gets deleted from all the devices in the HA environment.
|
| 906017 |
SSL Orchestrator's high availability (HA) pair is in an incorrect state after license reactivation. When HA peers have both licenses expire and reactivate, the Active unit reports an error. One or more SSL Orchestrator configurations are in an incorrect state. Look for errors in /var/log/restnoded/restnoded.log for corrective action to those configurations before making additional changes to avoid further errors.
Workaround: Run the following command:
restcurl -X POST -d '{"resetDevices": true}' /mgmt/shared/iapp/f5-iappslx-ssl-orchestrator/ha-remediation. If this does correct the issue, you must delete and rebuild the device group.
|
| 907605 |
Upgrading the non-strict SSL Orchestrator application to 8.0 does not trigger out-of-band change reconciliation. In v8.0, certain out-of-band changes that are reconcilable to the SSL Orchestrator GUI are reconciled, except for applications that are non-strict before the upgrade. Modifying such configurations using the SSL Orchestrator GUI might overwrite the out-of-band change. Workaround: Click the Update button in the GUI for each non-strict application object with an out-of-band change. To ensure the change, review each object (primarily virtual servers, pools, and SSL profiles that have a greater impact).
|
| 913469 |
Creating a new Rule or editing the Client IP Subnet Match rule in Security Policy sometimes results with the Rules are currently non-editable error. Workaround: Reload the Security Policy page.
|
| 947249 |
SSL Orchestrator configured for high availability (HA) and with manual config sync, goes to an error state when reverse configSync is done after deleting or deploying operation.Workaround:
- For delete operation: Trigger the delete on both devices.
- For config deployment: Sync the latest changes to the peer device.
|
| 957577 |
SSL Orchestrator has a protect/un-protect mechanism that allows administrators to modify the APM per-request policy derived from the security policy. Modification and re-protecting the config can sometimes fail if agents have been added or removed from the policy. |
| 966013 |
When you change the description of a virtual server created by an SSL Orchestrator deployment and then upgrade to the next version of RPM or ISO, the changed name does not get updated on the Interception Rules page.Workaround: Perform the following steps:
- Navigate to and click on the Interception Rule tab.
- Change the description in the Interception Rule.
- Deploy the Interception Rule.
|
| 966361 |
When config sync is triggered after an operation in the SSL Orchestrator GUI, if you overwrite the configuration from the peer box, causing reverse sync, the configuration is lost. Important: Always initiate ConfigSync from the device you deleted config to the peer devices. Syncing the other way would result in undesired consequences.
|
| 969209 |
SSL Orchestrator configuration page shows the following warning message if the UCS files within a failover device group do not contain the same shared blocks. This prevented modifications of SSL Orchestrator configurations. Loading SSL Orchestrator Configuration. Any configuration changes are not allowed till configuration is fully loaded.
Workaround: Ensure that UCS files are created on each device within the failover device group at the same time after both devices are in sync.
|
| 974945 |
The BIG-IP system upgrades the configuration to a newer version when you upgrade the SSL Orchestrator RPM. If this upgrade process is interrupted by a restnoded or restjavad restart, the upgrade fails with an error. Workaround: Complete the following steps:
- Navigate to iAppsApplication Services: Applications LX. Delete objects in error (red) state.
- Perform config sync if required.
- Navigate to and click Upgrade SSL Orchestrator on the top right.
If the above steps do not work, upgrade SSL Orchestrator again. |
| 987521 |
In the high availability (HA) manual sync mode, when the user deletes the configuration on one device and tries to sync the configuration on a peer device, the operation does not complete successfully. This is because, the configuration does not get deleted on the peer device.
Workaround: After deleting the configuration from one device, wait for 30 seconds before trying config sync on a peer device. If you already triggered the config sync and the configuration did not sync, delete the configuration from the peer device manually and start config sync again. |
| 995829 |
Clicking on the Fix Issue Manually link in the high availability (HA) screen of SSL Orchestrator fails to open the login screen of the affected device. Workaround: Use the help text and help icons in the high availability (HA) screen to get assistance on fixing issues.
|
| 997673 |
Upgrade fails with the following error when you create different topologies and redeploy them with cross-references of objects from other topologies:
Unable to complete the cleanup. You must resolve the error (if any), delete the iApp blocks in error state (if any) from the iApps menu on the left hand side and perform CMI sync. Then resume the upgrade process: click Upgrade.Workaround 1: Complete the following steps:
- Remove the circular dependencies using the TMUI or TMSH commands.
- Navigate to and click Upgrade SSL Orchestrator on the top right.
Workaround 2: Complete the following steps:
- Boot back to the earlier partition.
- Remove the circular dependencies.
- Install a new ISO.
- Boot into the new partition.
- Navigate to the SSL Orchestrator menu.
|
| 1001929 |
While creating a new L2 service, the desired IP offset value is not displayed.Workaround: Complete the following steps:
- Delete the errored L2 service.
- Restart restnoded: tmsh restart sys service restnoded
- Once the restart successfully completes, return to SSL Orchestrator and click Add for new L2 services. All available offset values are now visible.
|
| 1024417 |
Following the deployment of a topology, if an administrator modifies the associated Virtual Server under Local Traffic so that the source or destination is set to an address list in place of a host, traffic will continue to pass based on the addresses contained within the address list. As of 16.1.0, the SSL Orchestrator Guided Configuration allows changes to deployed objects without the administrator disabling strict updates. In some, within the Interception Rule of the Guided Configuration, the Source Address will show incorrectly as 0.0.0.0%0/0 and Destination Address as %0/0, and the field will show the following error: IP address with must CIDR prefix or optional Route Domain between 0 to 65534 Required.
Workaround: To clear the destination field error from the interception rule, the admin needs to set host addresses in place of address lists within the Virtual Server under Local Traffic. Once address lists have been replaced by host addresses within the virtual, any subsequent address changes can be made from the SSL Orchestrator Guided Configuration.
|
| 1031745 |
For SSL Orchestrator running versions 8.0 through 8.3, attempting to upload the version 8.4 RPM using the SSL Orchestrator UI gives a validation error.Workaround: Complete the following steps to upload the RPM:
- Navigate to .
- Click Import.
- Click Choose File and select the 8.4 RPM.
- Click Upload.
|
| 1033113 |
The SSL Orchestrator iApp does not support editing, deleting, or deployment of multiple items in a configuration. |
| 1038373 |
In the security policy configuration page of SSL Orchestrator UI, editing a rule with the condition "ip subnet match" with a data group value does not show the correct input field. Workaround: Delete and re-create the rule.
|
| 1040709 |
When you unbind SSL from the Interception Rules and attempt to delete that configuration, you get an error message that the SSL is used in the topology.
Conditions:
The topology is outbound/explicit.
Interception rules are updated via the Interception Rules mini workflow.
Workaround: In the Topology flow, unbind SSL from the Interception Rules step and then deploy. Use the delete button to delete this SSL from the SSL Configuration list. |
| 1044685 |
The BIG-IP version number from the SSL Orchestrator RPM version 9.1 onwards has changed. Uploading an RPM version 9.1 and above using the SSL Orchestrator GUI while the BIG-IP is still running the 9.0 RPM, would cause an upload failure with the following error message: Cannot install f5-iappslx-ssl-orchestrator-16.1.1-9.1.23.noarch.rpm, package version should be 16.1.0-x.x.x and higher than 16.1.0-9.0.24
Workaround: If you are running the 9.0 RPM, please install 9.1 or later versions using the menu. If you are running 9.1 RPM or above, you can use either upgrade method.Perform the following steps to install using the Package Management LX menu:
- Navigate to and click Import.
- Select the SSLO 9.2 RPM package.
- Wait until the upload completes, then wait another 15 minutes for the reconciliation and upgrade processes to complete.
- Visit the SSL Orchestrator GUI to ensure the upgraded version is correctly reported.
|
| 1047377 |
The "server speaks first" traffic does not pass through the SSL Orchestrator, and the connection fails. This happens when the SSL Orchestrator interception rule has an attached service chaining security policy, and port-remap is enabled on at least one service. Workaround: Disable port-remap on service and redeploy.
|
| 1048033 |
The "server speaks first" traffic does not pass through the SSL Orchestrator, and the connection fails. The service chaining does not work for the service when the port-remap is enabled. Workaround: Disable port-remap on service and redeploy.
|
| 1048393 |
After upgrading SSL Orchestrator to version 9.1, some temporarily created client and server SSL profiles are left behind on the device and are not deleted during the upgrade delete/cleanup process. Workaround: Run the following TMSH commands to delete these profile copies:
tmsh delete ltm profile client-ssl copy-ssloT*
tmsh delete ltm profile server-ssl copy-ssloT*
|
| 1049753 |
The HTTP traffic for Inbound application topology fails after upgrading to version 9.1 when interception rules have attached SSL profile(s). Workaround: Manually remove the SSL profile(s) from the interception rule and redeploy the inbound topology.
|
| 1050205 |
For an Inbound topology, when a service is port re-map enabled and attached to the server chain, re-deployment fails with an error when you remove the SSL profiles from the Interception Rule page. This happens because Port Remap requires the Client SSL profile to function. Workaround 1: When removing the SSL profile from the Interception Rule page, remove the Port Remap along with it. This is a temporary solution.
Workaround 2: Turn off Port Remap on service or disengage it from the policy or service chain.
|
| 1055389 |
When SSL Orchestrator is deployed in a HA configuration where Virtual Wire is in use, and the associated Network Trunks have LACP enabled, the traffic fails to pass following an upgrade from 15.1.x to 16.1.x. Workaround: Disable LACP on all Network Trunks used by Virtual Wire before upgrading from 15.1.x to 16.1.x.
|
| 1055945 |
Adding or removing port re-map to services may force full config-sync during deployment. The config-sync icon in the upper left of the configuration utility turns red, displaying the status "Changes Pending." This occurs on any deployment or re-deployment of an SSL Orchestrator topology where port re-map has been changed from enabled or disabled. |
| 1061109 |
For HA devices, sometimes manual sync fails, and the config-sync icon in the upper left of the configuration utility turns red, displaying the status "Changes Pending." In such scenarios, it is crucial to initiate ConfigSync from the device you performed the SSL Orchestrator operation to the peer device. Do NOT sync from the device which does not have SSL Orchestrator operation running.
Important: Syncing the incorrect way would result in undesired consequences.
|
| 1062625 |
When using BIG-IP 16.1.1 and SSL Orchestrator 9.2, if the devices have the same RPM, any attempt to deploy a topology results in the following error in the restnoded.log: [RestOperationDispatcher] 'shared/iapp/f5-iappslx-ssl-orchestrator/sgc-status' not found. Workaround: Restart restnoded using the following command:
bigstart restart restnoded restjavad |
| 1063589 |
The iRule does not get attached to the virtual server created for L2 Outbound topology with Custom Interception Rule. The HTTPS traffic passes when an iRule is not attached, but HTTP traffic fails. Workaround: Navigate to SSL Orchestrator configuration UI and attach the iRule manually.
|
| 1069769 |
When the one-connect setting of the ICAP service is initially disabled and then later re-enabled, followed by service redeployment, the profile is not attached to the request and response virtual servers. Workaround: Navigate back to the impacted ICAP service in the service tab of SSL Orchestrator, modify the description and redeploy the service.
|
| 1073269 |
When a Topology has multiple Services with port-remap connected, not all port_remap iRules are attached to the virtual server. Workaround: Navigate to Local TrafficVirtual Servers: Virtual Server List and find main Topology Virtual. In the Resources tab, attach the port_remap iRules.
|
