Policy Profile Options

The TCP destination port for decrypted traffic sent to inline tools can be configured as part of the profile. If not configured, incoming port is used directly as output by default.

Following are the two priorities that GigaSMART uses to decide on the TCP port number used for decrypted traffic:

■

Priority 1—This is a port map, which is user configurable. You can specify both the In Port and the Out Port. The In Port is the TCP destination port from a client. The Out Port is the TCP port used to send traffic to inline tools.

■

Priority 2—This is a default Out Port. This TCP port will be used if the incoming port does not match those specified in Priority 1.

Note:  You cannot configure Decryption Port Mapping and Tool Early Inspect features together.

Tool bypass can be enabled or disabled for the following types of traffic:

■

TLS/SSL decrypted traffic

■

non-decrypted SSL traffic (non-TLS/SSL TCP)

■

non-TLS/SSL traffic (non-TCP)

By default, tool bypass is disabled on these traffic types, meaning that all decrypted TLS/SSL, non-decrypted TLS/SSL, and non-TLS/SSL traffic is sent to the tools. When tool bypass is enabled on a specified traffic type, that traffic is not sent to the tools.

Starting in software version 5.2, inline network high availability active standby is supported. When enabled, link switchover by an upstream device in active/standby scenario is detected.

For example, when there is an inline TLS/SSL network group topology with two network port pairs (Na1, Nb1 and Na2, Nb2), the incoming traffic from one network (for example, Na1) may change to another network (for example, Na2) due to upstream devices, such as firewalls performing high availability active standby failover. If an upstream device fails over, GigaSMART will forward traffic to the correct inline network.

The default is disabled.

Note:  Do not enable this option if the inline TLS/SSL network group links are in an active/active scenario.

An inline network group topology can have multiple network port pairs (for example, Na1, Nb1 and Na2, Nb2). With multiple network port pairs, traffic from a network interface might traverse GigaSMART multiple times. Intercepted traffic from GigaSMART might reenter GigaSMART through a different network interface within the same network group as shown in 1.

1

Inline TLS/SSL Inline Network Group Configuration

When the inline TLS/SSL GigaSMART sits between internal devices and the upstream router, traffic from the devices to the Internet will be intercepted by GigaSMART. When internal devices belonging to different network port pairs within the same inline network group communicate with each other, traffic initiated from a device will be intercepted by GigaSMART and sent to the upstream router. This traffic will be routed back to GigaSMART from a different network port pair to reach the destination device.

Starting in software version 5.3, the same traffic sent from GigaSMART can reenter GigaSMART.

GigaSMART remembers the inline incoming inline network interface (for example, Na1) for each connection. When traffic from the same connection reaches GigaSMART with a different inline network interface within the same network group (for example, Na2), GigaSMART will forward the traffic to the corresponding opposite network interface (for example, Nb2), without further processing. This allows traffic from the same connection to reenter GigaSMART. GigaSMART will detect it and start forwarding traffic to the new network port pair.

However, the same traffic sent by GigaSMART reentering through the same network port pair (for example, Nb2, Na2) is not supported.

Other than the use case described above, any connection with traffic passing through GigaSMART involving more than the original network pair is not supported. If the first packet of a connection comes in through Na1, all traffic has to enter GigaSMART through the network port pair, Na1, Nb1.

You can enable or disable the inline network group multiple entry for the profile. The default is disabled.

In a layer 3 topology, the inline tools may need to change the MAC address or VLAN IDs when the client traffic is sent back to the server. The Tool Early Engage option supports the inline tools to make this change. When a connection request is received from the client, GigaSMART establishes the connection with the inline tool first, before connecting with the server. This helps the inline tools to modify the MAC address or VLAN IDs when sending the traffic back to the server.

With the One-Arm mode enabled, you can have both the client and server traffic travel through the same physical link or logical aggregate port channel.

Configuring One-Arm Mode

One-Arm Mode can be configured from GigaVUE‑FM and GigaVUE-OS CLI

In GigaVUE‑FM to enable One-Arm Mode do the following:

1.

Click on and select your node.

2.

While configuring maps, for the type Inline Second Level Map and click on the traffic path checkbox provided.

3.

Once you enable One-Arm, destination ports will become non-configurable.

In GigaVUE-OS CLI you can configure one-arm mode through the following commands:

• (config) # apps inline-ssl profile alias <profile_alias> one-arm enable​

Configure Inner MAP

• map alias <inner-map alias>

  use gsop <gsop alias>

  to <one-arm alias>

  from <vport alias>

  exit

Note:  Enabling one-arm mode in Inline second level map is applicable only if one-arm mode is enabled in inline-ssl-profile.

For each connection between the client and server, there are two TCP sessions established between GigaSMART and the inline network and two TCP sessions established between GigaSMART and the inline tool. In the above diagram, you can see that with the One-Arm mode enabled, both TCP sessions from the inline network side arrive at GigaSMART on the same link N1. The TCP sessions from the inline tool side arrive at GigaSMART on the same link T1.

In the above figure, the inline network link and inline tool link works as a pair – (N1, T1), (N2, T2), (N3, T3), and (N4, T4). The GigaSMART sends traffic to the corresponding tool link of the received network link. Similarly, GigaSMART sends the traffic back to the server on the corresponding network link of the received inline tool link. For example, when a connection comes to GigaSMART from the inline network N1, after decryption, GigaSMART sends clear text traffic to inline tool on T1. The return traffic of the same connection arrives at GigaSMART on the inline tool link T2. GigaSMART then re-encrypts the traffic and sends it to the server on the inline network link N2.

Failover Support

When the inline network link and inline tool link work as pairs and when one of the link goes down, the corresponding link of the pair will be forced down. To achieve this behavior, you can either configure Link Aggregation Control Protocol (LACP) or enable Link Failure Propogation (LFP) between the pair of inline network link and inline tool link.

Important Rules and Notes

Keep in mind the following rules and notes before you enable the One-Arm mode for your policy profile:

■

Inline network must be connected to Na side and inline tool must be connected to Nb side of the inline network.

■

The Tool Early Engage option must be enabled.

■

One-Arm mode is not supported on flexible inline decryption solution.

■

To route the packet through the firewall, you must configure the client and server gateway to the router’s IP address.

■

Second level oob is not supported. Instead, oob can be achieved by map-passall from the tool port.

■

When the Tool Early Engage and One-Arm mode is enabled, the MAC address or VLAN IDs can be changed, whereas, the IP address, ports, and protocol cannot be changed by the inline tool.

■

Inline network group multiple entry and High Availability active stand-by are not supported when you enable the One-Arm mode for your policy profile.

■

Ensure that LACP is enabled on both network and tool sides.

■

Ensure that LFP is enabled on the inline network configuration.

■

Bypass inline-tool options in the inline TLS/SSL profile (decrypt, no-decrypt, non-tls/ssl) will only work if you have another router configured on the network side to route the packets.

■

The name "one-arm" is a registered key word hence do not name your Inline network ,Inline tool or Map as "one-arm" . If you have existing alias with "one-arm" as the name then modify it before upgrading to GigaVUE-OS 5.12.xx.

■

Resilient Inline Arrangement will also not be supported if one-arm mode is enabled.

■

If 'one-arm' is configured as a tool in inline second level map, VPort status will be "up" not "up (Normal)".

■

One-Arm mode cannot co-exist with the Tool Early Inspect feature.

In the existing Inline TLS/SSL solution, the GigaVUE node intercepts the TLS/SSL connection initiated between the client and the server. The decrypted data is sent to the inline tool only after completing the TLS/SSL handshake connection between the client and the server. The downside of this method is that the TLS/SSL connection to the server is established, even for connections that the inline tool will subsequently reject.

Starting in software version 6.3.00, if Tool Early Inspect feature is enabled, the TLS/SSL handshake initiated by the client is completed first using the configured server certificate and key, and the decrypted data will be sent to the inline tool for inspection before connecting to the server. This process helps to ensure that only valid connections are sent to the server.
The following image explains the sequence of operations in the Tool Early Inspect feature.

Note:  Tool Early Inspect feature will only be supported in the inbound deployment modules; the outbound and hybrid deployment modules will not support it.

This feature focuses on a new approach in GigaSMART to offload TLS decryption from Layer 3 inline-tools performing NAT/PAT (Network Address Translation / Port Address Translation) on the traffic passing through them. The GigaSMART engine maintains two separate sessions towards the client and server-side to achieve this.

Supported Platforms

■

Gen3 cards in GigaVUE-HC1 and GigaVUE-HC3

■

GigaVUE-HC1-Plus

Topology

The following are the preferred topologies for connecting to L3 NAT/PAT tools. The tool must be connected to the Nb side of the inline-network pair and the network links must be connected to the Na side of the inline-network pair.

 

 

 

The traffic from the network is forwarded to the tool and the reverse traffic from the tool is forwarded to the server side.

Also due to separation of client and server side connections, it is possible to have the client and server connected across GS engines or devices as shown below.

However currently there is no communication mechanism between separate engines or devices. The fail-over action for these solutions must be vport-drop to avoid leaking of decrypted traffic to the network.

 

HTTP 2.0 Downgrade

In the Inline SSL APP, the HTTP2 Downgrade option is enabled by default, when the NAT/PAT Mode is enabled. The HTTP 2.0 traffic is downgraded to HTTP 1.1 and decrypted. When HTTP2 Downgrade option is disabled, the HTTP2 traffic is forwarded without decryption.

Decryption Port Mapping

In the Inline SSL application profile with NAT/PAT mode enabled, decrypted traffic can be sent to user-defined L4 ports. This feature supports the following scenarios:

■

One-to-One Tool Port Address Translation: A specific clear text port matching Inline SSL traffic is assigned, and after decryption, the decrypted flow is directed to this assigned port.

■

Many-to-One Tool Port Address Translation/Default Port Mapping: Multiple incoming SSL Layer 4 ports are mapped to a specific single clear text Layer 4 port . If a one-to-one tool port translation does not exist, the system directs decrypted traffic to the configured default port mapping.

■

No Port Mapping- If one-to-one or default port mappings are not configured, decrypted traffic will continue to use the same original L4 port from the incoming encrypted data.

 

To configure this feature, enable the NAT/PAT Mode and then configure the port details in TCP Port MAP Decryption. Refer to Inline TLS/SSL Decryption Port Map.

To configure the port details using GigaVUE-OS CLI, see the apps inline-ssl command section in the GigaVUE-OS CLI Reference Guide.

 

Limitations

■

L3 Tool port address translation does not apply to explicit proxy scenarios. Therefore, the tool port mapping must not include explicit proxy L4 port address.

■

The Start TLS port should not be configured in any port mapping settings, whether one-to-one or as a default port map.

■

Any L4 port expected to receive the first data from the server must not be included in the port mapping configuration.

Cache Timeout

The server information is cached for performance optimization. The default time out is 30 minutes. The cache is flushed when the cache timeout value is set to zero. The cache is disabled when the timeout value is set to zero.

Refer to the following Gigamon Validated Design for more information:

• Offloading TLS Decryption for an One-Armed Inline Tool in L3 with NAT/PAT Mode
• Enabling GigaSECURE TLS Decryption to Offload SSL Inspection from Next-Generation Firewall

Limitations

■

The decrypted data to inline tool is limited to HTTP/1.1 protocol over TLS, inline tool will only see encrypted data on other application protocols.

■

The StartTLS traffic will not be decrypted as it is non HTTP traffic.

■

It does not support bypass tool since all the packets from client or server need to pass to inline tool for NAT/PAT.

■

This feature cannot co-exist with features such as Network group multiple entries, Inline network high availability, RIA, Tool early engage, Tool early inspect and One-Arm.

■

The IPv6 version is not supported in software release version 6.1.00. The IPv6 version is supported from software release version 6.2.00