Original Publication Date: 04/07/2017
This release note documents the version 13.0.0 release of F5 SSL Orchestrator with F5 SSL Intercept iAppLX version 2.1.
This version of F5 SSL Orchestrator is supported on the following platforms:
The SSL Orchestrator license is the only Base module that is installed on your system. However, you can add the following modules:
For more information about purchasing other module licenses, contact your F5 Sales representative.
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:
This version of F5 SSL Orchestrator supports version 2.1 of the F5 SSL Orchestrator iAppLX template.
For a comprehensive list of documentation that is relevant to this release, refer to the F5 SSL Orchestrator 13.0.0 Documentation page.
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.
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 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 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:
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.
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.
Later, after a successful SSL Orchestrator HA deployment, you should verify that the same version appears on the BIG-IP HA peer device.
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.
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.
In the Address field, make sure that the VLAN address (ha_vlan) is present.
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.
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.
The Device Group List page appears listing your new device group. The ConfigSync Status column will indicate Awaiting Initial Sync.
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.
You have now completed your SSL Orchestrator high availability deployment. Next, setup a basic configuration for deployment on your Active device.
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.
If the versions are not identical, you must install an updated .rpm file and verify that both boxes are identically configured.
If this succeeds, you have recovered from the failure situation.
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.
The following fixes are included in SSL Orchestrator 13.0.0.
|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.|
|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.|
|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.|
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.|
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.
|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.|
|After the server certificate is already cached the subsequent connections may receive a redirect response.|
|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.|
|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.|
For additional information, please visit http://www.f5.com.
You can find additional support resources and technical documentation through a variety of sources.
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 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.
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.