Nse7 Enterprise Firewall Security And VPN practice questions

Weight

Why it fails: Weight is local to the FortiGate and is not advertised to either ISP, so it cannot steer traffic across two external peers; it only ranks routes learned from neighbours on the same device. It is tempting because it is the first attribute in the best-path order, and would be correct for preferring one of two routes received from the same ISP.

AS-Path

Why it fails: AS-Path prepending affects inbound traffic, influencing how remote autonomous systems choose the path towards you, not which ISP your FortiGate selects for outbound destinations. It is tempting because it is a common traffic-engineering tool, and would be correct when you want ISP1 to be preferred by the internet for your advertised prefixes.

Multi-Exit Discriminator (MED)

Why it fails: MED influences inbound traffic for external peers.

set metric-type

Why it fails: Metric-type is used for external route types.

set bandwidth-reference

Why it fails: Setting bandwidth-reference only rescales the cost formula's reference value globally; it does not set a link's cost, so the preferred path cannot be steered directly. It is tempting because it genuinely influences OSPF metric calculation across the area, and would be the right choice when you need all interface costs recalculated against a different reference bandwidth.

set priority

Why it fails: Setting OSPF interface priority only influences designated-router election on broadcast segments; it does not alter the metric used for path selection. The stem requires manipulating link cost, which is carried in Type 1 and Type 2 LSAs. Priority would be the right choice when forcing which router becomes DR or BDR on a multi-access network.

diagnose sniffer packet

Why it fails: This checks traffic flow, not the routing table.

get system status

Why it fails: This shows device health, not routing details.

exec ping-options

Why it fails: This is for sending test traffic.

Firewall address object

Why it fails: A firewall address object only matches IP addresses or subnets; it cannot identify SSL-protected website categories or FQDNs for inspection bypass. SSL exemptions require the SSL inspection exemption list or a custom category. Address objects tempt administrators used to policy matching, but they operate at layer 3/4, not the TLS SNI layer.

Application Control override

Why it fails: Application Control overrides govern action on matched application signatures; they do not exempt destinations from SSL inspection. The correct feature is an SSL exemption entry, which the inspection policy consults by SNI or FQDN. Application Control would be the right choice when you need to permit, block or shape a detected application rather than skip decryption.

IPS signature exclusion

Why it fails: IPS signature exclusions disable individual intrusion-prevention signatures for traffic already being inspected; they cannot exempt a destination from SSL decryption. The correct feature is an SSL exemption, matched on SNI or FQDN within the inspection profile. IPS exclusions suit suppressing false-positive detections from a specific signature, not preserving user privacy.

get system hardware status

Why it fails: This shows hardware health, not process CPU.

diagnose sniffer packet

Why it fails: This is for debugging traffic, not system performance.

get router info memory

Why it fails: This is for memory usage, not CPU usage.

An OSPF area configuration

Why it fails: OSPF is a dynamic routing protocol and has no role in DNS resolution. It is tempting because OSPF is commonly configured on FortiGates for internal routing; it would be correct when advertising or learning routes, whereas hostname resolution requires DNS servers and a route to reach them.

An IPSec tunnel for DNS traffic

Why it fails: DNS resolution needs a DNS server reachable via a routed path, not a tunnel dedicated to DNS. An IPSec tunnel is tempting because it secures traffic to a remote resolver, and would be correct when the DNS server sits behind a VPN rather than being publicly reachable.

A static route to the internet

Why it fails: A static route alone cannot resolve hostnames; the FortiGate still needs a DNS server configured under system dns. Static routes are tempting because reachability is a prerequisite, and the route would be correct when the DNS server is off-subnet and no dynamic route covers it.

Hardware serial numbers

Why it fails: Serial numbers are unique to each device.

Management IP address

Why it fails: Each unit has a unique management IP.

Re-route to a specific switch port

Why it fails: Policy actions control accept, deny, authentication, and inspection features; re-routing to a specific switch port is not among them, since forwarding decisions follow the routing table. It is tempting because policy-based routing exists, but that selects a next-hop gateway or interface, not an individual switch port.

Disable hardware acceleration

Why it fails: Hardware acceleration is a global or per-policy setting, not an action triggered when a policy matches. It is tempting because disabling acceleration is a real troubleshooting step for features that break offload, but it is configured beforehand rather than executed as a policy-match outcome.

The VIP is not included in the HA synchronization because its external interface is not monitored.

Why it fails: HA synchronization of VIPs depends on the configuration being synchronized, not on interface monitoring. Interface monitoring affects failover triggers, not object synchronization. The VIP would be synchronized as part of the configuration if the HA cluster is properly configured. Therefore, this is not the cause of the session failure after failover.

The firewall policy referencing the VIP is not synchronized because it was added while the cluster was out of sync.

Why it fails: Firewall policies are synchronized in an HA cluster. If a policy was added while the cluster was out of sync, it might not be present on the secondary. However, the scenario states the VIP is synchronized, implying the configuration is in sync. This option is plausible but less likely than the actual cause related to ARP.

The VIP's external interface is not configured as a monitored interface in the HA settings.

Why it fails: Monitored interfaces determine which interfaces are checked for failover conditions. They do not affect the sending of gratuitous ARP for VIPs. The VIP's external interface should be monitored to detect link failures, but that is separate from ARP behavior after failover. Thus, this is not the cause of the session failure.

Change the IPS mode from blocking to monitoring

Why it fails: Switching to monitor mode stops the drop but also stops all blocking, leaving the false-positive signature and every other exploit unenforced. It tempts as a quick fix; the targeted remedy is exempting the specific signature or source while keeping the sensor in blocking mode.

Disable the entire IPS sensor profile

Why it fails: Disabling the whole sensor removes protection against every signature, not just the offending one, so the web server loses IPS coverage entirely. It tempts as a fast way to stop drops; the precise fix is tuning or exempting the single false-positive signature while blocking continues.

Increase the IPS packet buffer size

Why it fails: Increasing the packet buffer only changes how much data is held for inspection, so the signature still matches and the traffic remains dropped. It is tempting because buffer tuning addresses throughput and memory exhaustion under heavy load, where it would be the right fix — not signature-level false positives.

SSL VPN portal settings

Why it fails: Portal settings control bookmarks, split tunnelling and layout, not endpoint posture; host checking enforces compliance. It tempts because the portal is the SSL VPN entry point users see, and it would be correct when customising realm appearance or restricting which bookmarks appear after login.

Two-factor authentication

Why it fails: Two-factor authentication verifies user identity with a second credential, not device compliance; it cannot detect missing antivirus or patches. It tempts because MFA is a standard VPN hardening step, and it would be correct when the requirement is proving the connecting user is who they claim.

PKI user authentication

Why it fails: PKI authentication validates a client certificate's trust chain, proving identity or device enrolment, but it does not inspect antivirus, patch level or firewall state. It tempts because certificate-based access feels device-bound, and it would be correct when only certificate-issued machines may authenticate.

Configure a distribute-list in the OSPF process

Why it fails: A distribute-list filters routes already present in the OSPF database in inbound or outbound directions; it cannot constrain which connected subnets redistribution injects. It is the right tool for filtering prefixes received from a neighbour or suppressing specific LSAs leaving an area.

Use an IP prefix list under the OSPF area command

Why it fails: Prefix lists attach to redistribution or route-map statements, not to the OSPF area command, which governs area type, authentication and stub settings. A prefix list is correctly used as the match condition inside a route-map applied to the redistribute connected statement.

Use an access list under the interface configuration

Why it fails: Access lists on a FortiGate interface control administrative access protocols such as HTTPS, SSH and ping; they do not filter routing updates. An access list would be the correct mechanism when restricting which management services may reach an interface.

Incorrect IKE version

Why it fails: IKE version mismatch prevents Phase 1 from establishing, so Phase 2 never begins. Phase 2 failures stem from mismatched proxy IDs, encryption or authentication algorithms, or PFS settings. IKE version tempts because it is a common VPN misconfiguration, but it manifests as Phase 1 failure, not Phase 2.

Expired certificate

Why it fails: An expired certificate breaks Phase 1 authentication when certificate-based IKE is used; Phase 2 would not be reached. Phase 2 failures arise from proxy ID, encryption, authentication or PFS mismatches. Certificates tempt because they are a frequent VPN issue, but they affect Phase 1, not the Phase 2 quick mode negotiation.

Mismatched pre-shared key

Why it fails: A mismatched pre-shared key causes Phase 1 authentication to fail, so Phase 2 is never negotiated. Phase 2 failures come from proxy ID, encryption, authentication or PFS mismatches. The PSK tempts because it is the classic VPN misconfiguration, but its symptom is Phase 1 down, not Phase 2.

Send to local DNS

Why it fails: FortiGate does not forward unmatched traffic to local DNS; DNS settings are unrelated to policy lookup. When no policy matches, the implicit deny discards the packet and logs it. Sending to DNS is tempting because FortiGate does perform DNS resolution for FQDN objects, but that occurs during policy matching, not as a fallback action.

Route to DMZ

Why it fails: Unmatched traffic is denied by the implicit deny policy; it is never routed to a DMZ, which is simply a zone defined by interfaces. It is tempting because DMZ zones host exposed services, but no implicit forwarding rule exists.

Allow

Why it fails: FortiGate applies an implicit deny at the end of policy lookup: traffic matching no explicit policy is dropped and logged, not allowed. Allowing unmatched traffic would require an explicit permit-any policy. Allow is tempting because administrators often add a broad allow rule for troubleshooting, but that is a deliberate configuration, never the default behaviour.

The FortiGate's local device certificate

Why it fails: The FortiGate's local device certificate is self-signed and not trusted by endpoint browsers, so warnings persist; SSL inspection requires the CA certificate that signed the inspection certificate. It is tempting because it is the FortiGate's own certificate, but it would be correct only for authenticating the firewall itself, not for inspection.

The Fortinet_Factory CA certificate

Why it fails: Fortinet_Factory is the appliance's default self-signed CA, trusted by no endpoint browser, so warnings persist. It is tempting because it signs the FortiGate's own management GUI certificate. The correct choice is the CA certificate generated for SSL inspection, exported and pushed to clients as a trusted root.

A third-party public CA certificate

Why it fails: A public CA cannot sign the forged per-site certificates deep inspection generates, so browsers still warn. It is tempting because public CAs are already trusted everywhere for ordinary TLS. The correct choice is the private inspection CA, whose root certificate must be imported into each endpoint's trust store.

Missing static route

Why it fails: A missing static route breaks return-path forwarding, but the tunnel would typically fail or traffic would be dropped before policy evaluation; the usual cause is no firewall policy permitting the tunnel's source and destination subnets. It is tempting because routing is a common IPsec fault, yet policy absence is the classic symptom here.

Incorrect IKE ID

Why it fails: An incorrect IKE ID prevents Phase 1 negotiation from completing, so the tunnel would never reach the up state. It is tempting because mismatched IKE IDs are a genuine cause of tunnel establishment failures, but the stem already confirms the tunnel is up, shifting the fault to Phase 2 selectors or missing firewall policy.

Phase 1 lifetime expiration

Why it fails: Phase 1 lifetime expiry tears down the tunnel entirely, so it cannot remain up while silently dropping traffic. Lifetime mismatches are a real negotiation problem worth checking during tunnel establishment, but once the tunnel is established this timer only governs rekeying, not whether firewall policy permits the interesting traffic.

To force traffic through the hardware switch

Why it fails: 'Any' matches all interfaces as source or destination, so it cannot force traffic through a hardware switch; that requires naming the switch port explicitly. It tempts because 'Any' is the default in many policies, and it would be correct when a rule must apply regardless of ingress or egress interface.

To bypass the routing table

Why it fails: The 'Any' interface matches traffic arriving on any interface, but packets still traverse normal route lookup to select an egress interface and next hop; it never bypasses the routing table. It is tempting because 'Any' removes ingress-interface matching, which is useful for policies that must accept traffic regardless of arrival port.

To match traffic only on the WAN port

Why it fails: 'Any' matches traffic on every interface, not just the WAN port; restricting to WAN requires selecting that specific interface or zone in the policy. It is tempting because WAN-facing policies are common, so administrators may assume 'Any' is shorthand for the external port.

Use a distribute-list

Why it fails: A distribute-list filters inbound or outbound prefixes on a neighbour, but suppressing component routes while originating a summary requires aggregation with a suppress policy or an explicit outbound filter of the specific prefixes. Distribute-lists alone cannot generate the summary. They suit filtering unwanted received routes.

Set the weight to 0

Why it fails: Weight is a local, router-specific preference influencing outbound path selection; it is never transmitted to peers, so it cannot suppress component prefixes from the ISP. The requirement is outbound advertisement filtering. Weight tuning suits influencing which exit path local traffic takes, not controlling what neighbours receive.

Configure a route map with a prefix list

Why it fails: A prefix list inside a route map filters which prefixes may be advertised, but it does not itself suppress the more-specific component routes; you must also apply aggregation (the network command or an aggregate address) so only the summary is originated. Route maps are for manipulating attributes and filtering, not summarisation.

To replace the AH protocol

Why it fails: AH is a separate IPsec protocol (IP protocol 51) carrying integrity without encryption; UDP 4500 does not replace it but encapsulates ESP in UDP to survive NAT. It is tempting because NAT-T does alter protocol handling, and would be relevant if the design required AH-style authentication without confidentiality.

To manage Phase 1 re-keying

Why it fails: Phase 1 re-keying runs inside the established IKE SA over UDP 500 or 4500; the 4500 port's defining role is encapsulating ESP packets so NAT devices can translate them. It is tempting because IKE negotiations do traverse 4500 once NAT is detected, and would be correct if the question asked which port carries IKE after NAT-T negotiation.

To verify certificate revocation status

Why it fails: Certificate revocation checking uses CRL or OCSP over HTTP, LDAP or OCSP ports, not UDP 4500, which exists to encapsulate ESP for NAT traversal. It is tempting because certificates are validated during Phase 1, and would be correct if the question concerned PKI validation rather than port function.

Antivirus profile

Why it fails: Antivirus profiles scan file transfers for malware signatures and do not evaluate web categories or URL reputation. Antivirus is the correct control when blocking malicious file downloads over allowed traffic, rather than preventing the initial connection to a malicious site.

Application Control

Why it fails: Application Control classifies traffic by application signature, not by URL category or reputation, so it cannot block sites using real-time threat intelligence. It is correct when enforcing policy on applications such as peer-to-peer or remote-access tools regardless of destination.

DNS Filter

Why it fails: DNS Filter resolves domain queries against FortiGuard categories and botnet lists, so it cannot inspect the URL path or payload of a request to a compromised legitimate site. It is tempting because it blocks known-malicious domains cheaply, and would be correct if the requirement were category-based domain blocking rather than real-time URL threat intelligence.