Technical Note: Transparent mode Layer-2 Ethernet issues with 3rd party load balancing clusters

[#1]

Article

Description	FortiGate transparent mode layer-2 Ethernet issues with 3rd party load balancing clusters
Components	FortiGate units running in transparent mode FortiOS 4.0 MR2, 4.0 MR3, FortiOS 5.0
Steps or Commands	Configuration Information The NLB (Network Load Balancer) uses a virtual IP and virtual MAC to which packets are addressed. The virtual IP is unicast. The virtual MAC is either unicast or multicast (configurable). The internal router will send packets to this NLB using either the unicast or multicast MAC address, as advertised by the cluster within an ARP reply. Potential problems and solutions Multicast MAC addressing traverses the FortiGate unit. Traffic addressed to a multicast MAC that traverses the FortiGate unit is sessionless, which results in the inability to antivirus scan the multicast, and the inability to create a stateful firewall session entry for the return traffic. Even if a firewall policy is created in the reverse direction (Ext->Int) for the return traffic, the FortiGate unit would still block it, since it is performing stateful inspection, and it would not have "seen" the originating packet corresponding to that session. The solution is to configure the NLB to use a Virtual Unicast MAC address. Masked Virtual Unicast MAC address When the client sends an ARP request to ask the NLB's MAC address, the NLB may respond with an ARP Reply that includes the Virtual MAC in the ARP payload (Sender MAC Address) but the Source Ethernet MAC will be one of the Physical units (or it may be a bogus MAC).  This masking technique informs the client that packets must be sent to the Virtual MAC, while at the same time it prevents the FortiGate, and switch from learning on which port the Virtual MAC resides.  The FortiGate and switch will therefore flood these received packets out of all ports, which effectively achieves load balancing by sending duplicate packets to each NLB unit.  When the FortiGate floods a packet in such a manner, it does not create a session for it, and this will result in the inability to antivirus scan it, and the inability to create a stateful firewall session entry for the return traffic.  To resolve this, manually configure a static MAC entry on the FortiGate, which informs it where the Virtual MAC resides:   config system mac-address-table edit 00:50:5A:20:14:1E set interface external end Please note that this is only allowed if the target interface is in forward domain 0. Swapping MAC addresses of the cluster (Virtual versus Physical) For example, the router sends a packet to the cluster's Virtual MAC, and the cluster replies using the Physical MAC of one of the two units. If antivirus is applied to these sessions, traffic will not pass through the FortiGate unit. If antivirus scanning is not required, then the swapping MAC behavior is not a problem. Otherwise the NLB must be configured to reply to the FortiGate unit with the same MAC address that it uses in its ARP payload replies. Another solution could be to insert a router between the FortiGate unit's external interface and the switch. Multicast ARP cache entries  Certain routers, Cisco for example, may not add a multicast MAC address to their ARP table, if it is associated with a unicast IP. A static ARP entry in the router may be required. This does not concern FortiGate units. Additional information concerning layer 2 issues with a FortiGate unit running in transparent mode is available in the Fortinet Knowledge Base article "Configuration best practice and troubleshooting tips for a FortiGate in Transparent mode"