How Network Packet Broker Works
Focus
Focus

How Network Packet Broker Works

Table of Contents

How Network Packet Broker Works

The high-level workflow for connecting the firewall to a chain of third-party security devices is:
  1. Identify the non-decrypted TLS, decrypted TLS, and non-TLS (TCP and UDP) traffic to forward.
  2. Identify the security chain topology. Determine whether each security chain’s devices forward traffic transparently (bridging) or whether the devices route traffic based on Layer 3 information. Using multiple security chains helps load-balance traffic. In addition, decide whether to bypass the security chain (traffic goes through normal processing on the firewall and is forwarded or blocked accordingly) or block the traffic if a security chain fails a health check.
  3. Install the free Network Packet Broker license on the firewalls that will forward traffic to the security chain(s).
  4. Identify one or more pairs of firewall interfaces to forward traffic to one or more security chains and enable Network Packet Broker on those interfaces.
  5. Configure at least one Packet Broker profile.
  6. Configure at least one Network Packet Broker policy.
To use a chain of third-party security devices to inspect traffic, you configure three objects on the firewall:
  • Interfaces—One or more pair of layer 3 Ethernet firewall interfaces for forwarding traffic from the firewall to the security chain and receiving the processed traffic back from the security chain. Configure Network Packet Broker interface pairs before you configure profiles and policy rules because you need to specify the interface pairs in the profiles.
  • Packet Broker profiles—Profiles control how to forward the traffic that you define in a policy to a security chain. Each Network Packet Broker policy rule has an associated Packet Broker profile. Profiles define whether the security chain is a routed layer 3 chain or a layer 1 Transparent Bridge chain, the direction of traffic through the chain (unidirectional or bidirectional), the dedicated Network Packet Broker firewall interfaces, and how to monitor the health of the connection between the firewall and the security chain. For multiple routed layer 3 security chains, you can specify the first and last device of each chain and a session distribution (load balancing) method for the associated traffic.
  • Network Packet Broker policy rules—Policy rules define the application traffic to forward to each security chain or to load balance for multiple routed (layer 3) chains. Policy rules define the source and destination, users, applications, and services of traffic to forward to a security chain. Policy rules also define the type of traffic to forward to a security chain: you can select decrypted TLS traffic, non-decrypted TLS traffic, non-TLS traffic, or any combination of traffic types. You also add a Packet Broker profile in each policy rule to specify the security chain to which to forward traffic (and all of the other profile characteristics).
    Use Policy Optimizer to review and tighten Network Packet Broker policy rules.
To match application traffic to Network Packet Broker policy rules, Network Packet Broker looks up applications in the firewall App-ID cache. If the application is not in the App-ID cache, then the firewall bypasses the security chain and applies any threat inspection that is configured in the Security policy allow rule to the traffic. If the application is in the App-ID cache, then the firewall forwards the traffic to the security chain in the manner specified by the Network Packet Broker policy rule and its associated Packet Broker profile.
For non-decrypted TLS and non-TLS traffic, the firewall installs the application in the App-ID cache on the first session, so the firewall treats the traffic as specified in the Network Packet Broker policy and profile.
For decrypted TLS traffic, on the first session for an application, Network Packet Broker doesn’t know that the session is being decrypted and sees “ssl” as the application. The underlying specific application is not yet known or installed in the App-ID cache, so the broker lookup fails and the traffic bypasses the security chain. The traffic is still subject to any threat inspection configured on the Security policy allow rule. When the firewall decrypts the traffic, the firewall learns the specific application and installs it in the App-ID cache. For the second and subsequent decrypted sessions for the same application, Network Packet Broker lookups succeed because the specific application is now in the App-ID cache, and the firewall forwards traffic to the security chain as expected.