SSL Orchestrator Advanced Use Cases: Reducing Complexity with Internal Layered Architecture

Introduction

Sir Isaac Newton said, "Truth is ever to be found in the simplicity, and not in the multiplicity and confusion of things". The world we live in is...complex. No getting around that. But at the very least, we should strive for simplicity where we can achieve it. As IT folk, we often find ourselves mired in the complexity of things until we lose sight of the big picture, the goal. How many times have you created an additional route table entry, or firewall exception, or virtual server, because the alternative meant having a deeper understanding of the existing (complex) architecture? Sure, sometimes it's unavoidable, but this article describes at least one way that you can achieve simplicity in your architecture. SSL Orchestrator sits as an inline point of presence in the network to decrypt, re-encrypt, and dynamically orchestrate that traffic to the security stack. You need rules to govern how to handle specific types of traffic, so you create security policy rules in the SSL Orchestrator configuration to describe and take action on these traffic patterns. It's definitely easy to create a multitude of traffic rules to match discrete conditions, but if you step back and look at the big picture, you may notice that the different traffic patterns basically all perform the same core actions. They allow or deny traffic, intercept or bypass TLS (decrypt/not-decrypt), and send to one or a few service chains. If you were to write down all of the combinations of these actions, you'd very likely discover a small subset of discrete "functions". As usual, F5 BIG-IP and SSL Orchestrator provide some innovative and unique ways to optimize this. And so in this article we will explore SSL Orchestrator topologies "as functions" to reduce complexity. Specifically, you can reduce the complexity of security policy rules, and in doing so, quite likely increase the performance of your SSL Orchestrator architecture.

SSL Orchestrator Use Case: Reducing Complexity with Internal Layered Architectures

The idea is simple. Instead of a single topology with a multitude of complex traffic pattern matching rules, create small atomic topologies as static functions and steer traffic to the topologies by virtue of "layered" traffic pattern matching. Granted, if your SSL Orchestrator configuration is already pretty simple, then please keep doing what you're doing. You've got this, Tiger. But if your environment is getting complex, and you're not quite convinced yet that topologies as functions is a good idea, here are a few additional benefits you'll get from this topology layering:

  • Dynamic egress selection: topologies as functions can define different egress paths.
  • Dynamic CA selection: topologies as functions can use different local issuing CAs for different traffic flows.
  • Dynamic traffic bypass: certain types of traffic can be challenging to handle internally. For example, mutual TLS traffic can be bypassed globally with the "Bypass on client cert failure" option in the SSL configuration, but bypassing mutual TLS sites by hostname is more complex. A layered architecture can steer traffic (by SNI) through a bypass topology, with a service chain.
  • More flexible pattern recognition: for all of its flexibility, SSL Orchestrator security policy rules cannot catch every possible use case. External traffic pattern recognition, via iRules or CPM (LTM policies) offer near infinite pattern matching options. You could, for example, steer traffic based on incoming tenant VLAN or route domain for multi-tenancy configurations.
  • More flexible automation strategies: as iRules, data groups, and CPM policies are fully automate-able across many AnO platforms (ex. AS3, Ansible, Terraform, etc.), it becomes exceedingly easy to automate SSL Orchestrator traffic processing, and removes the need to manage individual topology security policy rules.

Hopefully these benefits give you a pretty clear indication of the value in this architecture strategy. So without further ado, let's get started.

Configuration

Before we begin, I'd like to make note of the following caveats:

  • While every effort has been made to simplify the layered architecture, there is still a small element of complexity. If you are at all averse to creating virtual servers or modifying iRules, then maybe this isn't for you. But as you are reading this in a forum dedicated to programmability, I'm guessing you the reader are ready for a challenge.
  • This is a "field contributed" solution, so not officially supported by F5.
  • This topology layering architecture is applicable to all modern versions of SSL Orchestrator, from 5.0 to 8.0.
  • While topology layering can be used for inbound topologies, it is most appropriate for outbound. The configuration below also only describes the layer 3 implementation. But layer 2 layering is also possible.

With this said, there are just a few core concepts to understand:

  • Basic layered architecture configuration - how the pieces fit together
  • The iRules - how traffic moves through the architecture
  • Or the CPM policies - an alternative to iRules

Note again that this is primarily useful in outbound topologies. Inbound topologies are typically more atomic on their own already. I will cover both transparent and explicit forward proxy configurations below.

Basic layered architecture configuration

A layered architecture takes advantage of a powerful feature of the BIG-IP called "VIP targeting". The idea is that one virtual server calls another with negligible latency between the two VIPs. The "external" virtual server is client-facing. The SSL Orchestrator topology virtual servers are thus "internal". Traffic enters the external VIP and traffic rules pass control to any of a number of internal "topology function" VIPs.

You certainly don't have to use the iRule implementation presented here. You just need a client-facing virtual server with an iRule that VIP-targets to one or more SSL Orchestrator topologies. Each outbound topology is represented by a virtual server that includes the application server name. You can see these if you navigate to Local Traffic -> Virtual Servers in the BIG-IP UI. So then the most basic topology layering architecture might just look like this:

when CLIENT_ACCEPTED {
  virtual "/Common/sslo_my_topology.app/sslo_my_topology-in-t-4"
}

This iRule doesn't do anything interesting, except get traffic flowing across your layered architecture. To be truly useful you'll want to include conditions and evaluations to steer different types of traffic to different topologies (as functions).

As the majority of security policy rules are meant to define TLS traffic patterns, the provided iRules match on TLS traffic and pass any non-TLS traffic to a default (intercept/inspection) topology. These iRules are intended to simplify topology switching by moving all of the complexity of traffic pattern matching to a library iRule. You should then only need to modify the "switching" iRule to use the functions in the library, which all return Boolean true or false results. Here are the simple steps to create your layered architecture:

  • Step 1: Build a set of "dummy" VLANs. A topology must be bound to a VLAN. But since the topologies in this architecture won't be listening on client-facing VLANs, you will need to create a separate VLAN for each topology you intend to create. A dummy VLAN is a VLAN with no interface assigned. In the BIG-IP UI, under Network -> VLANs, click Create. Give your VLAN a name and click Finished. It will ask you to confirm since you're not attaching an interface. Repeat this step by creating unique VLAN names for each topology you are planning to use.
  • Step 2: Build a set of static topologies as functions. You'll want to create a normal "intercept" topology and a separate "bypass" topology, though you can create as many as you need to encompass the unique topology functions. Your intercept topology is configured as such:
    • L3 outbound topology configuration, normal topology settings, SSL configuration, services, service chains
    • No security policy rules - just the ALL rule with TLS intercept action (and service chain), and optionally remove the built-in Pinners rule
    • Attach to a dummy VLAN (a VLAN with no assigned interfaces)

Your bypass topology should then look like this:

  • L3 outbound topology configuration, skip the SSL Configuration settings, optionally re-use services and service chains
  • No security policy rules - just the ALL rule with TLS bypass action (and service chain)
  • Attach to a separate dummy VLAN (a VLAN with no assigned interfaces)

Note the name you use for each topology, as this will be called explicitly in the iRule. For example, if you name the topology "myTopology", that's the name you will use in each "call SSLOLIB::target" function (more on this in a moment) . If you look in the SSL Orchestrator UI, you will see that it prepends "sslo_" (ex. sslo_myTopology). Don't include the "sslo_" portion in the iRule.

  • Step 3: Import the SSLOLIB iRule (attached here). Name it "SSLOLIB". This is the library rule, so no modifications are needed. The functions within (as described below) will return a true or false, so you can mix these together in your switching rule as needed.
  • Step 4: Import the traffic switching iRule (attached here). You will modify this iRule as required, but the SSLOLIB library rule makes this very simple.
  • Step 5: Create your external layered virtual server. This is the client-facing virtual server that will catch the user traffic and pass control to one of the internal SSL Orchestrator topology listeners.
    • Type: Standard
    • Source: 0.0.0.0/0
    • Destination: 0.0.0.0/0
    • Service Port: 0
    • Protocol: TCP
    • VLAN: client-facing VLAN
    • Address Translation: disabled
    • Port Translation: disabled
    • Default Persistence Profile: ssl
    • iRule: the traffic switching iRule

Note that the ssl persistence profile is enabled here to allow the iRules to handle client side SSL traffic without SSL profiles attached. Also make sure that Address and Port Translation are disabled before clicking Finished.

  • Step 6: Modify the traffic switching iRule to meet your traffic matching requirements (see below).

You have the basic layered architecture created. The only remaining step is to modify the traffic switching iRule as required, and that's pretty easy too.

The iRules

I'll repeat, there are near infinite options here. At the very least you need to VIP target from the external layered VIP to at least one of the SSL Orchestrator topology VIPs. The iRules provided here have been cultivated to make traffic selection and steering as easy as possible by pushing all of the pattern functions to a library iRule (SSLOLIB). The idea is that you will call a library function for a specific traffic pattern and if true, call a separate library function to steer that flow to the desired topology. All of the build instructions are contained inside the SSLOLIB iRule, with examples.

SSLOLIB iRule: https://github.com/f5devcentral/sslo-script-tools/blob/main/internal-layered-architecture/transparent-proxy/SSLOLIB

Switching iRule: https://github.com/f5devcentral/sslo-script-tools/blob/main/internal-layered-architecture/transparent-proxy/sslo-layering-rule

The function to steer to a topology (SSLOLIB::target) has three parameters:

  • <topology name>: this is the name of the desired topology. Use the basic topology name as defined in the SSL Orchestrator configuration (ex. "intercept").
  • ${sni}: this is static and should be left alone. It's used to convey the SNI information for logging.
  • <message>: this is a message to send to the logs. In the examples, the message indicates the pattern matched (ex. "SRCIP").

Note, include an optional 'return' statement at the end to cancel any further matching. Without the 'return', the iRule will continue to process matches and settle on the value from the last evaluation.

Example (sending to a topology named "bypass"):

call SSLOLIB::target "bypass" ${sni} "DSTIP" ; return

There are separate traffic matching functions for each pattern:

  • SRCIP IP:<ip/subnet>
  • SRCIP DG:<data group name> (address-type data group)
  • SRCPORT PORT:<port/port-range>
  • SRCPORT DG:<data group name> (integer-type data group)
  • DSTIP IP:<ip/subnet>
  • DSTIP DG:<data group name> (address-type data group)
  • DSTPORT PORT:<port/port-range>
  • DSTPORT DG:<data group name> (integer-type data group)
  • SNI URL:<static url>
  • SNI URLGLOB:<glob match url> (ends_with match)
  • SNI CAT:<category name or list of categories>
  • SNI DG:<data group name> (string-type data group)
  • SNI DGGLOB:<data group name> (ends_with match)

Examples:

# SOURCE IP
if { [call SSLOLIB::SRCIP IP:10.1.0.0/16] } { call SSLOLIB::target "bypass" ${sni} "SRCIP" ; return }
if { [call SSLOLIB::SRCIP DG:my-srcip-dg] } { call SSLOLIB::target "bypass" ${sni} "SRCIP" ; return }

# SOURCE PORT
if { [call SSLOLIB::SRCPORT PORT:5000] } { call SSLOLIB::target "bypass" ${sni} "SRCPORT" ; return }
if { [call SSLOLIB::SRCPORT PORT:1000-60000] } { call SSLOLIB::target "bypass" ${sni} "SRCPORT" ; return }

# DESTINATION IP   
if { [call SSLOLIB::DSTIP IP:93.184.216.34] } { call SSLOLIB::target "bypass" ${sni} "DSTIP" ; return }
if { [call SSLOLIB::DSTIP DG:my-destip-dg] } { call SSLOLIB::target "bypass" ${sni} "DSTIP" ; return }

# DESTINATION PORT   
if { [call SSLOLIB::DSTPORT PORT:443] } { call SSLOLIB::target "bypass" ${sni} "DSTPORT" ; return }
if { [call SSLOLIB::DSTPORT PORT:443-9999] } { call SSLOLIB::target "bypass" ${sni} "DSTPORT" ; return }

# SNI URL match   
if { [call SSLOLIB::SNI URL:www.example.com] } { call SSLOLIB::target "bypass" ${sni} "SNIURLGLOB" ; return }
if { [call SSLOLIB::SNI URLGLOB:.example.com] } { call SSLOLIB::target "bypass" ${sni} "SNIURLGLOB" ; return }

# SNI CATEGORY match   
if { [call SSLOLIB::SNI CAT:$static::URLCAT_list] } { call SSLOLIB::target "bypass" ${sni} "SNICAT" ; return }
if { [call SSLOLIB::SNI CAT:/Common/Government] } { call SSLOLIB::target "bypass" ${sni} "SNICAT" ; return }

# SNI URL DATAGROUP match   
if { [call SSLOLIB::SNI DG:my-sni-dg] } { call SSLOLIB::target "bypass" ${sni} "SNIDGGLOB" ; return }
if { [call SSLOLIB::SNI DGGLOB:my-sniglob-dg] } { call SSLOLIB::target "bypass" ${sni} "SNIDGGLOB" ; return }

To combine these, you can use simple AND|OR logic. Example:

if { ( [call SSLOLIB::DSTIP DG:my-destip-dg] ) and ( [call SSLOLIB::SRCIP DG:my-srcip-dg] ) }

Finally, adjust the static configuration variables in the traffic switching iRule RULE_INIT event:

## User-defined: Default topology if no rules match (the topology name as defined in SSLO)
set static::default_topology "intercept"

## User-defined: DEBUG logging flag (1=on, 0=off)
set static::SSLODEBUG 0

## User-defined: URL category list (create as many lists as required)
set static::URLCAT_list {
  /Common/Financial_Data_and_Services
  /Common/Health_and_Medicine
}

CPM policies

LTM policies (CPM) can work here too, but with the caveat that LTM policies do not support URL category lookups. You'll probably want to either keep the Pinners rule in your intercept topologies, or convert the Pinners URL category to a data group. A "url-to-dg-convert.sh" Bash script can do that for you.

url-to-dg-convert.sh: https://github.com/f5devcentral/sslo-script-tools/blob/main/misc-tools/url-to-dg-convert.sh

As with iRules, infinite options exist. But again for simplicity here is a good CPM configuration. For this you'll still need a "helper" iRule, but this requires minimal one-time updates.

when RULE_INIT {
  ## Default SSLO topology if no rules match. Enter the name of the topology here
  set static::SSLO_DEFAULT "intercept"

  ## Debug flag
  set static::SSLODEBUG 0
}
when CLIENT_ACCEPTED {
  ## Set default topology (if no rules match)
  virtual "/Common/sslo_${static::SSLO_DEFAULT}.app/sslo_${static::SSLO_DEFAULT}-in-t-4"
}
when CLIENTSSL_CLIENTHELLO {
  if { ( [POLICY::names matched] ne "" ) and ( [info exists ACTION] ) and ( ${ACTION} ne "" ) } {
    if { $static::SSLODEBUG } { log -noname local0. "SSLO Switch Log :: [IP::client_addr]:[TCP::client_port] -> [IP::local_addr]:[TCP::local_port] :: [POLICY::rules matched [POLICY::names matched]] :: Sending to $ACTION" }
    virtual "/Common/sslo_${ACTION}.app/sslo_${ACTION}-in-t-4"
  }
}

The only thing you need to do here is update the static::SSLO_DEFAULT variable to indicate the name of the default topology, for any traffic that does not match a traffic rule. For the comparable set of CPM rules, navigate to Local Traffic -> Policies in the BIG-IP UI and create a new CPM policy. Set the strategy as "Execute First matching rule", and give each rule a useful name as the iRule can send this name in the logs.

  • For source IP matches, use the "TCP address" condition at ssl client hello time.
  • For source port matches, use the "TCP port" condition at ssl client hello time.
  • For destination IP matches the "TCP address" condition at ssl client hello time. Click on the Options icon and select "Local" and "External".
  • For destination port matches the "TCP port" condition at ssl client hello time. Click on the Options icon and select "Local" and "External".
  • For SNI matches, use the "SSL Extension server name" condition at ssl client hello time.

For each of the conditions, add a simple "Set variable" action as ssl client hello time. Name the variable "ACTION" and give it the name of the desired topology.

Apply the helper iRule and CPM policy to the external traffic steering virtual server. The "first" matching rule strategy is applied here, and all rules trigger on ssl client hello, so you can drag them around and re-order as necessary. 

Note again that all of the above only evaluates TLS traffic. Any non-TLS traffic will flow through the "default" topology that you identify in the iRule. It is possible to re-configure the above to evaluate HTTP traffic, but honestly the only significant use case here might be to allow or drop traffic at the policy.

Layered architecture for an explicit forward proxy

You can use the same logic to support an explicit proxy configuration. The only difference will be that the frontend layered virtual server will perform the explicit proxy functions. The backend SSL Orchestrator topologies will continue to be in layer 3 outbound (transparent proxy) mode. Normally SSL Orchestrator would build this for you, but it's pretty easy and I'll show you how. You could technically configure all of the SSL Orchestrator topologies as explicit proxies, and configure the client facing virtual server as a layer 3 pass-through, but that adds unnecessary complexity. If you also need to add explicit proxy authentication, that is done in the one frontend explicit proxy configuration. Use the settings below to create an explicit proxy LTM configuration. If not mentioned, settings can be left as defaults.

  • Under SSL Orchestrator -> Configuration in the UI, click on the gear icon in the top right corner. This will expose the DNS resolver configuration. The easiest option here is to select "Local Forwarding Nameserver" and then enter the IP address of the local DNS service. Click "Save & Next" and then "Deploy" when you're done.
  • Under Network -> Tunnels in the UI, click Create. This will create a TCP tunnel for the explicit proxy traffic.
    • Profile: select tcp-forward
  • Under Local Traffic -> Profiles -> Services -> HTTP in the UI, click Create. This will create the HTTP explicit proxy profile.
    • Proxy Mode: Explicit
    • Explicit Proxy: DNS Resolver: select the ssloGS-net-resolver
    • Explicit Proxy: Tunnel Name: select the TCP tunnel created earlier
  • Under Local Traffic -> Virtual Servers, click Create. This will create the client-facing explicit proxy virtual server.
    • Type: Standard
    • Source: 0.0.0.0/0
    • Destination: enter an IP the client can use to access the explicit proxy interface
    • Service Port: enter the explicit proxy listener port (ex. 3128, 8080)
    • HTTP Profile: HTTP explicit profile created earlier
    • VLANs and Tunnel Traffic: set to "Enable on..." and select the client-facing VLAN
    • Address Translation: enabled
    • Port Translation: enabled
  • Under Local Traffic -> Virtual Servers, click Create again. This will create the TCP tunnel virtual server.
    • Type: Standard
    • Source: 0.0.0.0/0
    • Destination: 0.0.0.0/0
    • Service Port: *
    • VLANs and Tunnel Traffic: set to "Enable on..." and select the TCP tunnel created earlier
    • Address Translation: disabled
    • Port Translation: disabled
    • iRule: select the SSLO switching iRule
    • Default Persistence Profile: select ssl

Note, make sure that Address and Port Translation are disabled before clicking Finished.

  • Under Local Traffic -> iRules, click Create. This will create a small iRule for the explicit proxy VIP to forward non-HTTPS traffic through the TCP tunnel. Change "<name-of-TCP-tunnel-VIP>" to reflect the name of the TCP tunnel virtual server created in the previous step.
when HTTP_REQUEST {
  virtual "/Common/<name-of-TCP-tunnel-VIP>" [HTTP::proxy addr] [HTTP::proxy port]
}
  • Add this new iRule to the explicit proxy virtual server. To test, point your explicit proxy client at the IP and port defined IP:port and give it a go. HTTP and HTTPS explicit proxy traffic arriving at the explicit proxy VIP will flow into the TCP tunnel VIP, where the SSLO switching rule will process traffic patterns and send to the appropriate backend SSL Orchestrator topology-as-function.

Testing and Considerations

Assuming you have the default topology defined in the switching iRule's RULE_INIT, and no traffic matching rules defined, all traffic from the client should pass effortlessly through that topology. If it does not, 

  • Ensure the named defined in the static::default_topology variable is the actual name of the topology, without the prepended "sslo_". 
  • Enable debug logging in the iRule and observe the LTM log (/var/log/ltm) for any anomalies.
  • Worst case, remove the client facing VLAN from the frontend switching virtual server and attach it to one of your topologies, effectively bypassing the layered architecture. If traffic does not pass in this configuration, then it cannot in the layered architecture. You need to troubleshoot the SSL Orchestrator topology itself. Once you have that working, put the dummy VLAN back on the topology and add the client facing VLAN to the switching virtual server.

Considerations

The above provides a unique way to solve for complex architectures. There are however a few minor considerations:

  • This is defined outside of SSL Orchestrator, so would not be included in the internal HA sync process. However, this architecture places very little administrative burden on the topologies directly. It is recommended that you create and sync all of the topologies first, then create the layered virtual server and iRules, and then manually sync the boxes. If you make any changes to the switching iRule (or CPM policy), that should not affect the topologies. You can initiate a manual BIG-IP HA sync to copy the changes to the peer.
  • If upgrading to a new version of SSL Orchestrator (only), no additional changes are required. If upgrading to a new BIG-IP version, it is recommended to break HA (SSL Orchestrator 8.0 and below) before performing the upgrade. The external switching virtual server and iRules should migrate natively.

Summary

And there you have it. In just a few steps you've been able to reduce complexity and add capabilities, and along the way you have hopefully recognized the immense flexibility at your command.

Updated Nov 30, 2022
Version 2.0
configuration
LTM
security
series-ssl-orchestrator-advanced-use-cases
ssl
SSL Orchestrator
sslo
tls

Was this article helpful?