Implementing SSL Orchestrator - High Level Considerations

Piotr,

I will try to answer your questions above.

1.- A couple of things: 

-the article should read "d. The Lan configuration for the connection to the BIG-IP ASM is as depicted below"

-the article should also read "e. The NGFW is connected to the INSPECTION switching network [...]"

-the letters above refer to the figure showing the different reference points.

We'll work on correcting the formatting and typo in the article.

2.-Dynamic Routing was not considered for this article series - are you talking about routing on ingress/egress, for services in the chain? i do not know what the implications are on ingress/egress and we would need to try that and possibly create another article on how to set that up successfuly.

3.-There is confusion there. As you caught, there is no alternate path drawn in the figure to allow for policy-based routing. The insertion of services in existing networks is tricky. The article suggests that you can have an alternate path between the North and South switches (not shown in the diagram) and that the administrator can manipulate routing to selectively send traffic to the BIG-IP SSL Orchestrator. Please consider the following diagram for more information:

4.-Please refer to K7820 for 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). There are also some caveats to using SNAT Automap along with floating IP addresses.

5.-BIG-IP is configured in L3 mode in this case and is a hop in the network. So the BIG-IP is not transparent from a network perspective and not configured with vWire. The NGFW is configured to act as transparent L2 device in the inspection/service chain. 

I hope this helps clarify some things in this article.

Romain