Implementing SSL Orchestrator: L2 Mode and L3 Mode Deployment

Introduction

F5 SSL Orchestrator (SSLO) is an all-in-one appliance solution that optimizes SSL infrastructure, gives security devices visibility into SSL/TLS encrypted traffic, and makes the most of existing security investments. This solution allows for policy-based traffic flow management and steering to existing security devices, and it's simple to integrate into existing architectures. It also centralizes the SSL decrypt/encrypt function by delivering the latest SSL encryption technologies across the entire security infrastructure.

Different environments call for different network implementations. While some can easily support SSL visibility at layer 3 (routed), others may require these devices to be inserted at layer 2. SSL Orchestrator can support all of these networking requirements with the following topology options:

Implementing SSL Orchestrator in Layer 2 and Layer 3 mode

Deploying SSL Orchestrator in Layer 2 (L2) mode and Layer 3 (L3) mode is divided into the following high level sections:

Network Topology
Requirements
Best Practices
Known Limitations

Software versions used are:

BIG-IP Version: 14.1.2

SSL Orchestrator Version: 5.5

BIG-IQ Version: 7.0.1

Network topology for L2 mode

The diagram below is a representation of the actual network where SSL Orchestrator was deployed and tested.

Before SSL Orchestrator

After SSL Orchestrator

Network topology for L3 mode

The diagram below is a representation of the actual network where SSL Orchestrator was deployed and tested.

Before SSL Orchestrator

After SSL Orchestrator

Note: All routing configuration is static routing – no dynamic routing protocols is implemented in this design. Dynamic Routing was not considered for this article series.

The design allows for the administrator to gradually forward services to the BIG-IP SSL Orchestrator using source-based routing rules. The end-result is to have all outbound and inbound traffic traversing the BIG-IP SSL Orchestrator solution.

Requirements

BIG-IP Version: 14.1.2

SSL Orchestrator Version: 5.5

BIG-IQ Version: 7.0.1

NGWF Version: Note that NGWF is configured with vWire and performs its inspection as a transparent L2 device. Articles regarding configuration of the Device is provided in the references.

Adv. WAF: For this implementation, the Advanced WAF module is running on a separate BIG-IP platform. Refer the articles in the bottom for the steps to configure the device.

Best practices for SSL Orchestrator deployment

BIG-IP recommendations

The following provides salient recommendations, these and others are discussed in detail in the SSL Orchestrator Document provided in the references.

AutoMap

AutoMap is a secure network address translation (SNAT) described in Knowledge article K7336. AutoMap should not be used where possible in BIG-IP SSL Orchestrator deployments.

Please refer to K7820 for SNAT uses and best practices. With BIG-IP configurations (SSLO or other modules), whenever a large number of connections are going to require SNAT, you want to make sure that SNAT pools are used to avoid port collisions (running out of ephemeral ports to initiate the connection).

Debug logging

Traffic through BIG-IP SSL Orchestrator will transit through different services as defined in the service chain. Enabling debug will generate logs as traffic traverses the different services – this can be very verbose and generate large amounts of traffic.

It is recommended to leverage debug logging for troubleshooting only.

Security recommendations

The following recommendations can also be found in the SSL Orchestrator Document referenced below.

SSL Orchestrator and Service Proximity

SSL Orchestrator is almost never first in an enterprise architecture, so other security devices (proxies, firewalls, IPSs, sandboxes, etc.) are already deployed. If you ask any network and/or security admin, 99% of the time they have no interest in moving those security devices or re-architecting anything else when SSL Orchestrator is introduced.

However, remember that the traffic being sent to and from the security devices is unencrypted, so sending traffic across an existing enterprise network to some security device is also sending passwords, credit card numbers, and other protected data (HIPAA, PCI, etc.), across an uncontrolled span of network where any connected device can see it in clear text.

It is therefore brutally important that customers understand this, and that they do move those security devices to networks that are behind and protected by SSL Orchestrator. In a perfect situation, no traffic should be able to reach these security devices except through SSL Orchestrator. As frightening as the possibility of a data exposure is, there are going to be customers that ignore the warnings. You should therefore do your best to convey this security best practice to customers as their trusted advisor.

This is the reason for the "Auto-Manage" field in the configuration for the services. It creates non- overlapping, internal, non-routable address spaces for each service and encourages customers to protect them.

If disabling this, and changing the inline service IP spaces, take care to protect these.

Known limitations

It is recommended to consult with the Knowledge Article K00805840 for current known issues and workarounds.

Strictness

Underlying the BIG-IP SSL Orchestrator is the BIG-IP TMOS infrastructure. The BIG-IP SSL Orchestrator provides a guided configuration front-end to configure TMOS to build the services, and different policies to make the solution work as designed.

If the administrator were to dive deeper in the low-level configuration of the device after building a topology, the configuration would contain BIG-IP configuration items – refer to Appendix C for sample configuration for a simple SSL Orchestrator configuration.

The notion of strictness is introduced to "lock" the configured items in such a manner as to prevent the administrator to be able to modify the underlying object without using the SSL Orchestrator interface.

Any attempt to modify an object that is strictly managed will result in an error message as shown below:

Gossip

For BIG-IP SSL Orchestrator deployed in redundant pairs, BIG-IP should be in manual/full sync mode (Device Management>>Device Group).

The traditional synchronization mechanism is augmented with "gossip" for the SSL Orchestrator. This synchronization mechanism is independent from typical LTM config sync. For the version of BIG-IP SSL Orchestrator used for this deployment, "gossip" config sync is two-way automatic. "gossip" uses REST API calls for the SSL Orchestrator related part of the config sync. If a change is made to one device in the pair, it is automatically propagated to the other device. This differs from the traditional BIG-IP sync behavior.

SSL Orchestrator config needs to be re-deployed if a STANDALONE environment is changed to an HA environment. Also, you need to make sure VLAN configuration is the same on both the box for successful re-deployment.

Conclusion

The article should be a good starting point for planning your initial SSL Orchestrator deployment. The network topology and architecture was explained with the help of diagrams. We also went over the software requirements, best practices and known limitations.