PAN OS Networking Configuration practice questions

Configure a virtual wire between HA1 and HA2 ports.

Why it fails: Virtual wires are not used for HA heartbeat management.

Assign the same IP to both HA1 interfaces.

Why it fails: HA1 links must have distinct IP addresses.

Configure an IP address on both interfaces

Why it fails: IP addresses are not required for vwire operation.

Create a loopback interface

Why it fails: Loopback is unrelated to vwire traffic flow.

Enable dynamic routing on the virtual wire

Why it fails: Dynamic routing is not supported on vwire interfaces.

Tap

Why it fails: Tap interfaces are for passive monitoring and do not process VLAN-tagged traffic for routing.

Virtual Wire

Why it fails: Virtual Wire interfaces do not support VLAN tagging in the same way as Layer 3 subinterfaces.

Layer2

Why it fails: Layer2 interfaces are for switching but do not handle tagged subinterfaces directly for routing purposes.

show interface all

Why it fails: This is for layer 2/3 link status.

show system state

Why it fails: This is for system metrics.

show routing fib

Why it fails: FIB only shows the final installed routes.

Enable DHCP relay on both interfaces

Why it fails: DHCP is for IP assignment, not traffic flow.

A VPN tunnel between the sub-interfaces

Why it fails: VPNs are not needed for local sub-interface routing.

A static route pointing to the physical port

Why it fails: Layer 3 switching happens via RIB/FIB.

Virtual Router

Why it fails: VR does not store crypto settings.

IPsec Crypto Profile

Why it fails: This handles Phase 2, not IKE Phase 1.

Tunnel Interface

Why it fails: Tunnel interfaces don't store encryption settings.

Network > Zones > Delete

Why it fails: This deletes a zone, not a policy.

Device > Setup > Delete

Why it fails: This is not a valid menu.

Right-click the rule and 'Remove'

Why it fails: The button is typically 'Delete'.

Matching interface speed

Why it fails: Interface speed affects throughput and link capacity, not whether a BGP session forms; peers establish over any reachable TCP path regardless of bandwidth. It is tempting because speed mismatches cause real problems at the physical and routing layers, so engineers reasonably suspect them when sessions fail.

OSPF adjacency

Why it fails: OSPF adjacency concerns interior routing between directly connected routers and has no bearing on BGP peer establishment, which depends on TCP port 179 reachability, matching AS numbers and prefix advertisement. It is tempting because both are routing protocols, and OSPF neighbour states genuinely matter when troubleshooting IGP adjacencies.

Matching router descriptions

Why it fails: Router descriptions are local administrative labels that are never exchanged during BGP session negotiation, so identical text cannot influence peer state. It is tempting because descriptions aid operational documentation and change tracking, which is why engineers often assume matching them across peers supports troubleshooting or consistency.

Aggregate Ethernet

Why it fails: Aggregate Ethernet bundles multiple physical links into one logical interface for bandwidth and redundancy, not segmentation. It tempts because it creates a distinct named interface, but all member links share one zone; segmentation requires separate interfaces or subinterfaces mapped to different zones.

Management

Why it fails: A management interface handles administrative access to the firewall itself, not traffic segmentation between networks. It tempts because it is a distinct interface with its own zone, but it exists for control-plane access, whereas segmentation needs data-plane interfaces carrying user traffic across separate security zones.

Loopback

Why it fails: Loopback is a virtual interface for management access and testing, not traffic segmentation; it carries no user traffic between zones. It tempts because engineers use it for routing stability and diagnostics, but segmentation requires physical or logical interfaces that forward packets between distinct security zones.

Aggregate setting

Why it fails: The Aggregate setting belongs to Layer 2 interface configuration, where subinterfaces and VLAN tags are defined. A Layer 3 interface instead requires interface type, security zone, and virtual router. It is tempting because aggregation appears on the same interface screen, but it is not one of the three settings the question expects.

Management Profile

Why it fails: Optional, not required.

Being the passive unit first

Why it fails: Irrelevant.

Having the most interfaces

Why it fails: Irrelevant.

Having the latest firmware

Why it fails: Irrelevant.

Remove the IP address from the physical interface and assign it to the subinterface.

Why it fails: Removing the IP address from the physical interface is not required to create a subinterface. PAN-OS allows a physical interface to retain its IP address while also hosting subinterfaces, each with their own IP addresses. The physical interface can continue to route traffic for its own subnet, while subinterfaces handle tagged VLANs. Therefore, this step is unnecessary and would disrupt existing connectivity.

Enable VLAN tagging on the physical interface by assigning it to a VLAN object.

Why it fails: Assigning the physical interface to a VLAN object is not a prerequisite for creating subinterfaces. VLAN objects are used for Layer 2 VLANs, not for Layer 3 subinterfaces. For Layer 3 subinterfaces, you simply add a subinterface and specify a VLAN tag (802.1Q). The physical interface remains a Layer 3 interface without a VLAN assignment.

Change the physical interface type to Layer 2 and then create the subinterface.

Why it fails: Changing the physical interface to Layer 2 would prevent it from having an IP address and would require a VLAN interface for routing, which is not the goal. The scenario specifies a Layer 3 subinterface, which is created directly on a Layer 3 physical interface. Converting to Layer 2 adds unnecessary complexity and does not align with the requirement.

The parent interface must be configured with the same VLAN tag as the sub-interface.

Why it fails: The parent interface does not need a VLAN tag; it acts as a trunk and passes tagged traffic to sub-interfaces. The VLAN tag is configured on the sub-interface itself. Configuring the same tag on the parent would conflict with the sub-interface configuration and is not required.

The sub-interface must be assigned to a virtual router different from the parent interface.

Why it fails: Sub-interfaces can be assigned to the same virtual router as the parent interface; there is no requirement for a different virtual router. In fact, they are often in the same virtual router to share routing information. This is not a mandatory step and would not cause traffic to fail.

The sub-interface must be configured as a Layer 2 interface.

Why it fails: Sub-interfaces can be Layer 3 interfaces if they are assigned an IP address. They are not required to be Layer 2. In fact, for routing between zones, a Layer 3 sub-interface is appropriate. Configuring it as Layer 2 would not allow IP routing and would not meet the requirement.

Intra-zone traffic is allowed if the interfaces are in different virtual routers.

Why it fails: Virtual router membership does not affect intra-zone security policy enforcement. Security zones are logical constructs independent of virtual routers. Traffic between interfaces in the same zone is still subject to the intra-zone default rule, regardless of virtual router configuration. This option is incorrect because it misattributes the behavior to routing rather than security policy.

Intra-zone traffic is controlled by the 'intrazone-default' rule, which can be modified to allow specific applications.

Why it fails: The 'intrazone-default' rule is an implicit rule that cannot be modified or deleted. It denies all intra-zone traffic by default. While you can create custom rules to allow traffic, you cannot alter the implicit rule itself. This option is incorrect because it suggests modifying an immutable rule.

Intra-zone traffic is allowed by default; no action is needed.

Why it fails: PAN-OS does not allow intra-zone traffic by default. The implicit intra-zone default rule denies traffic between interfaces in the same zone unless explicitly permitted. This option is incorrect because it contradicts the default security policy behavior. The engineer must create a rule to allow this traffic; otherwise, it remains blocked.

Configure the tunnel interface as a Layer 2 interface.

Why it fails: Tunnel interfaces are inherently Layer 3 interfaces. They cannot be configured as Layer 2. The tunnel interface operates at Layer 3 to encapsulate and route IP packets. Configuring it as Layer 2 is not possible and would not support VPN functionality. The correct type is Layer 3.

Enable OSPF on the tunnel interface.

Why it fails: OSPF is not required for a Site-to-Site VPN. Routing over the tunnel can be achieved with static routes or other dynamic protocols. While OSPF can be used to dynamically exchange routes over the VPN, it is not a mandatory configuration for the tunnel interface itself. The requirement is to have the interface in a zone and virtual router.

Configure the tunnel interface with an IP address.

Why it fails: While a tunnel interface can have an IP address, it is not strictly required for a route-based VPN. In many deployments, the tunnel interface is unnumbered and uses the IP address of another interface. The key requirement is that the tunnel interface is assigned to a zone and that routing directs traffic to it. An IP address is optional.

Static routes with path monitoring

Why it fails: Static routes with path monitoring can fail over between ISPs, but they are not policy-based. The requirement is to route specific traffic based on source IP using PBF. Static routes would affect all traffic, not just the selected subset. Therefore, this does not meet the policy-based requirement.

Dynamic routing with OSPF and BFD

Why it fails: While OSPF with BFD can detect link failures and reroute traffic, it is not directly tied to PBF rules. PBF is policy-based and does not automatically react to OSPF changes unless the PBF rule is configured to use the routing table. The scenario specifically requires PBF with monitoring, so OSPF/BFD is not the best fit.

HA active/active configuration with link monitoring

Why it fails: HA active/active is for firewall redundancy, not for ISP link failover within a single firewall. It does not provide policy-based forwarding decisions. The scenario involves a single firewall with two ISP links, so HA is not relevant. Thus, this option is incorrect.

Assign an IP address to the loopback interface and enable OSPF on it.

Why it fails: Assigning an IP address and enabling OSPF on the loopback interface is not sufficient because OSPF must be enabled on the virtual router, and the loopback interface must be included in an OSPF area. Simply enabling OSPF on the interface without area assignment does not activate it for OSPF. Thus, this step alone does not make the loopback usable as a router ID.

Assign an IP address to the loopback interface and add it to a security zone.

Why it fails: Adding a loopback interface to a security zone is not required for OSPF router ID purposes. Security zones are used for policy enforcement, not for routing protocol operation. While a zone may be needed for management access, it is not a prerequisite for OSPF to use the loopback as a router ID. Therefore, this step is unnecessary.

Assign an IP address to the loopback interface and configure it as a passive interface in OSPF.

Why it fails: Configuring the loopback as a passive interface prevents OSPF from forming adjacencies on it, which is often desirable, but it is not required to use it as a router ID. The router ID selection only requires the interface to have an IP address and be up. Passive mode is an optional optimization, not a mandatory step. Hence, this is not the required configuration.

The second IP address requires a separate Layer 3 interface because PAN-OS supports only one IP per interface.

Why it fails: This is incorrect because PAN-OS Layer 3 interfaces can have multiple IP addresses; you can add secondary IPs in the interface configuration. The limitation described does not exist. The real issue is likely return routing or policy, not the number of IPs. The engineer should verify routing and NAT for the 10.2.2.0/24 subnet.

A security policy must explicitly allow traffic from the 10.2.2.0/24 subnet because the trust zone only permits 10.1.1.0/24 by default.

Why it fails: This is incorrect because security policies are based on zones and IP addresses, not automatically restricted to a single subnet. If the policy allows the trust zone to untrust, both subnets are permitted. The issue is not policy but routing. The engineer should verify that return traffic can reach 10.2.2.0/24 through the firewall.

The firewall requires a separate virtual router for each IP subnet assigned to an interface.

Why it fails: This is false; a single virtual router can handle multiple subnets and interfaces. Creating a separate virtual router would isolate routing domains and is not required. The problem is not virtual router separation but rather the routing path for the 10.2.2.0/24 subnet. The engineer should check the routing table and upstream router configuration.

Configure a static route to the remote network pointing to the tunnel interface, and the firewall will automatically assign an IP address to the tunnel interface.

Why it fails: Static routes do not assign IP addresses to interfaces. The tunnel interface must be explicitly configured with an IP address. Without an IP address, the tunnel interface cannot be used as a next hop for routing. Static routes only define the path; they do not configure interface parameters.

Use a loopback interface with an IP address and reference it in the IPsec tunnel configuration as the local identity.

Why it fails: A loopback interface can be used as the local identity for IKE, but it does not provide an IP address for the tunnel interface itself. The tunnel interface still requires its own IP address to be used for routing. Using a loopback for identity is a common practice but does not fulfill the requirement of assigning an IP to the tunnel interface.

Create a tunnel interface in the Network > Interfaces > Tunnel section and assign it to a virtual router and a security zone.

Why it fails: Creating a tunnel interface and assigning it to a virtual router and zone is necessary, but it does not assign an IP address. The tunnel interface must have an IP address to be used for routing. This step alone is insufficient because the interface would remain without an IP, preventing it from participating in routing decisions.

Configure HA1 backup link on a different subnet than the primary HA1 link.

Why it fails: The HA1 backup link can be on a different subnet, but this is not a requirement for redundancy. The key is having a separate physical interface. Using a different subnet might complicate routing and is not necessary. The backup link can be on the same subnet as long as it is a separate physical path. The requirement is a separate interface, not a different subnet.

Enable HA1 encryption and configure a dedicated VLAN for HA traffic.

Why it fails: HA1 encryption secures control traffic but does not provide link redundancy. A dedicated VLAN can isolate traffic but does not automatically provide a backup path if the physical link fails. These settings enhance security and traffic separation but do not ensure HA1 connectivity if the primary link goes down. Redundancy requires an additional link.

Use the same physical interface for HA1 and HA2 with VLAN tagging.

Why it fails: Sharing a physical interface for HA1 and HA2 with VLAN tagging can be done, but it does not provide redundancy for HA1 itself. If that physical interface fails, both HA1 and HA2 are lost. This configuration is for interface conservation, not for HA1 link redundancy. It does not meet the requirement of maintaining HA1 connectivity if the primary HA1 link fails.