on 22-Jan-2020 11:30
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:
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.
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.
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:
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
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