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.
Where Can I Use This? | What Do I Need? |
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: 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
.
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:
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
.)
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
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.
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.