Implementing SSL Orchestrator - L2 Mode Deployment

Introduction

This article shows you how to deploy SSL Orchestrator in Layer 2 (L2) mode

This article is divided into the following high level sections:

Network Topology
Requirements
Best Practices
Known Limitations

Please forgive me for using SSL and TLS interchangeably in this article.

Software versions used in this article:

BIG-IP Version: 14.1.2

SSL Orchestrator Version: 5.5

BIG-IQ Version: 7.0.1

Network Topology

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

Before SSL Orchestrator

After SSL Orchestrator

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

Example Port Object/Channel and MLAG configuration from North Switch1:

interface Port-Channel511
   switchport trunk allowed vlan 511
   switchport mode trunk
   mlag 511

interface Port-Channel512
   switchport trunk allowed vlan 511
   switchport mode trunk
   mlag 512

mlag configuration
   domain-id mlag1
   heartbeat-interval 2500
   local-interface Vlan4094
   peer-address 172.16.0.2
   peer-link Port-Channel10
   reload-delay 150

Requirements

BIG-IP Version: 14.1.2

SSL Orchestrator Version: 5.5

BIG-IQ Version: 7.0.1

NGWF Version: Details are beyond the scope of this discussion – note that NGWF is configured with vWire and performs its inspection as a transparent L2 device.

Adv. WAF: Details are beyond the scope of this discussion – for this implementation, the Advanced WAF module is running on a separate BIG-IP platform.

Configuration of BIG-IP deployed as SSL Orchestrator can be downloaded from here in GitLab.

Demo videos are available for both Inbound and Outbound use cases:

Outbound Traffic Inspection

Inbound Traffic Inspection

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.

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.

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). For more information related to BIG-IP high availability (HA) configuration, refer to the user guide.

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.

Summary

This 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.