: Firewall Deployment Options for IoT Security
Focus
Focus

Firewall Deployment Options for IoT Security

Table of Contents

Firewall Deployment Options for IoT Security

Consider if the firewall sees unicast DHCP traffic and whether to use a Tap interface or Virtual Wire interface.
When assessing deployment options for IoT device visibility, there are two fundamental considerations:
  • The firewall must see traffic for the IoT application to use network traffic data for classification and analysis and for the enforcement of policy rules on the firewall itself. This includes regular operational traffic in addition to DHCP traffic.
  • With the exceptions outlined below, the firewall must see unicast DHCP traffic to generate the data that allows IoT Security to create the required IP address-to-device mappings.

Exceptions to the Unicast Rule

  • Virtual Wire: When the firewall has Virtual Wire interfaces with multicast firewalling enabled, it generates Enhanced Application logs (EALs) for broadcast DHCP sessions.
  • A DHCP server is configured on the firewall:
    • PAN-OS 8.1 - 9.1: A configuration-only workaround is required for the firewall to generate EALs when a DHCP server on one of its interfaces receives broadcast DHCP traffic.
    • PAN-OS 10.0 and later: No workaround is required for the firewall to generate EALs when a DHCP server on one of its interfaces receives broadcast DHCP traffic. Just enable DHCP Broadcast Session at DeviceSetupSession.
      When the firewall receives DHCP broadcast traffic and applies a policy rule with an Enhanced Application log forwarding profile, it logs the DHCP traffic and forwards it to the logging service. From there, IoT Security accesses the data for analysis.
  • A DHCP relay agent is configured on the firewall:
    • The firewall generates EALs for broadcast DHCP traffic when a DHCP relay agent is configured on one of its interfaces.

Tap Interfaces

Considerations – If you use a Tap interface to gain visibility into DHCP traffic that the firewall doesn’t ordinarily see, consider the following:
  • Place the tap “north” of any routed boundary where DHCP is configured. This will ensure that the captured traffic is unicast rather than broadcast. (If the firewall with the Tap interface is in the same broadcast domain as the switch that’s mirroring traffic to it, enable DHCP Broadcast Session at DeviceSetupSession.)
  • If adding a tap interface to an existing firewall, consider the available capacity on the firewall before implementing. While tap interfaces don’t forward traffic, traffic seen on the tap port still consumes resources for processes such as the session table and packet buffers. For guidance on mitigating performance impact, see Use a Tap Interface for DHCP Visibility.
Use Cases for Tap interfaces
  • Evaluations
  • Networks where DHCP is configured on a device “south” of the firewall
  • Monitor networks that don’t naturally traverse the firewall

Virtual Wire Interfaces

Considerations – You might have to use a Virtual Wire (vWire) interface on the firewall to gain visibility into DHCP traffic that the firewall wouldn’t normally see. Consider the following when using a tap interface in this manner:
  • Ensure the Virtual Wire has multicast firewalling enabled.
  • Ensure the Virtual Wire is in the path for DHCP traffic. This traffic can be either broadcast or unicast.
  • Ensure that a security policy rule allowing DHCP exists and that a proper log-forwarding profile is applied to the rule.
  • Ensure the firewall has the available capacity to process the additional traffic. For guidance on mitigating performance impact, see Use a Virtual Wire Interface for DHCP Visibility.
Use Case for Virtual Wire interfaces – When the DHCP server and the firewall interface are on the same network segment, the firewall sees only broadcast DHCP traffic. Placing the DHCP server behind a Virtual Wire interface enables the firewall to create EALs for this broadcast traffic.

Layer 2 and Layer 3 Interfaces

Considerations – Layer 2 (L2) and Layer 3 (L3) deployments both require unicast DHCP traffic to generate EALs. When using a VLAN interface in an L2 deployment, the considerations are the same as a deployment using Layer 3 interfaces:
  • Unicast DHCP packets traversing the firewall generate an EAL.
  • When an L3 or VLAN interface is configured as a DHCP relay agent, the firewall generates an EAL.
  • When an L3 or VLAN interface is configured as a DHCP server the firewall might generate an EAL. For more information, see DHCP Data Collection by Traffic Type in Firewall Deployment for Device Visibility.