Advanced VPN and Zero Trust practice questions

FortiAnalyzer

Why it fails: FortiAnalyzer is for logging and reporting, not enforcement.

FortiAuthenticator

Why it fails: FortiAuthenticator handles authentication, not endpoint compliance.

FortiGate ZTNA gateway

Why it fails: The ZTNA gateway enforces access based on tags, but tags are generated by EMS.

The internal application is not responding to the proxy request.

Why it fails: The log indicates timeout, not application unavailability.

The internal application has a 5-second timeout.

Why it fails: The log refers to ZTNA session timeout, not application timeout.

The client's FortiClient is not receiving the ZTNA tags.

Why it fails: The client can access the gateway, so tags are likely received.

SSL VPN with ZTNA

Why it fails: SSL VPN also requires rule changes.

IPsec VPN with ZTNA

Why it fails: IPsec VPN requires additional rules for VPN traffic.

Both proxy-based and IPsec VPN

Why it fails: Both would require more changes than proxy alone.

SNMP

Why it fails: SNMP is not used for tag delivery.

DHCP options

Why it fails: DHCP does not support ZTNA tags.

LDAP authentication

Why it fails: LDAP is a directory, not an authentication method per se; it can be used as a backend but the method is typically certificate or SAML.

FortiToken

Why it fails: FortiToken supplies one-time passcodes as a second factor, so it cannot authenticate users on its own; it requires a primary credential source such as FortiAuthenticator or Microsoft Entra ID. It is tempting because FortiToken is genuinely used in ZTNA deployments, but only for MFA, not as the initial user authentication method.

IPsec authentication

Why it fails: IPsec authentication secures the tunnel between endpoints and authenticates devices, not the individual user identity that ZTNA requires. It is tempting because IPsec is a FortiGate authentication mechanism, but ZTNA user authentication needs certificate or SAML-based identity verification instead.

Enable Perfect Forward Secrecy (PFS)

Why it fails: PFS is a security feature for key material, not for dynamic peer support.

Enable NAT traversal

Why it fails: NAT traversal handles NAT devices between peers, not dynamic addressing; the dynamic gateway requires a dial-up or dynamic-DNS peer configuration. It is tempting because NAT-T is commonly enabled on IPsec tunnels, and it would be correct when a NAT device sits between the two gateways and ESP must be encapsulated in UDP.

Use certificate-based authentication

Why it fails: Certificate-based authentication does not solve the problem of a peer with a dynamic IP address, because it still requires the remote FortiGate to be identified by a fixed IP or FQDN in the phase1 configuration to establish the IKE session. It is tempting because certificates are commonly used to authenticate peers without pre-shared keys, and in a hub-and-spoke topology where both peers have static IPs, certificate-based authentication would be a valid choice for strong identity verification.

The user 'user1' does not exist

Why it fails: The user is configured locally.

The login-attempt-limit is too low

Why it fails: The auth_fail reason indicates the credentials or authentication method were rejected, not that too many attempts were made; a low login-attempt-limit would log a different failure reason. The login-attempt-limit setting is intended to block brute-force attacks by locking accounts after repeated bad passwords.

The encryption algorithm is set to low

Why it fails: Encryption algorithm strength governs how the TLS session is encrypted, not whether user credentials are accepted, so it cannot produce an auth_fail result. Setting a low encryption algorithm is relevant when legacy clients cannot negotiate a supported cipher during the TLS handshake.

Reduce the DPD retry interval to 3 seconds.

Why it fails: Shortening the DPD retry interval makes the FortiGate declare a peer dead sooner, tearing down and rebuilding the tunnel during transient loss and worsening instability. A short interval suits fast failure detection on reliable links, not a lossy path needing tolerance.

Increase the phase1 lifetime to 86400 seconds.

Why it fails: Extending the phase1 lifetime to 86400 seconds reduces rekey frequency, but rekeys are not the cause of intermittent loss and a very long lifetime delays recovery from stale SAs. Long lifetimes suit stable links where rekey overhead must be minimised, not lossy tunnels.

Change the IKE version to IKEv1.

Why it fails: Downgrading to IKEv1 removes IKEv2 features such as built-in DPD and MOBIKE, and does not address the packet loss itself. IKEv1 is chosen for interoperability with peers that cannot support IKEv2, not for improving tunnel stability on a lossy path.

The tunnel is vulnerable to a man-in-the-middle attack because the IPsec SAs are using the same encryption algorithm.

Why it fails: Matching encryption algorithms across SAs is normal IPsec behaviour, not a vulnerability; each direction negotiates its own SA with its own keys. It is tempting because identical algorithms sound like shared secrets, but confidentiality comes from distinct session keys. The output actually shows IKE statistics such as SA counts and rekey timers.

The tunnel configuration is incorrect because there are two IPsec SAs under one IKE SA.

Why it fails: Two IPsec SAs under one IKE SA is normal Phase 2 behaviour, not a misconfiguration; each direction or subnet pair creates its own IPsec SA. It tempts administrators who expect a strict one-to-one mapping between IKE and IPsec SAs, but multiple child SAs per parent are expected.

The tunnel is using two IKE SAs for redundancy.

Why it fails: FortiGate does not establish two IKE SAs for redundancy within a single tunnel; redundancy comes from separate dial-up tunnels or redundant interfaces. The stats output reflects Phase 1 and Phase 2 counts, so interpreting duplicate IKE SAs as a redundancy mechanism misreads the counter's meaning.

Configure an LDAP server to synchronize user accounts

Why it fails: LDAP is not required for RADIUS authentication.

Configure an SSL VPN portal with 'Require Authentication' enabled

Why it fails: Portal settings don't specify the authentication method.

Set a local password policy for SSL VPN users

Why it fails: Password policy is not required; RADIUS handles passwords.

Phase 2 proposal (aes256-sha1) is not compatible with Phase 1 proposal (aes256-sha256)

Why it fails: This is incorrect. FortiGate does not require authentication algorithms to match between Phase 1 and Phase 2. The tunnel can establish with different algorithms for each phase.

The pre-shared key is encrypted in the configuration

Why it fails: This is incorrect. The pre-shared key is stored encrypted in the configuration, but FortiGate decrypts it when needed; encryption does not prevent tunnel establishment.

The 'net-device disable' setting prevents tunnel creation

Why it fails: This is incorrect. 'set net-device disable' is not a standard IPsec setting; it does not prevent tunnel creation in typical site-to-site VPNs.

SD-WAN Rule: Monitors link quality metrics (latency, jitter, packet loss) against thresholds.

Why it fails: This describes Performance SLA, not SD-WAN rule.

Performance SLA: Groups WAN interfaces into a logical bundle for load balancing.

Why it fails: This describes Virtual-WAN-Link, not Performance SLA.

Virtual-WAN-Link: Determines traffic steering based on criteria like source, destination, application.

Why it fails: This describes SD-WAN Rule, not Virtual-WAN-Link.

get system performance: Ping a network host

Why it fails: Incorrect — 'get system performance' does not ping; it shows performance stats.

execute ping: Display real-time system performance statistics

Why it fails: Incorrect — 'execute ping' does not show performance stats; it pings.

The spoke FortiGates are using main mode instead of aggressive mode for IKE phase 1

Why it fails: Incorrect. The scenario explicitly states that aggressive mode is configured, so spokes are not using main mode. The issue lies elsewhere.

The spoke FortiGates have 'set net-device disable' on the phase 1 interface

Why it fails: Incorrect. The 'set net-device disable' command affects the phase1 interface as a network interface but does not prevent shortcut tunnels from forming.

The hub FortiGate is not configured with 'set add-route enable' on the phase 1 interface

Why it fails: Incorrect. 'set add-route enable' adds routes for remote networks but is not the primary cause for shortcut tunnel failure. The fundamental issue is the use of IKEv1 instead of IKEv2.

The user's browser has cookies disabled

Why it fails: While cookies may be needed for session tracking, the redirect itself is handled by SAML protocol, not cookies.

The IdP certificate is not trusted by the FortiGate

Why it fails: This would cause a signature validation failure, not a redirect issue.

The FortiGate is configured as a SAML IdP instead of SP

Why it fails: If configured as IdP, FortiGate would not redirect to an external IdP.

The MTU on the VPN interface is too high

Why it fails: MTU too high can cause fragmentation but not specifically prevent Hello packet exchange; state would likely be EXSTART or EXCHANGE.

The IPsec phase 2 proposal does not include the OSPF multicast IP address (224.0.0.5)

Why it fails: Phase 2 selector missing multicast will block OSPF packets entirely, but this usually results in no neighbor adjacency at all (state Down), not INIT. INIT indicates Hello sent but not received.

The OSPF hello interval is too short

Why it fails: Hello interval mismatch would cause neighbor to fall out of sync, typically leading to EXSTART/EXCHANGE issues, not stuck in INIT.

IPsec interface mode with DHCP

Why it fails: DHCP is for obtaining IP addresses, not for failover.

IKEv2 with mobility extension

Why it fails: Mobility extension is for mobile IP changes, not for multi-ISP failover.

Auto-negotiate phase 1 settings

Why it fails: Auto-negotiation is for proposal matching, not failover.

The SAML single logout URL is misconfigured

Why it fails: Misconfigured SLO would affect logout, not login.

The SAML assertion is not signed

Why it fails: Unsigned assertions would cause authentication failures, not repeated prompts.

The FortiGate is not configured to generate a Name ID

Why it fails: Missing Name ID would cause assertion failure, not repeated prompts.

Set the phase 1 proposal to use AES-256-GCM only

Why it fails: Any valid proposal works; specific encryption is not mandatory.

Enable DPD on the phase 1 interface

Why it fails: DPD is optional for tunnel maintenance, not required for establishment.

Configure the phase 2 selector to include all traffic (0.0.0.0/0)

Why it fails: Phase 2 selectors define interesting traffic, not required for phase 1 establishment.

The VPN interface must be configured with 'set acceleration-mode ipsec'

Why it fails: Acceleration mode is automatically enabled; no manual setting required.

The firewall policy using the VPN interface must not have NAT enabled

Why it fails: NAT does not disable hardware acceleration for IPsec.