Inline Tool Configurations
Inline tools connect to the GigaVUE node through inline bypass (BPS) modules, available on the GigaVUE‑HC1, and GigaVUE‑HC3.
The inline bypass arrangements supported by inline TLS/SSL decryption are as follows:
| single inline network. The inline network ports can be protected, unprotected, or a mix of protected and unprotected. |
| inline network group, consisting of multiple inline networks |
| single inline tool |
| inline tool group, consisting of multiple inline tools over which traffic is distributed |
| inline tool group with a spare inline tool, in which the failure of one tool in the inline tool group will trigger a failover to the spare |
| inline series, in which traffic is guided through inline tools in a particular order |
In summary, inline TLS/SSL decryption can be deployed in any combination of inline network and inline network group with any inline tool, inline tool group, or inline series.
Note: The TLS/SSL sessions will fail ,if a BPS card is shut down and brought back up with an Inline TLS/SSL configuration.
Inline tool ports can be configured in shared mode. When an inline tool is shared (true), the decrypted traffic will be VLAN tagged. The connected inline device is expected to receive VLAN tagged packets instead of untagged packets. There is an extra outer VLAN tag added to the packet, which the connected inline device needs to see. When an inline tool is not shared (false), the extra VLAN tag is not added. This allows untagged traffic to be sent to the tool ports. Use false for inline tools that are not able to handle more than one VLAN tag, such as Q-in-Q tagged packets. For tagless mode, if an inline tool is involved in an inline TLS/SSL map, the inline tool cannot be used in any other classic inline map.
Starting in software version 6.5, you can choose to deploy flexible iSSL solution with single VLAN tag in which the original tag received from the inline network will be removed and only the tool tag you create when configuring an inline map will be part of the packet. This will prevent the inclusion of additional VLAN tag in the decrypted packets that have been routed through inline tools. The inline tool that is shared with a single VLAN tag in a packet will be supported in the flexible inline TLS/SSL arrangements across multiple maps with different single VLAN tags. Shared mode (false) is not allowed when single VLAN tag is enabled in the iSSL solution.
Refer to 1 to3 for inline tool arrangements. Encrypted traffic is shown in solid lines, decrypted traffic is shown in dotted lines.
1 shows a simple inline tool arrangement with one inline tool connected to the GigaVUE node. Traffic is decrypted and sent to the inline tool.
| 1 | Simple Inline Tool Arrangement |
2 shows a multiple inline tool arrangement with three inline tools connected to the GigaVUE node. Decrypted traffic is distributed across the tools.
| 2 | Multiple Inline Tool Arrangement |
3 shows a serial inline tool arrangement in which traffic is decrypted on the GigaVUE node, sent serially through the inline tool, and then re-encrypted on the GigaVUE node.
| 3 | Serial Inline Tool Arrangement |
Inline Bypass Restriction
The inline bypass arrangements supported by inline TLS/SSL decryption have the following restriction:
| inline network group does not support ingress VLAN tagging on the member links |
Forwarding
Inline TLS/SSL decryption supports the following kinds of forwarding:
| inline forwarding—Packets can be forwarded from the inline network or inline network group to the inline tool, inline tool group, or inline series. The IPv6 traffic received from the inline network is forwarded as IPv6 traffic in tool-port. The translation from IPv6 packet in network-port to IPv4 packet in tool port will not be supported. |
| inline out-of-band forwarding—Packets from inline ports can be sent to regular tool ports. |
| inline bypassing—Packets can be put in loopback between two ports of an inline network. |
| TLS/SSL forwarding—Packets from an inline network or inline network group can be sent to GigaSMART, then from GigaSMART to an inline tool, inline tool group, or inline series. |
| GigaSMART out-of-band forwarding—Packets from GigaSMART can be copied to tool ports. |
Failover
The inline bypass module detects failure either through link loss or tool heartbeat failure.
The inline bypass module supports the following failover actions:
| inline tool failover action—Specifies the failover action taken in response to a failure of an inline tool. |
| inline tool group failover actions—Specifies the failover action taken in response to a failure of an inline tool group, when the number of healthy inline tools in the inline tool group (including the spare inline tool, if configured) falls below the configured minimum. |
| inline tool series failover actions—Specifies the failover action taken in response to a failure of an inline tool series as a whole. An inline tool series is declared to be in a failure condition as soon as any of its member inline tools goes into a failure condition. An inline tool series recovers from a failure condition after all the member inline tools recover from their failure conditions. The failover-action attributes of the individual inline tools participating in an inline tool series are ignored. Instead, the failover-action configured for the inline tool series is respected. |
The inline bypass failover actions are configurable. Refer to the GigaVUE-OS CLI Reference Guide for the actions and default values of the inline-tool, inline-tool-group, and inline-serial commands.
The virtual port also has configurable failover actions. Refer to the GigaVUE-OS CLI Reference Guide for the actions and default value of the vport command.
The GigaSMART module might also have events such as port down or card down. These failover actions are not configurable but are triggered by events. These events should not impact traffic.
Out-of-Band and Inline Tools
After decryption, traffic can be sent to multiple tools. The tools can be either inline or out-of-band.
Out-of-band tools process the decrypted packets offline. The tools are connected to the GigaVUE node through tool or hybrid ports, GigaStream, or port groups with tool or hybrid ports. The out-of-band tools receive a copy of the decrypted packets from the GigaSMART module. This is referred to as GigaSMART out-of-band forwarding.
Inline tools process the decrypted packets inline. Inline tools are connected to the GigaVUE node through inline bypass (BPS) modules.
An out-of-band tool might be an Intrusion Detection System (IDS) examining decrypted packets:
| If it detects a threat, the IDS will send a notification back, but does not have the ability to act. |
An inline tool might be an Intrusion Prevention System (IPS) examining decrypted packets:
| If it does not detect a threat in the decrypted packets, the traffic comes out of the inline tool and goes back to the GigaSMART module to be re-encrypted and sent to the server. |
| If it detects a threat, the IPS can act. The action depends on the tools’ behavior. It can either terminate the connection or modify packets |
| If the IPS terminates the connection, then GigaVUE node will terminate the connection between the client and the server. |
| If the IPS modifies packets, then the modified packets will come out of the inline tool, go to the GigaSMART module to be re-encrypted, and sent to the server. |
When an inline tool is shared, you must:
| configure the inline second level out-of-band map to forward proxy traffic from GigaSMART to the out-of-band tool port. |
When an inline tool is not shared, you must configure only the inline second level out-of-band map to forward proxy and non-proxy traffic from GigaSMART to the out-of-band tool port.
Note: When OOB-copy is configured in a non-shared inline-tool with the tag set as “inline”, both proxy and non-proxy out-of-band traffic will be copied with the proxy map VLAN tag.
Service Chaining of Decrypted Traffic
Service chaining of decrypted traffic may be required for compliance purposes.
This is done by directing the decrypted traffic to a hybrid port and applying the required GigaSMART operations on the traffic that is looped back from the hybrid port, before forwarding the traffic to the out-of-band tool.
The GigaSMART operations must be configured on a different GigaSMART engine than the one used for inline TLS/SSL decryption.
