cancel
Showing results for 
Search instead for 
Did you mean: 
KevinGallaugher
F5 Employee
F5 Employee

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.

 

0EM1T000001NQ0t.png

 


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.

 

0EM1T000001NQ0u.png

 


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.

 

0EM1T000001NQ0v.png

 


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.

 

0EM1T000001NQ0w.png

 


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.

 

0EM1T000001NQ1i.png

 


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.

 

Comments
burbigo1
Nimbostratus
Nimbostratus

Really great explanation, thank you so much.

 

SHAREit MX Player

Hi,

Just to be sure for Layer 2, Inbound Transparent Proxy diagram. Is that just simplification in diagram or I don't get something here 😞 SSL is between Egress and Internal routers. From the schema:

  1. Egress router IP: 10.3.0.254
  2. Internal route IP: 10.2.0.254

Assuming that subnets this IP are from are not using /8 mask then both IPs are from different subnets - if so I don't get how traffic can flow between routers?

Or maybe IP specified for Egress router is on external side (User facing) but on internal side (facing SSLO or rather Internal Router) it is using IP from 10.2.0.0/24 subnet?

As far as I understand vWire and VLAN group those can only connect VLANs with the same subnet, so host in VLAN on one side of SSLO has to use the same subnet as host on other side of the SSLO - or in other words it handles just single L2 broadcast domain - Am I wrong?

Piotr

Romain
F5 Employee
F5 Employee

Piotr,

The picture used for this article to illustrate the L2 topologies are confusing. As you mention, it is a simplification. For the L2 topologies, the MAC information is what is really significant.

For IP forwarding to take place between networks, you would need the routers to be in the same network on either side of the SSLO device.

Thank you for catching that. Hopefully this comment will bring some clarity. We'll work to modify these two diagrams in the article to make them clearer.

Romain

Hi,

Sorry for nitpicking, just tried to figure out if I am missing some important piece. Thanks a lot for clarification!

Piotr

Version history
Last update:
‎22-Jan-2020 11:30
Updated by:
Contributors