Get Started with Inline SSL Decryption
This section describes the prerequisites needed before you begin configuring inline SSL decryption.
Supported Platforms
Inline SSL decryption is supported on GigaVUE‑HC1, GigaVUE‑HC2, and GigaVUE‑HC3 nodes.
GigaSMART Licensing
The required GigaSMART license is SSL Decryption for Inline and Out-of-Band Tools.
Note: A GigaSMART license for Inline SSL is required to upgrade a passive SSL to inline SSL.
GigaSMART Compatibility
Inline SSL decryption is not compatible with any other GigaSMART operations, including Passive SSL decryption. Configure inline SSL decryption on a GigaSMART engine that is not shared with any other GigaSMART operation. Inbound and Outbound Inline-SSL decryption can be deployed on a single GigaSMART engine. Moreover, for GigaVUE‑HC2 nodes, it is recommended that you create separate GigaSMART operations for front and rear GigaSMART engines.
However, in GigaVUE‑HC1 nodes, you can configure inline SSL along with other GigaSMART applications. Refer to You can configure GigaSMART engine resources on GigaVUE‑HC1 to reduce the Inline SSL resource utilization by 50% and use the rest of the resource to configure the other GigaSMART applications. The Inline SSL application runs in the following two modes: for more information.
Install the GigaSMART and inline bypass module or copper TAP on the same GigaVUE‑HC1 or GigaVUE‑HC2 node or install the GigaSMART and inline bypass module on the same GigaVUE‑HC3 node.
Install software version 5.2.xx or higher for the GigaVUE-OS CLI, GigaVUE‑OS and GigaVUE‑FM.
The U-Boot version on GigaVUE‑HC2 nodes must be upgraded to version 2011.06.9 or higher. The upgrade can only be done from the CLI.
To check the U-Boot version, use the following command:
(config) # show version
For example on a GigaVUE‑HC2 node, the following output is displayed:
U-Boot version: 2011.06.10
If you do not have version 2011.06.10 or higher, you will have to do a U-Boot upgrade, after the image installation. Refer to the GigaVUE-OS Upgrade Guide for details on installing an image.
After the image installation of the software, use the following command to upgrade the U-Boot version:
(config) # uboot install
The binary bootloader code included with the installed image is installed.
Note: The newer U-Boot version only goes into effect after a reload.
For an outbound deployment, the Man-in-the-Middle (MitM) certificates must be installed in the client trust store. Install the certificates as a Trusted Root Authority in web browsers on the client PC.
Refer to your browser’s documentation for installing CA certificates to the trust store.
A stack port is a port that is used to communicate with other nodes in the stack to expand your network capacity. GigaVUE HC Series devices provide dedicated, configurable ports for stacking.
Internet connectivity is required for CRL, OCSP, and URL categorization. The stack port interface must be configured on the GigaSMART engine. You can configure one stack port for all the GigaSMART engines in a GigaVUE node. However, you must configure all the engines with unique DHCP or static IP address.
Refer to 1 for the location of the stack port on the front of the GigaVUE‑HC2. It is the second port from the top on the left side of the chassis.
1 | Stack Port Location on GigaVUE‑HC2 Front |
Refer to 2 for the location of the two stack ports, eth2 (default) and eth3 on the control card in the front of GigaVUE‑HC3. You can use either one or both the stack ports for GigaSMART connectivity.
2 | Stack Port Location on GigaVUE‑HC3 Front |
Refer to 3 for the location of the stack port on the front of the GigaVUE‑HC1. It is the top port on the right.
3 | Stack Port Location on GigaVUE‑HC1 Front |
To configure the stack port interface:
1. | Go to Ports > All Ports. Select a GigaSMART engine port and click Edit. |
3. | Click OK. The stack port interface is added. |
Note: Proxy IP addresses cannot be used to configure for internet connectivity in the stack port. The Port ID used to connect to web root URL is 80.
You can configure GigaSMART engine resources on GigaVUE‑HC1 to reduce the Inline SSL resource utilization by 50% and use the rest of the resource to configure the other GigaSMART applications. The Inline SSL application runs in the following two modes:
Standalone mode Enabled—The Inline SSL feature takes the entire GigaSMART engine resource. By default standalone mode is enabled for Inline SSL. |
Standalone mode Disabled—The GigaSMART engine resource allocated for Inline SSL feature is reduced to 50% and the residual GigaSMART engine resource can be configured for other GigaSMART applications. |
On GigaVUE‑HC1, you can configure the following GigaSMART applications along with the Inline SSL feature:
De-duplication (SMT-HC1-DD1) |
NetFlow Generation (SMT-HC1-NF1) |
BSE Combo (SMT-HC1-BSE) - Masking, Slicing, and Trailer |
Header-stripping (SMT-HC1-HS1) |
Flow Sampling (SMT-HC1-FVU) |
Tunneling, ERSPAN (SMT-HC1-TUN) |
- It is not recommended to configure Inline SSL feature with other GigaSMART applications, except the applications listed above.
- The Passive SSL decryption is not recommended to be configured with Inline SSL feature and combination of NetFlow and SSL decryption do not work with the Inline SSL.
- For inline SSL decryption, Internet connectivity to GigaSMART and clustering is not supported on the same interface, for example, eth2.
To enable Standalone mode for Inline SSL decryption on GigaVUE‑HC1:
1. | From the GigaVUE‑HC1 device view, select GigaSMART > GigaSMART Groups > GigaSMART Groups. |
2. | Click New to create a new GigaSMART group or click Edit to modify an existing GigaSMART group. |
3. | Go to Inline SSL under GigaSMART Parameters, and select Standalone. |
4. | Click OK. |
For Inbound and Outbound Inline-SSL deployments, the keychain password must be configured before installing the certificates and private keys into the keystore.
Refer to Configure Inline SSL Decryption Using GigaVUE‑FM for the configuration steps.
For an outbound deployment, at least one of the CAs must be configured (primary or secondary). For an inbound deployment, a CA is not necessary.
The primary CA re-signs certificates for servers that present a valid certificate. The secondary CA re-signs certificates for servers that are invalid or that fail validation. If the secondary CA is not configured, the primary CA will be used for all certificates.
Refer to Configure Inline SSL Decryption Using GigaVUE‑FM for the configuration steps.
You can configure an inline SSL session logging server to store the logged events that are generated when there are any changes made to the devices. You can specify the type of events that must be logged in to the server.
The following table provides a mapping of the severity, log level and its description:
Severity |
Log Level |
Description |
0 |
Emergency |
System is unusable |
1 |
Alert |
Action must be taken immediately |
2 |
Critical |
Critical condition |
3 |
Error |
Error condition |
4 |
Warning |
Warning condition |
5 |
Notice |
Normal but significant condition |
6 |
Informational |
Informational message |
7 |
Debug |
Debug message |
The logged events are stored in the Common Event Format (CEF) as follows:
<SYSLOG_HEADER> <Timestamp> <hostname:engine> CEF:0|Gigamon|<Device Model>|<GigaVUE OS Version>|<Event ID>|<Event name>|<Severity>|[Extension]
Here is an example of a logged event:
Thu Jun 14 15:50:16 2018 hostname:hc2_test:1/1/e1
CEF:0|Gigamon|HC2|5.5.0|102|SESSION_DECRYPT|6|src=126.1.0.20
dst=126.1.0.10 spt=34267 dpt=443 dhost=example.com
cs1Label=Certificate Subject cs1=C\=US, ST\=CA, L\=Santa Clara,
CN=*.example.com cs2Label=Cipher Suite cs2=DHE-RSA-AES128-GCM-SHA256
You can view and track these logs to troubleshoot system issues, maintain audit trails, and for compliance purpose.
To configure an inline SSL session logging server using GigaVUE‑FM:
Task | Description | UI Steps |
---|---|---|
1. | Configure a tool port. |
|
2. | Configure an IP interface with an IP address, subnet mask, default gateway, and MTU setting. Assign it to the GigaSMART group. |
|
3. | Configure the inline SSL session logging server under the GigaSMART group to which you assigned the IP interface in the task 2. |
|