| Description |
This article describes a known design issue that can occur when using a Transparent mode FortiGate with 3rd party network load-balancing clusters. |
| Scope | FortiOS v4.0 MR2, v4.0 MR3, FortiOS v5.0; Transparent mode |
| Solution |
Consider the following example topology:
Configuration Information
The following are the potential problems and solutions that can be observed with this configuration:
Traffic addressed to a multicast-based MAC address that traverses the FortiGate unit is sessionless, which results in the FortiGate being unable to scan the multicast traffic using antivirus, as well as the inability to create a stateful firewall session entry to allow return traffic. Even if a Firewall Policy is created in the reverse direction (for example, External -> Internal) to allow this return traffic, the FortiGate unit would still block it since it is performing stateful inspection and 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 Router sends an ARP request for the NLB cluster's Virtual IP address, the NLB ARP Reply will include the Virtual MAC Address in the ARP payload (Sender MAC Address) but the actual Source MAC Address of the Ethernet frame sent back to the Router will be the physical MAC address from the actual NLB Nodes (or possibly even a bogus MAC address).
This masking technique still informs the Router that packets must be routed towards the Virtual MAC, but it will also prevent the Transparent mode FortiGate (and the network switch) from learning the physical port on which 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 Node. When the FortiGate floods a packet in such a manner, it does not create a session for it. This results in the FortiGate being unable to perform antivirus scanning for this traffic, as well as 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 to inform it as to which interface is associated with the Virtual MAC address:
config system mac-address-table edit 00-00-5E-00-53-FF set interface External next end
This is only allowed if the target interface belongs to forward-domain 0.
Swapping MAC addresses of the cluster (Virtual versus Physical) For example, the router sends a packet destined for the cluster's Virtual MAC address, and the cluster replies using the Physical MAC of one of the two units. If antivirus is applied to these sessions, then traffic will not pass through the FortiGate. If antivirus scanning is not required, then the swapping MAC behaviour 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's external interface and the Switch.
Multicast ARP cache entries: Certain routers may not add a multicast MAC address to their ARP table if it is also associated with a unicast IP address. A static ARP entry may need to be added to those routers, though this is not a concern on the FortiGate.
Related article: |
