2.6. Creating an Existing Application Topology

2.6.1. What it is

The layer 3 SSL Orchestrator topology workflows build an application set that includes Interception Rules (i.e. virtual servers), SSL Settings (client and server SSL profiles), and Egress Settings (routing or load balancing). However, it may also be useful to simply integrate dynamic service chaining of decrypted traffic to services with existing LTM application virtual servers. In this case, an F5 BIG-IP LTM with configured applications can consume an SSL Orchestrator security policy, while handling their own SSL settings and traffic management. An Existing Application topology is a shortcut workflow for building just the services, service chains and a security policy. Once complete, the security policy is consumed by an LTM virtual server.

Note

The Existing Application topology requires the Local Traffic Manager (LTM) to be licensed and provisioned.


2.6.2. How to build it

The Existing Application topology is designed as a shortcut workflow to build services, service chains and a security policy.

Topology Properties User Input
The Topology Properties page provides 5 selections
Topology name Enter a unique name here.
Description Optionally enter a description here.
IP Family Select between IPv4 and IPv6.
SSL Orchestrator Topologies Select the Existing Application topology here.

Click Save & Next to proceed.


Services List User Input
For simplicity of this initial topology configuration, security services are defined in the Services chapter of this deployment guide. Please navigate to this chapter for complete information on configuration of services within SSL Orchestrator.

Click Save & Next to proceed.


Service Chain List User Input
If Services have been created per the previous step, create service chains to contain the services for use by security service policies. Click the Add button.
Name Provide a name for the service chain.
Description Optionally provide a description.
Services Move any available services over to the “Selected Service Chain Order” box, and re-order as required.
Click the Save button to proceed. Repeat this process for any additional service chains.

Click Save & Next to proceed.


Security Policy User Input

The Security Policy defines the set of traffic matching rules and corresponding actions to take on matches. The built-in security policy contains one rule:

  • All Traffic - the default catch-all rule for any traffic that does not match other rules. By default, this rule allows and intercepts (decrypts) traffic but does not preselect any service chain.

    To create additional rules, click the Add button.

Name Provide a name for this rule.
Conditions Select a condition that matches your traffic requirement.
Action Select to either Allow or Reject traffic for this traffic condition.
SSL Forward Proxy Action Select to either Intercept (decrypt) or Bypass (not decrypt) TLS traffic for this condition.
Service Chain Select a service chain to process traffic for this condition.
Click the OK button. Repeat this process for any additional rules.

Click Save & Next to proceed.


Summary User Input
The Summary page displays all of the previously defined settings and provides re-entry to each setting to make modifications before deploying.

If all is correct, click Deploy to build this transparent forward proxy SSL Orchestrator topology.

Attaching to Virtual Server User Input
Once complete, the Existing Application topology will have created a security policy that can be directly consumed by an LTM virtual server. Within an LTM virtual server configuration (Local Traffic -> Virtual Servers), find the Access Policy section.
Access Profile Select the “ssloDefault_accessProfile”.
Per-Request Policy Select the previously created Existing Application security policy.

Click Finished to update the LTM virtual server configuration.


2.6.3. How it works

SSL Orchestrator defines an existing application as a typical reverse proxy LTM virtual server, performing its own SSL handling (SSL profiles) and traffic management (assigned pool). The Existing Application SSLO topology therefore only needs to create the components that this virtual server can consume, specifically the services, service chains, and security policy. The Existing Application SSLO workflow skips SSL management, interception rules and egress settings, and ultimately produces an SSLO-type per-request policy that can be attached to an existing LTM virtual server.

  • Topology Properties

    The Existing Application Topology is protocol agnostic, so only specifies an IP family selection of either IPv4 or IPv6.


  • Services

    The Services List page is used to define security services that attach to SSL Orchestrator. The Guided Configuration includes a services catalog that contains common product integrations. Each icon represents a security product integration deployed as one of the five basic service types. The service catalog also provides “generic” security services if your security service is not included in the catalog. Depending on screen resolution, it may be necessary to scroll down to see additional services.


    ../_images/image26.png

    Figure 26: SSL Orchestrator service catalog


    For simplicity of this initial topology configuration, security services are defined in the Services chapter. Please navigate to this chapter for complete information on configuration of the various services.


  • Service Chain List

    Service Chains are ordered lists of security devices. Based on environmental requirements, different service chains may contain different re-used sets of services, and different types of traffic can be assigned to different service chains.


    ../_images/image27.png

    Figure 27: SSL Orchestrator logical security policy and service chaining


  • Security Policy

    Security Policies are the set of rules that govern how traffic is processed in SSL Orchestrator, and the actions a rule can take include,

    • Whether or not to allow the traffic (Allow or Reject)
    • Whether or not to decrypt the traffic (Intercept or Bypass)
    • Which service chain (if any) to pass the traffic through

    The Guided Configuration presents an intuitive rule-based, drag-and-drop user interface for the definition of security policies. Note that the default “All Traffic” rule allows and intercepts (decrypts) traffic but does not assign a service chain. To be effective, it is advisable to assign a service chain here.

    ../_images/image28.png

    Figure 28: SSL Orchestrator basic security policy

    In the background, SSL Orchestrator maintains these security policies as visual per-request policies. If traffic processing is required that exceeds the capabilities of the rule-based user interface, the underlying per-request policy can be managed directly.


    Note

    Once the per-request policy is manipulated, the rules-based user interface can no longer be used.


  • Summary

    The Summary page presents an expandable list of all of the workflow-configured objects. To expand the details for any given setting, click the corresponding arrow icon on the far right. To edit any given setting, click the corresponding pencil icon. Clicking the pencil icon will send the workflow back to the selected settings page.

    Upon successfully deploying the configuration, SSL Orchestrator will now display a Configure view.


    ../_images/image29.png

    Figure 29: Guided Configuration landing page


    The Existing Application topology does not create Interception Rules.


  • Attaching to an LTM virtual server

    The Existing Application topology will have created a security policy that can be directly consumed by an LTM virtual server. This manifests as an Access per-request policy. The Access per-session policy is static, un-editable and created by default. Both of these policies are of type “SSL Orchestrator”. This type of policy is “session-less” and does not require Access Policy Manager (APM) to be licensed and provisioned.


    • Access Profile - select the “ssloDefault_accessProfile”.


    • Per-Request Policy - select the previously-created Existing Application security policy.


    ../_images/image30.png

    Figure 30: Attaching an Existing Application topology to a virtual server