Inline TLS/SSL Decryption Solution with Layer 2 Transparent Tools
In an Inline SSL deployment, encrypted traffic passes through a sequence of components for secure decryption, inspection, and re-encryption. This deployment is designed to support Layer 2 inspection tools that analyze traffic without altering its contents.
The below shown is an inbound deployment of Inline TLS/SSL Decryption.
The shown is an outbound deployment of Inline TLS/SSL Decryption.
The following steps describe the end-to-end flow:
| 1. | Traffic Ingress-Traffic enters the system through the Inline Network Port (Ingress). This port acts as the first point of entry for all inbound encrypted traffic. |
| 2. | TLS/SSL Decryption-The traffic is directed to the GigaSMART engine, where the inline TLS/SSL application is. The engine decrypts the TLS/SSL traffic, making it readable for inspection tools. |
| 3. | Traffic Inspection-The decrypted traffic is forwarded to inline security tools (for example, IPS, WAF, SIEM, etc). These tools operate in Layer 2 (transparent) mode, meaning they inspect but do not modify packet contents. Tools may allow, alert on, or block traffic based on inspection results, but they do not change the actual data. |
| 4. | Traffic Return from Tools- after inspection, the traffic is returned to the GigaSMART engine. This ensures that only inspected traffic proceeds further. |
| 5. | SSL Re-encryption-The GigaSMART engine re-encrypts the traffic using the original TLS/SSL parameters. |
| 6. | Traffic Egress-The re-encrypted traffic is sent out through the Inline Network Port (Egress) to continue to the servers. |
Rules and Notes
The following table lists rules and notes that you need to be aware of while configuring your deployment.
|
Rule / Feature |
Details / Limitations |
|---|---|
|
Exclusive Use |
Inline tools in a flexible inline map cannot be used in classic inline or inline decryption maps. All inline networks and tools must belong to only one type of map. |
|
Collector Maps |
Only one unidirectional collector map is allowed for the same inline network. To use different VLANs in each direction, create separate unidirectional maps with unique VLAN tags. Tags can be set manually or assigned automatically by GigaVUE-FM. |
|
Unsupported Features ( GigaVUE‑TA200, GigaVUE‑TA200E, GigaVUE‑TA25E, GigaVUE‑TA25, GigaVUE‑TA400, GigaVUE-TA400E) |
- Physical Bypass (no BPS card) |
|
VLAN Tagging and OOB Copy Limits ( GigaVUE‑TA25, GigaVUE‑TA25E, GigaVUE‑HC1-Plus) |
Flexible Inline Single VLAN Tag with monitoring mode may send incorrect VLAN tags. OOB copy packets may also have wrong tags. You cannot use BYPASS WITH MONITORING with MONITORING mode on the tool. OOB copy from inline network is not allowed in this mode. |
|
Inline Map Limits — Bidirectional |
GigaVUE‑TA25,GigaVUE‑TA25E, GigaVUE‑HC1-Plus → 126 maps GigaVUE‑HC1,GigaVUE‑HC3 (CCv1 & CCv2), GigaVUE‑TA200, GigaVUE‑TA200E, GigaVUE‑TA400, GigaVUE-TA400E → 256 or 512 maps depending on setup. |
|
Inline Map Limits — Unidirectional |
GigaVUE‑TA25,GigaVUE‑TA25E, GigaVUE‑HC1-Plus→ 252 mapsGigaVUE‑HC1,GigaVUE‑HC3 (CCv1 & CCv2), ), GigaVUE‑TA200, GigaVUE‑TA200E, GigaVUE‑TA400, GigaVUE-TA400E → 512 or 1024 maps depending on setup. |
|
Flexible Inline SSL Limits |
Not supported with Inline Network LAG. Setting inline tools to “Drop” in the chain does not block Inline SSL traffic. |
|
Filtering Limits( GigaVUE‑TA400, GigaVUE-TA400E) |
VLAN-based filtering in the Egress Port Filter for OOB copies is not supported. If one tool in the map is in monitoring mode, all tools must use the same mode. Asymmetric hashing (a-srcip-b-dstip and b-srcip-a-dstip) is not supported. |
|
Protocol Pass-Through( GigaVUE‑TA400, GigaVUE-TA400E) |
CDP pass-through is not supported when the source is an Inline Network LAG. Bypass for LACP, CDP, and LLDP is supported. |
|
Scaling Limits — GigaVUE‑TA400, GigaVUE-TA400E |
Max Inline Networks and Tools: 48 Max Inline Network LAG list: 24 Max Inline tools or tool groups per direction: 16 Max OOB copy entries per direction: 17 Max OOB copy ports per entry: 128 |
