Policy Profile Options

The TCP destination port for decrypted traffic sent to inline tools can be configured as part of the profile.

Note:  If not configured, incoming port will be used directly as output by default.

Add this as a note in this section.

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 keyword 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.