MAC Address vs. Route Lookups

For traffic within a bridge group, the outgoing interface of a packet is determined by performing a destination MAC address lookup instead of a route lookup.

Route lookups, however, are necessary for the following situations:

  • Traffic originating on the Firewall Threat Defense device—Add a default/static route on the Firewall Threat Defense device for traffic destined for a remote network where a syslog server, for example, is located.

  • SSL policy enabled in transparent firewall mode—

    • TLS 1.3 traffic passes through the Firewall Threat Defense device device.

    • Firewall Threat Defense device acts as a TCP proxy. It terminates the client-side TCP connection and initiates a separate server-side connection. The Firewall Threat Defense device TCP stack owns the session state.

    • For idle proxied sessions, Firewall Threat Defense device generates TCP ACK keepalive probes to preserve the connection state. These are not passthrough packets—the firewall originates them and sends them toward the client or server depending on the state of the TLS transit connection.

    • Because the Firewall Threat Defense device originates these keepalives, it must perform an adjacency table lookup (next-hop or egress MAC resolution) even in transparent mode.

    • If the adjacency lookup fails for one of these proxy-generated packets, the Firewall Threat Defense device logs syslog 110003.

      To prevent these syslog messages, configure routes on the Firewall Threat Defense device for the transit connection endpoints (client and server IP addresses). Proper routing enables successful adjacency lookups for keepalive packets.

      If the Firewall Threat Defense device successfully sends a TCP keepalive and receives a reply, it keeps the transit connection active. If the device cannot send the keepalives, or receives no reply, it removes the transit connection after approximately 240 seconds.

  • Voice over IP (VoIP) and TFTP traffic, and the endpoint is at least one hop away—Add a static route on the Firewall Threat Defense device for traffic destined for the remote endpoint so that secondary connections are successful. The Firewall Threat Defense device creates a temporary "pinhole" in the access control policy to allow the secondary connection; and because the connection might use a different set of IP addresses than the primary connection, the Firewall Threat Defense device needs to perform a route lookup to install the pinhole on the correct interface.

    Affected applications include:

    • H.323

    • RTSP

    • SIP

    • Skinny (SCCP)

    • SQL*Net

    • SunRPC

    • TFTP

  • Traffic at least one hop away for which the Firewall Threat Defense device performs NAT—Configure a static route on the Firewall Threat Defense device for traffic destined for the remote network. You also need a static route on the upstream router for traffic destined for the mapped addresses to be sent to the Firewall Threat Defense device.

    This routing requirement is also true for embedded IP addresses for VoIP and DNS with NAT enabled, and the embedded IP addresses are at least one hop away. The Firewall Threat Defense device needs to identify the correct egress interface so it can perform the translation.

    NAT Example: NAT within a Bridge Group

    NAT in Threat Defense transparent mode.