Release Notes : F5 SSL Orchestrator Release Notes version 13.0.0 with F5 SSL Intercept iAppLX version 2.1

Applies To:

Show Versions Show Versions

F5 SSL Orchestrator

  • 13.0.0
Release Notes
Original Publication Date: 09/11/2018 Updated Date: 12/09/2021

Summary:

This release note documents the version 13.0.0 release of F5 SSL Orchestrator with F5 SSL Intercept iAppLX version 2.1.

Contents:

 

Configuration utility browser support

The F5 SSL Orchestrator iAppLX template acts as the configuration utility for SSL Orchestrator. SSL Orchestrator supports these browsers and versions for use with the configuration utility:

  • Microsoft Internet Explorer 11.x - Only 32-bit browsers are supported.
  • Mozilla Firefox 27.x
  • Google Chrome 32.x

iAppLX template support

This version of F5 SSL Orchestrator supports version 2.1 of the F5 SSL Orchestrator iAppLX template.

User documentation for this release

For a comprehensive list of documentation that is relevant to this release, refer to the F5 SSL Orchestrator 13.0.0 Documentation page.

SSL Orchestrator features in 13.0.0

F5 SSL Orchestrator

F5 SSL Orchestrator provides an all-in-one appliance solution designed specifically to optimize the SSL infrastructure, provide security devices with visibility of SSL/TLS encrypted traffic, and maximize efficient use of that existing security investment. This solution supports policy-based management and steering of traffic flows to existing security devices, designed to easily integrate into existing architectures, and centralizes the SSL decrypt/encrypt function by delivering the latest SSL encryption technologies across the entire security infrastructure.

Multi-Layered Security

In order to solve specific security challenges, security administrators are accustomed to manually chaining together multiple point products, creating a bare-bones “security stack” consisting of multiple services. A typical stack may include components like Data Leak Prevention (DLP) scanners, Web Application Firewalls (WAF), Intrusion Prevention and Detection Systems (IPS and IDS), Malware Analysis tools, and more. In this model, all user sessions are provided the same level of security, as this “daisy chain” of services is hard-wired.

Dynamic Service Chaining

Dynamic Service Chaining processes specific connections based on context provided by the Classification Engine. These service chains can include four types of services (Layer 2 in-line services, Layer 3 in-line services, receive-only services, and ICAP services) you define, as well as any decrypt zone between separate ingress and egress devices).

Classification Engine

Classification Engine provides a rich set of methods based on context to dynamically determine how best to optimize the flow through the security stack. Context can come from the following:

  • Source IP/subnet
  • Destination IP/subnet
  • IP intelligence category - Subscription
  • IP geolocation
  • Host and domain name
  • URL filtering category - Subscription
  • Destination port
  • Protocol

Deployment modes

F5 recommends, and has optimized the SSL Orchestrator for deployment in an active-inline mode. This mode supports the broadest set of industry recommended ciphers suites, enables policy-based steering to allow for better utilization of the security services investments deployed at either OSI Layer 2 or Layer 3, and helps reduce administrative costs through efficient steering based on traffic context through selective device load balancing and health monitoring.

Setting up SSL Orchestrator in a High Availability Environment

Overview: Setting up SSL Orchestrator in a high availability environment

SSL Orchestrator deployment of High Availability (HA) ensures a decrease in downtime and eliminates single points of failure. The deployment of SSL Orchestrator’s HA works in concert with the BIG-IP® device groups support to sync the SSL Orchestrator specific configuration items and is transparent to the user. The deployment occurs after completing a configuration change and selecting Deploy. The deploy request is first routed to one of the devices in the HA device group. This first device configures the box where the request is received. After successful deployment on that box, the request is repeated on other BIG-IP devices. With SSL Orchestrator installed onto a dedicated system with failover, it automatically takes over in case of system failure. Data is synchronized between the two systems ensuring high availability and consistent protection.

Assumptions and dependencies

  • HA Setup: BIG-IP® HA (CMI) must be set to Active-Standby mode with network failover. See the BIG-IP Device Service Clustering: Administration document for detailed information on Active-Standby HA mode.
  • HA Setup: If the deployed device group is not properly synced or .rpm packages are not properly syncing, make sure your HA self IP (for example, ha_self) Port Lockdown is not set to Allow None. On the Main tab, click Network > Self IPs and click on your ha_self. If Port Lockdown is set to Allow Custom, check that the HA network port 443 is open on self IP.
  • BIG-IP HA Devices: Only manual sync is supported.
  • BIG-IP HA Devices: For use with SSL Orchestrator iApp 2.1, the devices in each BIG-IP HA pair must be the same model and run the same version of TMOS (including any hotfixes). Except for the management interface, you must configure both devices to use the same arrangement of network interfaces, trunks, VLANs, self IPs (address and subnet mask), and routes. For example, if one BIG-IP is connected to a specific VLAN/subnet via interface 1.1, the other BIG-IP must also be connected to that VLAN/subnet via interface 1.1. If the BIG-IP configurations do not match, this solution will not deploy correctly and HA failover will not work.
  • User Experience: False positive configuration conflicts in the HA environment must be ignored.
  • User Experience: Deployment must be initiated from Active HA BIG-IP.
  • User Experience: If a non HA environment is changed to an HA environment, the application must be redeployed. Similarly, if an HA environment is changed to a non HA environment, the application must be redeployed.
  • User Experience: The SSL Configuration page (SSL Orchestrator > Configuration) for each peer device can be refreshed in order to see all modified changes.

SSL Orchestrator high availability deployment

To ensure that your SSL Orchestrator HA deployment succeeds, it is critical that each deployment step, as well as the assumptions and dependencies, are closely followed for both boxes. In addition, adhere to all prerequisites, noting that if the systems in the device group are not configured consistently, the deployment synchronization process may fail.
  • Installing an updated .rpm file
  • Configuring the network for high availability
    • Configuring the ConfigSync and Failover IP address
    • Adding a device to the local trust domain
    • Creating a Sync-Failover device group
  • Synchronizing the device group
  • Setting up a basic configuration for deployment
It is also critical to test the deployment after configuration as some failures may not be reported in the UI.

Prerequisites:

  • You have made sure that the information used to configure your devices are identical on both boxes before configuring the network for high availability. Without identical information on both devices, noted throughout the following steps, the HA deployment may fail.
  • You must have successfully setup a HA ConfigSync device group prior to starting configuration. Basic instructions are below. For more detailed instructions, refer to the BIG-IP Device Service Clustering: Administration document, section Managing Configuration Synchronization.
  • You have successfully installed the most current .rpm file on the first device (the Active device).
  • You have already installed SSL Orchestrator with the appropriate license information using the SSL Orchestrator Setup Wizard (or the CLI) and made sure your device setup information is identical on both boxes:
    • While using the SSL Orchestrator Setup Wizard, you have noted the details used for NTP and DNS setup and made sure they will be identical on both boxes. You may verify duplication by selecting System > Configuration > Device > NTP (or DNS).
    • You have made sure that any certificates used in the configuration are copied to all devices.
    • You have made sure that information is identical on all devices. This information should include any of the following that are needed:
      • Client network
      • External network
      • Decrypt zone network
      • Decrypt zone control network
      • Networks providing access to:
        • ICAP devices
        • Receive-only devices
    • You have made sure the log publishers are configured and named the same.
    • You have made sure all systems use the same interfaces for any services (if interface 1.1 is used to send traffic to an inline layer 2 device on system A, interface 1.1 must also be used on systems B, C, and D).
    Note: Do not attempt to duplicate the configuration by saving and restoring a user configuration set (UCS) file from one machine to the other or any other cloning approach. There are several IDs that are required to be unique that will also be duplicated, causing additional problems.
    Note: For more detailed information on using the SSL Orchestrator Setup Wizard, see the F5 Herculon SSL Orchestrator: Setup document.

Installing an updated .rpm file

Make sure you have the latest version of SSL Orchestrator. This will establish the version that will later appear on your other BIG-IP® HA peer device. After downloading the latest version of the SSL Orchestrator zip file from downloads.F5.com, return to your SSL Orchestrator configuration utility. See the F5 Herculon SSL Orchestrator Setup document, section Update the SSL Orchestrator version, for more detailed installation instructions.
  1. Create a backup of your current configuration.
  2. On the Main tab, click SSL Orchestrator > Updates.
  3. In the File Name field, click Browse and navigate to the file you saved onto your system.
  4. Click Open to select it.
  5. Click Install.
    Note: Only install the iApp package (the *.rpg file) on the Active system. That system will copy it to the other systems in the ConfigSync group.

    Later, after a successful SSL Orchestrator HA deployment, you should verify that the same version appears on the BIG-IP HA peer device.

Configuring the network for high availability

On the Active device, specify the settings for VLAN HA and self IP addresses. If needed, configure all devices involved in the high availability group for HA.

Note: This network will connect the various devices and must be a common layer-2 network between all devices.
  1. On the Main tab, click Network > VLANs. The VLAN List page appears.
  2. Click Create. A new page appears to configure your new VLAN.
  3. In the Name field of General Properties, enter the name (for example, ha_vlan).
  4. For the Interfaces setting:
    1. From the Interfaces list, select an interface number.
    2. From the Tagging list, select Tagged for traffic, for that interface, to be tagged with a VLAN ID.
    3. Click Add. The interface number you selected will appear as a tagged service.
    4. Select Finished.
    5. Next to the F5 logo, your device status will appear showing ONLINE (ACTIVE) and Standalone with green indicators showing their status as up and running.
  5. On the Main tab, click Network > Self IPs. The New Self IP Configuration page appears.
  6. In the Name field, enter the self IP name (for example, ha_self).
  7. In the IP Address field, enter the IP address for the device.
  8. In the Netmask field, enter the netmask for the device.
  9. In the VLAN/Tunnel field, select the VLAN name (ha_vlan).
  10. Click Finished.

Configuring the ConfigSync and failover IP address

Before creating the device group, you should configure the configuration synchronization (ConfigSync) and Failover IP addresses for each BIG-IP® system in the device group. The ConfigSync address is the IP address that the system uses when synchronizing configuration with peer devices, and the Failover address is the IP address that the system uses for network failover.

  1. On the Main tab, click Device Management > Devices. The Device List page appears with your current device showing in the list.
  2. Click on your device in the device list. The device Properties page appears.
  3. Select the ConfigSync tab. The ConfigSync Configuration section appears showing the Local Address of that device.
  4. From the Local Address list, select the VLAN address (ha_vlan).
  5. Click Update.
  6. Select the Failover Network tab and click Add. The New Failover Unicast Address page opens.

    In the Address field, make sure that the VLAN address (ha_vlan) is present.

  7. Click Repeat.
  8. After the page refreshes, from the Address list, select the Management Address.
    Note: Connection Mirroring is not supported.
  9. Click Finished. The Failover Unicast Configuration section will list both the VLAN HA (ha_valn) and Management Address devices.

Adding a device to the local trust domain

Any BIG-IP® devices that you intend to add to a device group must first be members of the same local trust domain. When a BIG-IP device joins the local trust domain, it establishes a trust relationship with peer BIG-IP devices that are members of the same trust domain. For example, if you are creating a device group with two members, you must log in to one of the devices and join the other device to that system's local trust domain. The devices can then exchange their device properties and device connectivity information.

  1. On the Main tab, click Device Management > Device Trust. The Local Domain page appears.
  2. Select the Device Trust Members tab. The Peer and Subordinate Devices page appears.
  3. Click Add. The Device Trust page appears with the Retrieve Device Credentials (Step 1 of 3) section.
  4. In the Device Type field, select Peer.
  5. In the Device IP Address, enter the IP address of your device.
  6. Click Retrieve Device Information. The Verify Device Certificates (Step 2 of 3) section appears.
  7. Click Device Certificate Matches. The Add Device (Step 3 of 3) section appears.
  8. In the Name field, enter the name of the device you are adding.
  9. Click Add Device. Next to the F5 logo, the status of your device should show ONLINE (ACTIVE) and Connected with a green indicator next to it showing its active and connected status.

Creating a sync-failover device group

This task establishes failover capability between two or more BIG-IP® devices. If an active device in a Sync-Failover device group becomes unavailable, the configuration objects fail over to another member of the device group and traffic processing is unaffected. You perform this task on any one of the authority devices within the local trust domain.

  1. On the Main tab, click Device Management > Device Groups. The New Device Group page appears.
  2. Click Create.
  3. In the General Properties section, do the following:
    1. In the Name field, enter the name of your device group.
    2. In the Group Type field, select Sync-Failover from the list.
  4. In the Configuration section, do the following:
    1. In the Members field, select both available devices from the Available list and add them to the Includes list.
    2. In the Sync Type field, select Manual with Incremental Sync.
      Note: You must do a manual sync. If you select Automatic with Incremental Sync, your HA deployment will fail.
  5. Click Finished.

    The Device Group List page appears listing your new device group. The ConfigSync Status column will indicate Awaiting Initial Sync.

Synchronizing the device group

This task synchronizes the BIG-IP® configuration data from the local device to the devices in the device group. This synchronization ensures that devices in the device group operate properly. When synchronizing self IP addresses, the BIG-IP system synchronizes floating self IP addresses only.

  1. Next to the F5 logo, click on Awaiting Initial Sync. The Device Management Overview page appears showing your Device Groups.
  2. In the Sync Issues section, select ha to expand the Devices and Sync Options sections.
  3. In the Devices section, make sure you select the device showing Changes Pending.
  4. In the Sync Options section, select Push the selected device configuration to the group.
  5. Click Sync.

You have now completed your SSL Orchestrator high availability deployment. Next, setup a basic configuration for deployment on your Active device.

Setting up a basic configuration for deployment

Please refer to the F5 Herculon SSL Orchestrator: Setup document for detailed instructions on completing the basic configuration on your Active device.
Note: You must create identical information on each device before deploying the configuration.

After deploying your configuration on the Active device, the configuration is automatically synchronized with all of the other devices in the device group. Since some errors may not be apparent, it is critical that you thoroughly test and diagnose the success or failure of the deployment. The following steps can be taken to test the system.

Task summary for diagnosing and fixing high availability deployment

Even though the potential for SSL Orchestrator HA deployment is low, thorough verification is recommended. If your HA deployment fails, attempt:
  • Verifying deployment and viewing logs
  • Verifying the .rpm file version on both devices
  • Configuring general properties and redeploying
  • Reviewing error logs and performing recovery steps

Verifying deployment and viewing logs

Verify that all expected and required virtuals, profiles, and BIG-IP® LTM and network objects (route-domains, VLANs, self IPs) have been created on each device in the HA device group. These will be items beginning with the name given to the application (for example, if the application was named SSLO, verify that all of the items named SSLO_* are the same on all boxes). Ensure that the .rpm files are in sync, verify deployment with or without services, and review the following logs for failures:
  • /var/log/restnoded/restnoded.log
  • /var/log/restjavad.0.log
Note: Because the initial device in the HA device group repeats the configuration requests and propagates the configuration to other BIG-IP devices, make sure you verify the initial configured device first, followed by each device in the HA device group. If the initial device deployment configuration fails, all other device configuration deployments will not successfully be configured.

Verifying the .rpm file version on both devices

After a successful SSL Orchestrator HA deployment, verify that the latest version of the SSL Orchestrator zip file is installed on both devices.
  1. On the Main tab, click SSL Orchestrator > Updates.
  2. Check the versions in the Version field.

If the versions are not identical, you must install an updated .rpm file and verify that both boxes are identically configured.

Configuring general properties and redeploying

  1. Remove all configurations present on all devices.
    Note: You may want to restore a backup file instead, per device, to remove all current configurations.
  2. For all devices, individually configure each section in the iApp and select Deploy. Verify that all new objects are properly synced and deployed.
    Note: If synchronization or deployment issues persist after deploying after each section, attempt to deploy after updating each item (instead of after each section) in the iApp and verify that all new objects are properly synced and deployed.
    Note: See the F5 Herculon SSL Orchestrator Setup document, section Configuring general properties, for more detailed information.

Reviewing error logs and performing recovery steps

  1. Verify that all BIG-IP® LTM and network objects are present on each of the devices in the HA device group.
  2. If the configuration deployment fails on each device, review the logs:
    • /var/log/restnoded/restnoded.log
    • /var/log/restjavad.0.log
  3. Use the following REST GET command to determine the state of the deployed device block in the REST storage:
  4. Since failure scenarios can vary, after reviewing the logs, attempt the following recovery steps:
    1. Redeploy SSL Orchestrator.

      If this succeeds, you have recovered from the failure situation.

    2. Undeploy SSL Orchestrator.

      By undeploying, a cleanup of MCP objects on each of the boxes occurs while also cleaning up required data properties within the block stored in REST storage. If this succeeds, attempt to redeploy again.

    3. If redeploy or undeploy fails, do the following:
      1. From command line (back door), run > touch /var/config/rest/iapps/enable.
      2. Refresh the SSL Orchestrator menu UI.
      3. Select the deployed application from the list and delete the application.
      4. Redeploy and undeploy again.
      5. Once done, remove the file rm -f /var/config/rest/iapps/enable.
    4. If these recovery steps do not work, you may need to clean up the REST storage.
Note: For more detailed information on setting up HA, see the BIG-IP Device Service Clustering: Administration document. For more detailed information on setting up SSL Orchestrator, see the F5 Herculon SSL Orchestrator: Setup document.

Fixes in 13.0.0

The following fixes are included in SSL Orchestrator 13.0.0.

ID number Description
622859 After creating an L2 inline service, the field showing added members now expands and is scrollable so all members are visible.
632106 Control channel implementation in SSL Orchestrator two box mode no longer drops control messages under load.
632265 After creating a TCP classifier rule with a pre-handshake phase and HTTP protocol, the DDB option correctly appears in the mode dropdown list.
632375 Pinners data group list was resetting when re-deploying the app. User modified pinners are now being retained in the Pinners data group list after re-deploying the app.
633577 SSL Orchestrator, when deployed in 2-box mode, did not correctly SNAT the client traffic. Fixed the code to generate the SNAT pool and fixed the corresponding -ctx datagroup for the egress device with the proper value for ex_snat to either "snat automap" for automap selection or the SNAT pool object name.
633956 SSL Orchestrator did not associate any VLAN to the virtual server created for handling UDP traffic. Fixed the code to correctly associate the client side of VLAN to UDP and non-tcp non-udp (-ot) virtual.

Behavior changes in 13.0.0

ID Number Description
640276 SSL Orchestrator deploy times out on Herculon i2800 Platform. Workaround: Go to "System :: Resource Provisioning" on TMUI, change Management (MGMT) provision level to "Medium" and try to deploy again. Platforms with a SSL Orchestrator license should have Management module provisioned at "Medium" level by default and should be able to deploy SSL Orchestrator successfully.
643854 The initial TPS ramp-up time for two box transparent proxy setup with iApp 2.1 takes about 50 seconds before it increases.
643870 iApp 2.1 is unable to sustain TPS performance when two box explicit proxy is configured.
646382 TPS performance dips when configuring a BIG-IP one box explicit proxy using iApp configuration policies for URLF bypass.
646430 There is a 20% drop in TPS performance when AVR analytics is turned on.

Known issues

ID number Description
623179 Clicking on the L3 name for inline services so to reconfigure it results in the drop down menu that lists interfaces to not load and is empty.
623441 Creating a receive only service using a VLAN, newly created with an interface using TMSH, results in the UI not updating the interface to correspond with the newly created VLAN.
624393 Deleting the SSL Orchestrator iApp from TMSH is not recommended. It is recommended that you use the SSL Orechestrator UI to manage the iApp.
641628 The SSL Orchestrator two box solution sends decrypt zone traffic directly to connected servers even if a specific route to the egress box is specified. This occurs even if there is a specific route to the egress box set up on the ingress box. It is recommended that you avoid setting up directly connected servers to the ingress box.
643713 IMAPS traffic hangs when the service chain has an ICAP.
643746

When choosing SNAT in the iApp, others virtual does not translate the address. If a request is sent from a private IP to the internet, traffic processed by others virtual does not come back to the BIG-IP.

644182 The IPI Subscription as an add-on to the SSL Orchestrator license fails to initialize and automatically download the IP reputation database.
644518 HTTPS traffic on a non-standard port with ICAP in the service chain causes the request to hang indefinitely.
644838

Deleting the first created classifier rule incorrectly deletes the classifier rule that was created last. Each additional deletion results in the deletion of a rule in reverse order.

645080

Creating a UDP classifier rule with protocol options QUIC or QQQQ updates the UDP rules data-group with ‘undefined’.
645651 Deploying the SSLO iAPPL application will sometimes timeout with the LTM log showing the system to be very slow. The UI will display a lost connection window. Workaround: Undeploy and then deploy again or try using a different system resource provisioning and redeploy.

645662

After the server certificate is already cached the subsequent connections may receive a redirect response.

645696

In a two-box deployment, a configuration request may fail when the client connection goes through an L3 inline service resulting in the error: legacy not found/empty.

645737

After an inline service configuration is deleted, the iApp reconfigures all inline services and requires IP addresses on L3 devices to be reconfigured.
651165 SSL Orchestrator application traffic does not pass-through when HA failover for Ixia client. When using HA failover in SSL Orchestrator, traffic does not pass-through for traffic coming from the Ixia client. SSLO uses the "default" SSL key to generate the temporary certificates to communicate with the client. Each box in HA will have its own "default" SSL key (which does not sync to peer) and both will have identical names but their contents might differ. Therefore, a temporary certificate used in establishing the SSL connection with the client (Ixia) may not be compatible with the "default" key on the peer when traffic failover occurs. Traffic should work for new clients after failover, but in this case, Ixia client is trying to communicate using the same old SSL certificate (it may be cached somewhere) thus causing traffic to fail. Workaround: First, deploy SSL Orchestrator by disabling strict updates. Second, go to "Local Traffic ›› Profiles : SSL : Client ›› <app_name>-cssl" and remove "default". Lastly, add any other RSA Certificate Key Chain and save. Note: This workaround will not persist across the SSLO deployments and needs to be done every time an SSLO application is deployed.

Contacting F5 Networks

For additional information, please visit http://www.f5.com.

Additional resources

You can find additional support resources and technical documentation through a variety of sources.

F5 Networks Technical Support

Free self-service tools give you 24x7 access to a wealth of knowledge and technical support. Whether it is providing quick answers to questions, training your staff, or handling entire implementations from design to deployment, F5 services teams are ready to ensure that you get the most from your F5 technology.

AskF5

AskF5 is your storehouse for thousands of solutions to help you manage your F5 products more effectively. Whether you want to search the knowledge base periodically to research a solution, or you need the most recent news about your F5 products, AskF5 is your source.

F5 DevCentral

The F5 DevCentral community helps you get more from F5 products and technologies. You can connect with user groups, learn about the latest F5 tools, and discuss F5 products and technology.

AskF5 TechNews

Weekly HTML TechNews
The weekly TechNews HTML email includes timely information about known issues, product releases, hotfix releases, updated and new solutions, and new feature notices. To subscribe, click TechNews Subscription, complete the required fields, and click the Subscribe button. You will receive a confirmation. Unsubscribe at any time by clicking the Unsubscribe link at the bottom of the TechNews email.
Periodic plain text TechNews
F5 Networks sends a timely TechNews email any time a product or hotfix is released. (This information is always included in the next weekly HTML TechNews email.) To subscribe, send a blank email to technews-subscribe@lists.f5.com from the email address you are using to subscribe. Unsubscribe by sending a blank email to technews-unsubscribe@lists.f5.com.

Legal notices