SSL Orchestrator Lab Environment (Ravello)

To access your lab and lookup the necessary IP addresses, you should have received an email with your personal "Lab Portal Link". Once attached you should have something similar to the following image. Highlighted is the "Lab Guide" and the VM's you'll spend all of your time attached to.



The lab environment for this guide has provided some prerequisite settings that you should be aware of. These are provided to make the demo simpler. All of the following would need to be configured manually in another environment.


Most of this lab can be accomplished by directly attaching to the BIG-IP GUI. Within your assigned Ravello lab lookup the IP, open new tab and goto https://<assigned_IP>

The following information is based on our custom Ravello blue print "SSL Orchestrator 5.4 Lab".

  • Client side VLAN and subnet are defined - this is the VLAN that an internal client connects to for outbound traffic flows. SSLO does not define the client-side VLAN(s) and self-IP(s). A web server also exists on the client side VLAN to facilitate an inbound (reverse proxy) use case - external client to an internal set of websites.
  • Outbound side VLAN and subnet are defined - this is the VLAN that traffic egresses from SSLO to the Internet gateway. SSLO does not define the server-side VLAN(s) and self-IP(s).
  • ICAP service VLAN and subnet are defined - SSLO does not define the networking for this service type, so it has been pre-created in this lab.
  • CA certificate and private key are installed - this is the CA certificate and private key that are used to re-issue (forge) remote server certificates to internal clients for outbound traffic flows.
  • Server certificate and private key are installed - for the inbound (reverse proxy) traffic flow use case, SSL traffic is terminated at the F5, and re-encrypted on the way to the internal application environment. A wildcard server certificate is installed to facilitate using any name under the "" sub-domain.


It is a security best practice to isolate security devices within the protected network enclave provided by SSLO. Customers will often desire NOT to move or change existing security services. However, while possible with SSLO 4.0 and beyond, passing this decrypted traffic to points on an existing network architecture could create multiple points of data exposure. Usernames, passwords, credit card numbers and other sensitive information could be exposed to other devices on that network. Each inline layer 3 security service definition includes an "Auto Manage" option. This option, enabled by default, provides internal network settings for security services to use, so that only the interface (and 802.1q VLAN tag as needed) is required to be defined for the inbound and outbound interfaces. Should customers opt to not follow security best practices, or simply need different networking settings, you can disable the Auto Manage option and define all of the required inbound and outbound networking setting manually.

SSL Orchestrator
BIG-IP Management IP  
Gateway IP/DNS  
Login admin:admin | root:default  
Interfaces Client VLAN 1.1
  Outbound VLAN 1.2
  Inline L3/HTTP services 1.3 (tagged)
  TAP service 1.4
  ICAP service 1.5
  Inline L2 service inbound 1.6
  Inline L2 service outbound 1.7
Inline layer 2 service
Login student:agility
Inline layer 3 service
Login student:agility    
Interfaces Inbound interface 1.3 tag 50
  Outbound interface 1.3 tag 60
Explicit proxy service
Login student:agility    
Interfaces Inbound interface 1.3 tag 110
  Outbound interface 1.3 tag 120
Service Squid Port 31281  
Receive-only service
Login student:agility
MAC Address 12:12:12:12:12:12 (arbitrary if isolated)
ICAP service
Login student:agility
IP Address:port
REQ/RES URLs /squidclamav
Internal web server
Login student:agility
IP Addresses (* (Apache2 instances listening on HTTPS port 443)
Outbound client
Login student:agility
IP address (RDP and SSH)
Inbound client
Login student:agility
IP address (RDP and SSH)