Connectivity And Security practice questions

Disable the security policy.

Why it fails: This would allow traffic but stop logging, the opposite of the goal.

Implement a Decryption Policy.

Why it fails: This is for inspecting encrypted traffic content, not just application monitoring.

Create a mirror port on the switch.

Why it fails: This is a network-layer solution outside the firewall configuration.

debug dataplane packet-diag

Why it fails: This is for dataplane traffic analysis, not management plane process monitoring.

show running config

Why it fails: This just lists current configurations.

show session all

Why it fails: This displays active sessions, not management plane CPU utilization.

NSSA

Why it fails: NSSA allows external routes, which is the opposite of the requirement.

Backbone Area (Area 0)

Why it fails: Area 0 must contain all routes and cannot be stubby.

Standard Area

Why it fails: Standard areas contain all route types.

Policies > Security

Why it fails: This is for policy management, not session viewing.

Device > Setup > Management

Why it fails: This is for management interface configuration.

Monitor > Logs > Traffic

Why it fails: This shows historical traffic, not real-time active session states.

The NAT policy is missing.

Why it fails: If NAT were missing, the session would still show bytes if the connection reached the server.

The Security Policy is misconfigured.

Why it fails: If it were a policy issue, the traffic would show as 'dropped' or 'rejected' in the logs.

App-ID is failing to identify the traffic.

Why it fails: If App-ID failed, the traffic would show 'incomplete' but would likely have some byte count.

Policy-based VPN

Why it fails: Policy-based VPNs are less flexible and rarely used in modern PAN-OS environments.

SSL VPN

Why it fails: SSL VPN is generally for remote access, not site-to-site connectivity.

L2TP VPN

Why it fails: L2TP is a legacy tunneling protocol.

Interface speed settings.

Why it fails: Interface speed is a physical layer setting.

SNMP community strings.

Why it fails: SNMP is for monitoring.

Global NTP server configuration.

Why it fails: NTP is for system-wide timing.

A static route with a lower metric on the secondary ISP and a floating static route on the primary ISP.

Why it fails: Static routes do not monitor latency. A floating static route activates only when the primary route is removed from the routing table, which typically requires the interface to go down. Since latency degradation does not remove the route, this approach will not trigger failover at the 200 ms threshold.

A virtual router with OSPF configured on both ISP interfaces and cost manipulation based on interface bandwidth.

Why it fails: OSPF cost is based on bandwidth or manually set values, not real-time latency. While OSPF can converge when a link fails, it does not react to latency spikes. This would not fail over at 200 ms and could cause unnecessary reconvergence, disrupting sessions.

ECMP with maximum path count set to two and a static route to 0.0.0.0/0 with equal metrics.

Why it fails: ECMP distributes new sessions across both paths based on hashing but does not react to latency thresholds. It also does not preserve existing sessions when a path degrades, because ECMP has no health monitoring tied to latency. This would cause unpredictable failover and does not meet the requirement.

The PBF rule does not have a 'negate' option enabled, so it only matches traffic that does not match the criteria.

Why it fails: The 'negate' option in a PBF rule is used to invert the match criteria; it is not required for a rule to function. Without negation, the rule matches traffic that meets the specified criteria. Enabling negation would make it match everything except the criteria, which is not desired here.

The PBF rule is evaluated after the security policy, and the security policy is allowing the traffic without forwarding.

Why it fails: PBF is evaluated before the security policy for the initial session. If the PBF rule matches, it forwards the traffic and the security policy is still applied for security inspection. The order is not the cause; PBF takes precedence for forwarding decisions.

The PBF rule requires a destination zone to be specified, and it is currently set to 'any'.

Why it fails: In Policy-Based Forwarding, a destination zone is not a required match criterion; the rule can match on source zone, source address, destination address, and application. Setting it to 'any' does not prevent matching. The issue is more likely related to the order of evaluation or the lack of a matching service/application.

A security policy allowing traffic from the VPN zone to the VPN zone.

Why it fails: A security policy permitting intra-zone traffic is not required for tunnel establishment; it only controls data traffic after the tunnel is up. The tunnel status remains red if the firewall cannot route encapsulated packets to the peer, which is typically a routing issue. This policy would not resolve the underlying connectivity problem.

A management profile allowing IKE and IPsec on the external interface.

Why it fails: Management profiles control administrative access to the firewall, not VPN tunnel negotiation. IKE and IPsec are handled by the dataplane and do not require a management profile. While interface permissions can affect VPN, management profiles are not the relevant setting for tunnel establishment.

A NAT policy exempting traffic between the local and remote networks.

Why it fails: NAT exemption is necessary to prevent source translation for VPN traffic, but it does not affect tunnel establishment. The tunnel can be up even if NAT is misconfigured; the issue would then be that traffic is translated and fails to match the VPN selector. Here, the tunnel itself is down, so NAT is not the cause.

Enable SSL Forward Proxy and configure a Decryption profile to block sessions with untrusted certificates.

Why it fails: Blocking sessions with untrusted certificates would prevent users from accessing the website entirely, which is not the goal. The engineer wants to allow decryption while avoiding certificate errors, so blocking is counterproductive. A Decryption profile that blocks untrusted certificates would cause connection failures, not seamless decryption.

Add the website's CA certificate to the firewall's trusted certificate authorities list and enable SSL Forward Proxy decryption.

Why it fails: Adding the website's CA to the firewall's trusted list does not enable decryption of traffic signed by an untrusted CA. SSL Forward Proxy requires the firewall to present its own certificate to the client, and the firewall must trust the server certificate or be configured to ignore trust issues. Simply trusting the CA does not resolve the untrusted CA error for decryption; the firewall would still block or not decrypt.

Configure SSL Inbound Inspection to decrypt traffic to the internal web server and apply security profiles.

Why it fails: SSL Inbound Inspection is used to decrypt traffic destined to internal servers, not outbound traffic to external websites. The scenario describes users accessing an external website, so inbound inspection is not applicable. Using SSL Inbound Inspection would not address the untrusted CA issue for outbound connections and would not decrypt the traffic as required.

File Blocking

Why it fails: File Blocking profiles restrict the transfer of specific file types. While it can prevent certain files from being downloaded or uploaded, it does not scan file contents for malware. It is a complementary profile but not mandatory for threat inspection and blocking malicious files, as antivirus handles content inspection.

URL Filtering

Why it fails: URL Filtering controls access to websites based on categories and is useful for enforcing acceptable use policies. However, it does not inspect files or traffic for malware. While it can block access to malicious sites, it is not mandatory for blocking malicious files; antivirus and vulnerability protection are more directly responsible for that.

Data Filtering

Why it fails: Data Filtering profiles are used to detect and block sensitive data patterns, such as credit card numbers or social security numbers, in traffic. They are not designed to detect malware or exploits. Therefore, they are not required for the stated goal of inspecting traffic for threats and blocking malicious files.

Enable RIP or OSPF on the tunnel interface.

Why it fails: Enabling a dynamic routing protocol on the tunnel interface can populate routes, but it requires configuration on both peers and may not be desired in all scenarios. For a simple Site-to-Site VPN, a static route is sufficient and more straightforward. The question asks what must be done to include the interface in the routing table; a static route is a direct method, while dynamic routing is an alternative that may not be necessary.

Assign an IP address to the tunnel interface and enable it.

Why it fails: Assigning an IP address and enabling the tunnel interface are necessary steps, but they do not automatically include the interface in the routing table. The routing table must have a specific route that points to the tunnel interface for the remote network. Without that route, the interface is up but not used for forwarding.

Configure a policy-based VPN instead of a route-based VPN.

Why it fails: Policy-based VPNs do not use tunnel interfaces; they use proxy IDs to select traffic. The question specifies a tunnel interface, which implies a route-based VPN. Switching to policy-based would eliminate the need for a tunnel interface route but would change the VPN type. The engineer wants to include the tunnel interface in the routing table, so this is not the correct action.

A rule with source zone 'Trust', destination zone 'Untrust', application 'web-browsing', and action 'Allow'.

Why it fails: This rule only allows the 'web-browsing' application, which typically covers HTTP but not HTTPS. HTTPS traffic is identified as the 'ssl' application. Therefore, this rule would block HTTPS traffic, which is part of web browsing. To allow both HTTP and HTTPS, both applications must be specified.

A rule with source zone 'Trust', destination zone 'Untrust', service 'service-http' and 'service-https', and action 'Allow'.

Why it fails: Using service objects (ports) instead of applications allows any application that uses those ports, including non-web applications that might tunnel over HTTP/HTTPS. This does not meet the requirement to allow only web browsing; it would allow any traffic on port 80 or 443. Application-based rules are needed to ensure only the intended applications are permitted.

A rule with source zone 'Trust', destination zone 'Untrust', application 'any', and action 'Allow'.

Why it fails: Allowing 'any' application would permit all traffic from Trust to Untrust, not just web browsing. This violates the requirement to block all other applications. The administrator must specify the applications to allow. Using 'any' is overly permissive and a security risk.

Configure a policy-based VPN instead of a route-based VPN.

Why it fails: Policy-based VPNs do not use tunnel interfaces; they use proxy IDs and are matched by security policies. The scenario specifically mentions a tunnel interface, which is used in route-based VPNs. Policy-based VPNs do not add a tunnel interface to the routing table because they do not have one. Therefore, this option is incorrect for the given scenario.

Enable OSPF on the tunnel interface to dynamically learn routes.

Why it fails: While OSPF can be used to dynamically learn routes over the tunnel, it is not a requirement to simply include the tunnel interface in the routing table. The question asks for configurations required to ensure the tunnel interface is included in the routing table; a static route is sufficient. OSPF would be an alternative to static routing but is not mandatory. In many Site-to-Site VPN deployments, static routes are used.

Assign the tunnel interface to a security zone.

Why it fails: Assigning the tunnel interface to a security zone is necessary for security policy enforcement, but it does not directly add the tunnel interface to the routing table. The routing table is populated by static routes or dynamic routing protocols. Zone assignment is about applying security policies to the tunnel traffic, not about routing. Without a route, traffic will not be sent through the tunnel even if the interface is in a zone.

Certificate Profile

Why it fails: A Certificate Profile is used to validate certificates presented by users or devices, but it does not enforce certificate authentication by itself. It must be referenced in an authentication profile or portal configuration. For portal authentication, you need to specify the authentication method, not just a certificate profile.

Client Certificate

Why it fails: Client Certificate authentication is used for the GlobalProtect agent to authenticate to the gateway, not for portal authentication before downloading the agent. The portal authentication is separate and occurs before the agent is installed. Configuring client certificate in the portal would not enforce certificate-based authentication for agent download.

Portal Authentication with SAML

Why it fails: SAML authentication is used for single sign-on and typically involves a browser-based login, not certificate-based authentication. While SAML can be used for portal authentication, it does not enforce the use of client certificates. The requirement specifically asks for certificate authentication, so SAML is not the correct choice.

Virtual Router Redundancy Protocol (VRRP)

Why it fails: VRRP is used to provide redundancy for a virtual router's IP address by electing a master and backup. However, it operates within a single virtual router or between devices, not between two separate virtual routers on the same firewall. It does not automatically reroute traffic between different virtual routers.

Static routes with backup paths

Why it fails: Static routes with backup paths can provide redundancy if a primary path fails, but they require manual configuration and do not dynamically reroute between virtual routers. They are not as flexible or automatic as dynamic routing protocols.

Policy-Based Forwarding (PBF)

Why it fails: Policy-Based Forwarding allows forwarding decisions based on policy rules, but it does not provide automatic failover between virtual routers. It is used for specific routing scenarios, such as directing traffic based on source or destination, but not for dynamic rerouting upon failure.

Increase the GlobalProtect timeout value.

Why it fails: Raising the GlobalProtect timeout only extends how long a session persists before disconnecting; it cannot alter the path MTU or ICMPv6 Packet Too Big handling that causes IPv6 fragmentation loss. Timeouts suit idle-session disconnects, not MTU issues, where lowering the tunnel MTU or clamping MSS is the fix.

Disable hardware offloading for IPv6.

Why it fails: Hardware offloading affects checksum and segmentation performance, not the MTU value that triggers fragmentation. It is tempting because offload bugs can cause odd packet loss, and disabling it would be correct when NIC offload corrupts packets, not when path MTU is the cause.

Enable IPv6 transition mechanisms on the external interface.

Why it fails: Transition mechanisms address IPv4-to-IPv6 interworking, not the path MTU that causes fragmentation drops. It is tempting because IPv6 connectivity issues often involve tunnelling, and enabling them would be correct when IPv6 hosts must reach IPv4-only resources, not for MTU discovery failures.

Objects > Addresses

Why it fails: Objects stores address definitions, not gateway-specific client settings.

Network > DHCP > Server

Why it fails: This is for configuring the firewall as a DHCP server for physical interfaces.

Device > Setup > Management

Why it fails: This manages firewall administrative settings, not VPN client pools.

debug dataplane packet-diag

Why it fails: This is for advanced packet capture and debugging, not quick policy lookup.

show running security-policy

Why it fails: This displays the policy configuration, not the outcome of a match.

show session all filter source <ip>

Why it fails: This shows existing sessions, not policy matching for blocked traffic.