Traffic does not pass through ClusterXL with enabled VMAC mode and SecureXL

Support Center > Search Results > SecureKnowledge Details

Symptoms

Clients are not able to connect to Server through ClusterXL in the following scenario:
- Virtual MAC (VMAC) mode is enabled on ClusterXL (per sk50840)
- SecureXL is enabled on ClusterXL
Traffic capture on ClusterXL shows:
- Traffic from Client to Server passes through ClusterXL successfully.
- The return traffic from Server to Client enters the ClusterXL, but is never forwarded to Client.
Disabling only SecureXL on ClusterXL resolves the issue.
Disabling only Virtual MAC (VMAC) mode on ClusterXL resolves the issue.
ClusterXL debug ('fw ctl debug -m cluster + drop') shows that the involved traffic is dropped by the cluster code:
fwha_select_ip_packet: dropping packet that arrived on ifn IF <Interface_Name> (<IfNumber> - vmac - <Virtual_MAC_Address>)

Cause

Cluster code drops packets that were forwarded by SecureXL on Medium path (PSL, QoS, VPN accelerated packets).

Flow of events:

First packet from Client to Server is always forwarded by SecureXL to FireWall.
Since Virtual MAC (VMAC) mode is enabled, packet's destination MAC address is changed.
SecureXL SIM debug ('sim dbg -m drv + pkt routing') would show:
;[cpu_N];[SIM...]dst mac: 00:1c:7f:YY:YY:YY <--> src mac: XX:XX:XX:XX:XX:XX;
Packet undergoes full inspection.
If connection is accepted, then FireWall offloads this connection (as accepted) to SecureXL.
The return traffic from Server to Client is processed by SecureXL.
If the involved packet must go through Medium path (PXL/QoS/VPN), then SecureXL must forward it to FireWall.

sim dbg -m drv + pkt routing

;[cpu_N];[SIM...]dst mac: XX:XX:XX:XX:XX:XX <--> src mac: 00:1c:7f:ZZ:ZZ:ZZ;

Cluster code drops this packet because internal destination MAC Address does not match the VMAC address of incoming interface.

Solution

Note: To view this solution you need to Sign In .