How does “Use Local Source MAC Address for Inspected Traffic” affect traffic on a segment?

Products

• SV-3800
• SSL Visibility Appliance Software
• SV-1800
• SV-2800
• SV-800
• SV-S550

Issue/Introduction

When this option is disabled (as it is by default), inspected traffic uses the original source MAC address as seen on the TCP three-way handshake for the SSL session. If the SSL Visibility appliance has a policy to inspect the SSL session, these learned source MAC addresses are also used going forward in order to be transparent on network ports.

In topologies that have active and passive network paths, each having its own SSL Visibility appliance where learning bridges are being used, this transparency can cause problems. In this scenario, using the original source MAC address for inspected flows can cause the learning bridge source MAC address table to flap. To avoid this situation, you can enable the segment option Use Local Source MAC Address for Inspected Traffic. When this option is enabled, the SSL Visibility appliance uses its local network interface source MAC for inspected traffic, thus using globally unique source MAC addresses and preventing any bridge flap.

Resolution

The SSLV will only change the source MAC address for inspected flows and this will apply to both sides of the SSLV.

The TCP handshake passes through unmodified for all flows:
- If the flow is SSL/TLS the SSLV will change the source MACs for the SSL handshake until a policy decision is made
- If cut-through the SSLV will switch the source MACs back to the original
- If inspect the SSLV will continue to use its own source MACs until that flow is finished
 
The Switch and the Firewall will always know the next hop IP and associated MAC and will continue to use them for routing and forwarding purposes. Again the SSLV will only change the source MAC, so the FW and the switch will now see two different MAC addresses, but this should not cause any issues as the SSLV is just another MAC in the table and not tied to any IP’s.

When failing back to the active FW it will send out its GARP, which the SSLV does not modify, and the traffic will be routed back without interruption. This feature allows the SSLV to remain transparent and if a packet reaches the standby SSLV or it sends out a packet for an inspected flow, such as a TCP keep-alive, it will use its own local MAC instead of the FW’s virtual MAC thus avoiding the flapping that is currently seen.