4.16. Implementing LTM Policy Integration

4.16.1. What it is

SSL Orchestrator security policies are a specialized function of Access per-request policies. In the SSL Orchestrator 11.0 release, a new LTM policy engine construct has been introduced for the Inbound Application Mode topology that reduces much of the Access policy overhead. LTM policy provides an alternative to per-request policy that yields higher performance and reduced CPU usage on specific conditions/actions supporting SSL Orchestrator. For an Inbound Application Mode topology, you can select between the classic per-request policy, or an LTM policy. Note also in this release that LTM policies will provide a subset of the traffic conditions available in the per-request policy. These are:

  • Client IP subnet

  • Client IP geolocation

  • Client IP reputation

  • Client port

  • IP protocol

  • Server IP subnet

  • Server IP geolocation

  • Server IP reputation

  • Server port

  • Server Name (TLS ClientHello)

The LTM policy also provides an enhancement to perform granular traffic logging by using collect data actions.

The below information describes how to insert security services into the matching traffic flows with LTM policies.


4.16.2. How to build it

To use LTM policies, configure an Inbound Application Mode topology in SSL Orchestrator. On the Security Policy page of the topology workflow, you are presented with two Provider options:

  • Per Request Policy

  • LTM Policy

When the latter (LTM Policy) is selected, the available conditions are modified to include the above list. Create a security policy as usual. To view the resulting LTM policy, navigate in the BIG-IP UI to Local Traffic -> Policies. There will be three policies created:

  • ssloP_<policy_name>_ltm_pol: this contains the LTM policy logic derived from the SSL Orchestrator security policy rules. Because this policy is derived, it is created in Strict Mode and cannot be edited directly.


  • ssloP_<policy_name>_log _ltm_pol: this contains a set of actions to be applied to all traffic to log general traffic flow data.


  • ssloP_<policy_name>_logssl_ltm_pol: this contains a set of actions to be applied to all traffic to log SSL flow data.

Only the “_ltm_pol” policy is initially attached to the topology. To add the others, navigate to the representative LTM virtual server for the topology, in Local Traffic -> Virtual Servers. Edit the topology virtual server and go to the Resources tab. Click the “Manage…” button under Policies and add the additional logging policies, as required.

Note, as a general rule, actions should be applied in OSI layer order. Any layer 3 or layer 4 conditions (IP, port match) should be specified first in the rule list, with “at client accepted time”. Any SSL conditions should be specified last, with “at ssl client hello”. If any layer 3 or layer condition is defined after an SSL condition, that layer 3/4 condition must also specify “at ssl client hello”.

When a security service is created in SSL Orchestrator, it creates one or more “Connector” profiles. These are the objects responsible for passing traffic to the security service, and can come in different forms, based on layer 4 and IP protocols. For example, a layer 2 service will create four Connectors:

  • -t-4 for TCP IPv4

  • -t-6 for TCP IPv6

  • -u-4 for UDP IPv4

  • -t-6 for UDP IPv6