Implementing SSL Orchestrator - Network Insertion Use Cases
General Topology Considerations SSL Orchestrator is deployed as an inline device on the network and supports both single devices and HA clusters using device groups. Deployment topology can be described by a combination of: SSL Orchestrator's deployment mode (layer 2 or layer 3) Direction of traffic flow (inbound or outbound) SSL Orchestrator's proxy type (transparent, explicit, or both) Any given SSL Orchestrator can only be deployed in either a layer 2 mode, or a layer 3 mode, but it can use multiple combinations of traffic flow and proxy type. Deployment Mode: The deployment mode is used to configure how the SSL Orchestrator interacts with the network around it. This can be set to either Layer 2 Network (if the hardware supports it) or Layer 3 Network. Layer 2 Network: This operates as a transparent switch in the network and must be installed between two VLANS in such a way that the traffic must flow through the system. This approach, called a "virtual wire" topology mode (SSL Orchestrator as a bump-in-the-wire) is only available on (i5800, i7800, i10800, i11800, i15800). This mode is enabled with special characteristics of the Broadcom network chipsets which enable full L2 header passing from ingress to egress. There is still a full proxy environment inside the inspection zone, allowing L3, ICAP and proxy devices to function, so this new mode isn't technically a "true" bump-in-the-wire, but does not require any L3 addressing on the edges. This involves using virtual wire and VLAN Group deployments. Layer 3 Network: This deployment mode operates as a router in the network. If using with transparent mode, downstream routers consider the SSL Orchestrator as a default gateway to the internet, and upstream routers routing through it to get to the internal resources. If operating as an explicit proxy, upstream and downstream routers must simply have a route to get to the SSL Orchestrator system. NOTE: In most cases this is the best option to choose as it provides the most flexibility. Topologies available for configuration. Deployment Topology Details: In addition to the deployment mode, a system can be configured to handle inbound and outbound traffic, and in the case of one configured for Layer 3 mode, it can handle both explicit and transparent proxies. L2 mode can only support transparent proxy deployment. Transparency is determined by the amount of configuration or awareness the client has of the proxy.The deployment is considered transparent if the client requires no additional configuration. For transparent configurations, the network is configured in such a manner as all client/end-user traffic transits through the BIG-IP for SSL/TLS processing. Layer 3, Outbound Transparent Proxy: This topology provides a transparent outbound, or forward proxy solution to monitor traffic from internal users and systems going to external systems. With this topology, clients do not need to be configured with the SSL Orchestrator as a proxy for their systems.The figure below gives an overview of the typical traffic flow. Layer 3, Outbound Explicit Proxy: This topology provides an explicit outbound, or forward proxy solution to monitor traffic from internal users and systems going to external systems. In this topology each client application must be explicitly configured to send traffic to SSL Orchestrator. This option is only available for HTTP traffic using a HTTP CONNECT header option. When SSL Orchestrator is configured as an explicit proxy, and receives the HTTP CONNECT request, it strips off the CONNECT header before forwarding the traffic to the service devices. The figure below gives an overview of the typical traffic flow. Layer 3, Inbound Reverse Proxy: This topology provides a transparent inbound, or reverse proxy solution to monitor traffic from external users and systems going to internal systems. The figure below gives an overview of the typical traffic flow. Layer 2, Outbound Transparent Proxy: This topology provides a transparent outbound, or forward proxy solution to monitor traffic from internal users and systems going to external systems without having to modify the customers routing environment. The figure below gives an overview of the typical traffic flow. Layer 2, Inbound Transparent Proxy: This topology provides a transparent inbound, or reverse proxy solution to monitor traffic from external users and systems going to internal systems without having to modify the customers routing environment. The figure below gives an overview of the typical traffic flow. Existing Application: For existing applications, the topology is built on existing BIG-IP configuration from non-SSL Orchestrator products such as BIG-IP LTM.This brings configuration items under a common umbrella to support infrastructure that was implemented prior to SSL Orchestrator implementation.
