Firewall Deployment Options for IoT Security
Table of Contents
Expand all | Collapse all
-
- Firewall and PAN-OS Support of IoT Security
- IoT Security Prerequisites
- Onboard IoT Security
- Onboard IoT Security on VM-Series with Software NGFW Credits
-
- DHCP Data Collection by Traffic Type
- Firewall Deployment Options for IoT Security
- Configure a Pre-PAN-OS 10.0 Firewall with a DHCP Server
- Configure a Pre-PAN-OS 10.0 Firewall for a Local DHCP Server
- Use a Tap Interface for DHCP Visibility
- Use a Virtual Wire Interface for DHCP Visibility
- Use SNMP Network Discovery to Learn about Devices from Switches
- Use Network Discovery Polling to Discover Devices
- Use ERSPAN to Send Mirrored Traffic through GRE Tunnels
- Use DHCP Server Logs to Increase Device Visibility
- Plan for Scaling when Your Firewall Serves DHCP
- Prepare Your Firewall for IoT Security
- Configure Policies for Log Forwarding
- Control Allowed Traffic for Onboarding Devices
- Support Isolated Network Segments
- IoT Security Integration with Prisma Access
- IoT Security Licenses
- Offboard IoT Security Subscriptions
-
- Introduction to IoT Security
- IoT Security Integration with Next-generation Firewalls
- IoT Security Portal
- Vertical-themed Portals
- Device-to-Site Mapping
- Sites and Site Groups
- Networks
- Network Segments Configuration
- Reports
- IoT Security Integration Status with Firewalls
- IoT Security Integration Status with Prisma Access
- Data Quality Diagnostics
- Authorize On-demand PCAP
- IoT Security Integrations with Third-party Products
- IoT Security and FedRAMP
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.