6.2. Packet Flow in an SSL Orchestrator Reverse Proxy

6.2.1. What it is

If you have a basic understanding of the outbound packet flow through SSL Orchestrator, as described above, the same knowledge can be applied to the inbound use case. Inbound topologies essentially differentiate from outbound in the way certificates are handled. For inbound topologies, it is expected that the BIG-IP possesses the server certificates and private keys.

That said, there are three inbound topology modes important to describe further. The layer 2 inbound mode ONLY differentiates from the outbound layer 2 mode in the way it handles certificates. For all of the inbound topology modes, packet flow through the service chain is the same as described above.

6.2.2. Inbound Gateway Mode

When you define an inbound layer 3 topology, you have two options depending on how traffic flows to or through the topology. In the Gateway mode, the topology becomes a routing point. The destination IP address in the client’s packet is an address behind the BIG-IP, thus the topology contains a wildcard listener (ex. 0.0.0.0/0) and forwards (routes) the traffic inbound to a separate destination, load balancer, or next hop route. No NAT is applied to the traffic, though SNAT can be applied as required. In the Gateway mode implementation, the corresponding LTM virtual server has a wildcard destination address (0.0.0.0/0), address and port translation disabled, and no pool assignment. Note that while the destination IP address is behind the BIG-IP in this mode, as in any routing configuration the destination MAC address is on the BIG-IP.

6.2.3. Inbound Application Mode

In Application Mode, the topology is a termination point. In this case, the destination address in the client’s packet is an IP address assigned to the topology listener. In the Application mode implementation, the corresponding LTM virtual server defines the target destination IP address and port, address and port translation are enabled, a pool is assigned, and NAT is performed to the load balanced pool members. Note here that the destination IP and destination MAC address are on the BIG-IP.

6.2.4. Existing Application Mode

The Existing Application mode enables you to attach the SSL Orchestrator security directly to an existing LTM reverse proxy virtual server. This is most useful in situations where a BIG-IP LTM is already deployed and handling application traffic. The SSL Orchestrator security policy can be attached to provide dynamic decrypted service chaining to a set of security devices. It is expected that the existing LTM virtual server already handles its own SSL decryption (client/server SSL profiles) and traffic management (pool). The Existing Application topology workflow simply contains configuration steps for defining security services, service chains, and a security policy. The resulting security policy manifests as an Access per-request policy.