F5 BIG-IP SSL Orchestrator Training Lab > All SSL Orchestrator Lab Guides > SSLO 102: Diving into SSL Orchestrator for BIG-IP Next (AppWorld 2024 | 2 hours) > 5. Lab 3 - Inbound Gateway Mode Deployment Source | Edit on

5.6. Testing the Inbound Gateway Deployment¶

You have now deployed an Inbound Gateway Mode SSL Orchestrator configuration with a traffic policy that steers decrypted traffic to a Service Chain containing an Inline L3 inspection service and an ICAP service. The next step is to test your application from a client environment and verify that decrypted traffic is visible to the inspection services.

You have effectively configured a routed (next hop) gateway at the BIG-IP that listens for all incoming addresses and forwards to the backend. An Internet client would resolve an application to an IP address behind the BIG-IP instance, potentially on another BIG-IP, or other application server. Assuming multiple applications exist behind the BIG-IP, TLS certificate handling can be done in two different ways:

Using a single wildcard domain certificate matching all of the destination hosts. The wildcard.f5labs.com certificate used in this lab is applying this option. The lab client is configured to resolve the following hostnames to internal IPs:
- gwapp1.f5labs.com
- gwapp2.f5labs.com
- gwapp3.f5labs.com
Using separate entity certificates in the client-side TLS configuration. In this scenario, each additional certificate added in the Enable HTTPS (Client-Side TLS) drawer under the Protocols & Profiles configuration will also need one or more Server Names added. In this dialog, click the Add Servers option, click the Start Adding button, and then enter one or more names. This name maps to the Server Name Indication (SNI) value from the TLS ClientHello request coming from the client. The matching SNI (server name) defines which certificate is then presented to the client in the TLS handshake. One and only one of the certificates added MUST be set to Use Default Server, while all of the others must add one or more server names. The certificate with Use Default Server selected is the certificate that will be used if no other certificate matches the incoming client SNI.

5.6.1. Test Access to the HTTPS Application¶

You will now test the HTTPS application by sending a command line cURL request to the BIG-IP Virtual Server.

In the Client VM shell (or a shell running in the Client VM desktop), enter the following commands to verify that the applications behind SSL Orchestrator are reachable:
```
curl -vk https://gwapp1.f5labs.com
curl -vk https://gwapp2.f5labs.com
curl -vk https://gwapp3.f5labs.com
```
Under the Ubuntu-Server resource of the UDF Deployment tab, click on Access -> Web Shell. This will open a console shell window to the Server VM (in a separate browser tab).

Note

The Ubuntu-Server VM instance leverages a set of Docker containers that are running various tools to emulate real world inspection services. In order to view the traffic flowing through these services, you will need to connect to the Docker containers.
Capture traffic on the ICAP interface: The ICAP service container does not have any capture tools installed, but you can still access the container's dedicated interface from the Ubuntu-Server instance.
```
sudo tcpdump -lnni ens6.50 -Xs0
```
The -Xs0 (capital 'x', lowercase 's', zero) flag allows you to view the unencrypted payload.

Note

An ICAP server will not receive encrypted traffic, so by design traffic to the gwapp3.f5labs.com URL per the above policy will not be seen in ICAP captures. To see this encrypted traffic, use the Inline Layer 3 inspection service.
The Inline Layer 3 inspection service runs inside a container named layer3. Execute the following commands to access the container shell and perform a tcpdump packet capture on the service's inbound interface (eth1):
```
docker exec -it layer3 /bin/bash
tcpdump -lnni eth1 -Xs0
```
The -Xs0 (capital 'x', lowercase 's', zero) flag allows you to view the unencrypted payload.
From the Client VM Web Shell, test the BIG-IP application using each of the three provided hostnames: gwapp1.f5labs.com, gwapp2.f5labs.com, and gwapp3.f5labs.com. The tcpdump packet capture should show clear text (decrypted) traffic to the first two hosts, and encrypted traffic to the third host.

Attention

This is the end of the lab module.

Previous Next