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 fromherein 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 theSSL Orchestrator Document. AutoMap AutoMap is a secure network address translation (SNAT) described in Knowledge articleK7336. AutoMap should not be used where possible in BIG-IP SSL Orchestrator deployments. Please refer toK7820for 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 theSSL 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 ArticleK00805840for 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 theuser 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. Next Steps Click Next to proceed to the next article in the series.
Service chains packet processing for L3 devices
Hello, I'm trying to understand SSL intercept and Service Chains, and have a few questions about it: According to a devCentral video, https://www.youtube.com/watch?v=mvse6zCt_jo , devices in a service chain are accessed in parallell, minimizing the delay in a long chain with many inspection devices. However, reading the SSL intercept deployment guide, it says " Each service chain is an ordered list of services of various types", that sounds like the devices are processed one at a time? Question 2: When you hook up a L3 device in your service chain, does the complete packet get sent to the device and back again to the BIGIP (if allowed though the L3 device)? Question 3: What about the return traffic, is it automatically send back to the sending interface of the L3 device? In my case the L3 device is a NGFW, I'm asking because I want to know if the traffic flow will be weird in any way from the NGFW point of view (statistics, logging and so on).
