Exam PCNSE topic 1 question 586 discussion

A is the right answer. https://docs.paloaltonetworks.com/iot/getting-started/firewall-deployment-for-device-visibility

Virtual Wire can only generate EAL for received traffic

IOT - firewall vwire - DHCP server - Answer is A - vwire. https://docs.paloaltonetworks.com/iot/getting-started/firewall-deployment-for-device-visibility

Virtual Wire needs to be inline, looks like TAP is the best option

broadcast DHCP traffic

Answer is "D"

The only interface that is not “ in-line”

"NGFW is not in line of any DHCP traffic" Virtual Wire can only generate EAL for received traffic

From the links other provided “Virtual Wire: When the firewall has Virtual Wire interfaces with multicast firewalling enabled, it generates Enhanced Application logs (EALs) for broadcast DHCP sessions.”

I guess that “in line” in this sentence indicates that unicast DHCP is not received. Only Virtual wire can generate an EAL for broadcast DHCP Traffic. https://docs.paloaltonetworks.com/iot/iot-security-admin/get-started-with-iot-security/firewall-deployment-for-dhcp-visibility/dhcp-data-collection-by-traffic-type

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.

the engineer can use the Virtual Wire (vWire) interface mode to generate Enhanced Application Logs (EALs) for classifying IoT devices while receiving broadcast DHCP traffic. Here's why: Virtual Wire Interfaces: The text specifies that for Virtual Wire interfaces, multicast firewalling should be enabled. 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. This ensures that the firewall can generate the necessary logs even for broadcast DHCP traffic, which is crucial for IoT device classification.

A. for sure

Tap interface does not have to be inline.

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.) 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

answer is A. DHCP server, DHCP client and FW on the same broadcast domain means that a VWire interface will only catch the broadcast packets (not the unicast) and will still generate EALs. For a Tap interface to catch the 4 DHCP packets, the switch needs to mirror the traffic.

Has anybody recently taken the PCNSE exam? Are there any questions on the exam that are under #300 on the study guide?