CCNA Advanced VPN and Zero Trust Questions

Dead Peer Detection sends periodic probes to the remote gateway and, when replies stop arriving, declares the peer dead and tears down the security association. This detects loss of connectivity to the remote VPN peer so traffic can fail over or renegotiate.

Phase 2 selectors define the traffic that is allowed through the tunnel. To restrict the VPN to specific subnets, the administrator must configure the local and remote subnets in the phase 2 selectors. This ensures that only traffic between those subnets is encrypted and sent through the tunnel. Without this, the tunnel might use 0.0.0.0/0, allowing all traffic. Thus, this is required to meet the goal of restricted selectors.

A DLP profile inspects file content traversing the ZTNA inline CASB proxy, matching patterns such as credit card numbers and blocking the upload action. This directly satisfies the requirement to prevent sensitive data exfiltration to the SaaS application, which URL filtering or application control cannot achieve.

In FortiOS, PFS is enabled in the phase2 proposal by setting 'pfs enable'. This ensures that a new Diffie-Hellman exchange occurs for each phase2 rekey, providing perfect forward secrecy. Without this, the tunnel would not use PFS, and the requirement would not be met. This command is specific to phase2 and is the correct way to enable PFS.

ZTNA proxy in FortiOS lets the FortiGate broker client-initiated connections to internal applications, enforcing user identity via Microsoft Entra ID and device posture checks before granting access. This satisfies the stem's constraint of no VPN client, unlike IPsec or SSL VPN tunnels that require client software.

The FortiGate must have the FortiClient EMS fabric connector configured so it can query EMS for endpoint tags, and the firewall or ZTNA policies must reference those EMS tag objects as match criteria. Without the connector, tags are not resolvable; without policy references, tags do not gate traffic. Together they enforce compliant-only access while a separate policy can permit remediation traffic.

In ADVPN, the hub sends a shortcut offer to the originating spoke when it detects traffic destined for another spoke. The originating spoke then attempts to establish a direct tunnel to the destination spoke. For this to succeed, the spoke must have a route to the destination spoke's public IP address, which is typically learned via the hub or through the underlay network. This allows spoke-to-spoke traffic to bypass the hub.

Tags originate from FortiClient EMS, so the FortiGate cannot receive them without the EMS connector configured under Security Fabric > External Connectors. Without that connector, the ZTNA log shows no tag, blocking the compliant user.

DPD 'dead' means the FortiGate sent dead peer detection probes and received no response within the configured retry interval, so the peer is treated as unreachable and the tunnel torn down. This differs from an idle but responsive peer, which reports 'alive'.

ZTNA inline CASB uses security profiles, including DLP, to inspect traffic to SaaS applications. By attaching a DLP profile that detects and blocks sensitive data, the FortiGate can prevent uploads of such files. The ZTNA rule applies the inline CASB profile to the traffic, and the DLP profile enforces the blocking action. This is the correct configuration to meet the requirement.

In tunnel mode, the SSL VPN client receives an IP address and routes traffic to internal resources. By creating firewall policies that match user groups and specific destination subnets, the administrator can enforce granular access control. Only users in the allowed groups can reach the defined resources, while others are denied.

Device posture checks in FortiClient EMS evaluate endpoint compliance conditions such as antivirus signature currency and disk encryption status. They produce the compliance result that ZTNA enforcement then uses to permit or deny access to the sensitive application.

ZTNA relies on tags from FortiClient EMS to enforce compliance. If the 'MFA' tag is not synchronized, the FortiGate will not see that the user has MFA enabled, and the ZTNA rule will deny access. The administrator should verify that the EMS connector is properly configured and that the tag is being synchronized. This is a common issue when the EMS integration is not fully functional or when the tag is not correctly assigned in EMS.

Signature (RSA) makes FortiGate verify the peer's certificate during IKEv2 phase 1, satisfying the requirement for certificate-based peer identity validation. The remote gateway proves possession of its private key by signing the IKEv2 exchange, and FortiGate validates that signature against a trusted CA certificate.

SSL inspection decrypts the TLS session so the CASB profile can inspect file payloads for credit card patterns before upload completes. Without decryption, the traffic is opaque and data-loss rules cannot match content. The ZTNA application binds the CASB profile to the SaaS destination, satisfying the inline blocking requirement.

Phase 2 selectors define which traffic is encrypted. If the local subnet on one peer does not correspond to the remote subnet on the other, the proposal does not match and Phase 2 fails. Aligning the selectors so each peer's local subnet equals the other's remote subnet resolves the mismatch and allows the child SA to establish.

A phase 2 mismatch prevents the IPsec SA from being negotiated, so Quick Mode fails while the IKE SA stays up. That matches the stem exactly: `diagnose vpn ike gateway list` shows an established IKE SA, but `diagnose vpn tunnel list` shows no IPsec SA entries. Phase 1 selectors and proposals are not the constraint here.

Shortcuts require BGP to advertise spoke routes across the ADVPN overlay; without it, the hub cannot signal peers to build direct tunnels, so no shortcut entries appear in the NP6 peercache. The stem's missing shortcut condition is therefore explained by absent BGP peering between spokes.

A compliance rule in FortiClient EMS queries the endpoint's antivirus signature version and flags non-compliant devices, satisfying the requirement that only endpoints with updated definitions reach the VPN. FortiClient EMS then shares this compliance status with FortiGate, which enforces it through the VPN portal's host-check policy.

LDAP against Active Directory preserves existing credentials, FortiToken adds the required 2FA, a public CA certificate prevents client warnings, and combining web mode with tunnel mode via FortiClient covers both web apps and legacy TCP traffic while split tunnelling keeps internal traffic encrypted.

Compliance tags originate from FortiClient EMS, so the FortiGate must first learn them. Adding EMS as a security fabric connector establishes that channel, allowing the FortiGate to receive endpoint compliance posture and populate ZTNA tags.

Client certificate authentication in a ZTNA proxy rule requires the client to present a valid certificate during the TLS handshake. The FortiGate validates the certificate against a configured CA and can enforce additional checks such as revocation status. This directly ensures that only users with a valid corporate PKI certificate are granted access, matching the scenario's requirement.

To achieve redundancy with automatic failover, you need separate phase 1 configurations for each peer. Using route-based VPNs (with tunnel interfaces) allows dynamic routing protocols like BGP or OSPF to detect failures and reconverge, or you can use link monitoring with static routes. This setup ensures that if one peer goes down, traffic is rerouted through the other. This is the standard method for IPsec VPN redundancy.

IPsec phase 2 requires both peers to agree on identical encryption and authentication algorithms, plus matching DH groups. A proposal mismatch means the two ends offer no common transform set, so the quick mode negotiation fails and the tunnel tears down, matching the repeated SA negotiation errors in the logs.

Web mode delivers SSL VPN access entirely through a browser, proxying internal web applications without any client installation. This directly satisfies the stem's constraint of portal-based access with no software deployment, unlike tunnel mode, which requires FortiClient or a comparable client to establish the virtual adapter.

ZTNA posture enforcement requires the access proxy policy to match on a device posture tag synchronized from FortiClient EMS. Without referencing the EMS-issued tag in the policy, the FortiGate cannot differentiate compliant from non-compliant endpoints, so all authenticated users are treated equally and the personal device is permitted despite failing posture.

To use ZTNA tags in firewall policies, you must create a dynamic firewall address that references the tag. This address object is then used as the source or destination in the policy. The FortiGate dynamically populates the address with IP addresses of endpoints that have the tag, as reported by FortiClient EMS. This is the standard method to enforce tag-based access.

When an IKE gateway is stuck in 'connecting', it often indicates a phase 1 proposal mismatch or other negotiation failure. Enabling IKE debug with 'diagnose debug application ike -1' provides detailed logs of the negotiation, including proposed and received proposals. This helps identify mismatched encryption, authentication, or DH group settings. Since the pre-shared key is confirmed correct, the next step is to examine the IKE negotiation details. This is the most effective troubleshooting action.

The FortiGate validates the peer certificate against a trusted CA. If the issuing CA is not imported or not referenced in the phase 1 peer authentication settings, the certificate exchange completes but validation fails. Importing the correct CA and selecting it for peer authentication is necessary for the tunnel to proceed past certificate validation.

Phase 2 selectors define which source and destination subnets each peer encrypts. If the local and remote proxy IDs configured on each FortiGate do not mirror the other side's, the quick-mode negotiation fails because no matching security association can be built for the traffic.

FortiGate validates the client certificate against its trusted CA store during ZTNA certificate authentication. If the issuing CA is absent, validation fails and the FortiGate falls back to prompting for credentials, explaining the repeated prompts users report despite correct certificate configuration.

The SP posts its SAML assertion to the ACS URL, so if that URL configured on the FortiGate IdP does not exactly match the SP's endpoint, authentication succeeds but the assertion is delivered nowhere valid, producing the SP error.

Phase 1 negotiates the IKE SA, which is UP, so peer identity and IKE proposals already match. Phase 2 builds the IPsec SA separately, so a DOWN IPsec SA with an UP IKE SA points to mismatched Phase 2 encryption, authentication, or proxy IDs between the peers.

In the phase 2 proposal, enabling PFS and selecting a DH group ensures that a new key exchange occurs for each phase 2 rekey, providing perfect forward secrecy. This setting must match on both peers. Without it, the tunnel uses the phase 1 keys, which reduces security.

The ZTNA access proxy terminates the user connection and establishes a separate connection to the application, so the application's real IP address and port are never exposed. It enforces policy per session, satisfying the requirement to hide the legacy application's network location.

ADVPN shortcut negotiation uses IKEv2 auto-discovery sender and receiver roles to exchange shortcut offers and replies between spokes, while NAT traversal keeps the IKE and ESP traffic flowing through intervening NAT devices. Together these allow spokes with dynamic, NATed addresses to learn each other's reachable endpoints and build direct tunnels, which is precisely what the design requires.

When the remote peer has a dynamic IP, setting the remote gateway to 0.0.0.0 allows the FortiGate to accept connections from any IP. The peer ID is used to authenticate the remote peer. This is the standard method for dynamic IP peers in IPsec VPN configurations on FortiGate.

SAML assertions must be digitally signed so the service provider can verify they genuinely originate from the FortiGate IdP. A signing certificate is therefore mandatory; without it, the SP rejects assertions and SSO fails during trust validation.

The tag alone enforces nothing; a ZTNA policy on the FortiGate must reference the 'Compliant' tag as a matching condition so posture status drives the allow or deny decision. Without this policy binding, the tag is merely reported by FortiClient EMS and never evaluated.

The EMS connector on the FortiGate only receives dynamic endpoint tags after the FortiGate is authorized on FortiClient EMS. Without this authorization, the FortiGate cannot learn which endpoints are compliant, so tag-based ZTNA policies would never match. Authorizing the FortiGate is therefore a prerequisite for enforcing posture-driven access decisions in this scenario.

The firewall policy is where authentication and posture enforcement are applied. By matching ZTNA traffic and referencing user groups plus FortiClient EMS tags, the policy ensures only authenticated and compliant devices are permitted. This is the enforcement point that ties identity and posture to access, which is central to the Zero Trust requirement.

A ZTNA proxy policy allows the administrator to combine user authentication (via SAML) and device posture checks (such as antivirus signature version). This policy enforces access based on both identity and device compliance, meeting the requirement. It is the core component for ZTNA access control.

The FortiGate ZTNA gateway terminates the client tunnel and enforces access policy per session, granting or denying each request to internal applications. It is the enforcement point, while the EMS or fabric connector supplies identity and posture context used in those decisions.

FortiClient EMS integrates with FortiGate to enforce ZTNA device compliance, checking endpoint posture such as antivirus status and management ownership before granting access. It satisfies the stem's constraint that only company-managed laptops with up-to-date antivirus reach the internal file server remotely, using endpoint telemetry tags rather than network location.

INITIAL_CONTACT is sent when an IKE peer starts without existing security associations, so repeated notifications mean the branch device or its VPN daemon is restarting, tearing down and renegotiating the tunnel. This directly explains the frequent outages observed on that branch VPN.

To enforce client certificates, the access proxy rule’s authentication configuration must explicitly require certificate authentication, typically by selecting the client certificate option and referencing the trusted CA. If only password authentication is enabled, users without certificates can still authenticate, so the certificate requirement is not enforced at the proxy.

ZTNA proxy policies on FortiGate can enforce device posture by referencing tags from FortiClient EMS. By configuring a proxy policy that includes a device posture check, the FortiGate verifies that the connecting device has the required EMS tag before granting access. This ensures that only compliant devices can reach the internal web applications, aligning with zero-trust principles.

DPD sends periodic encrypted probes (IKE notify payloads) to the peer; if no response arrives within the configured retry and idle intervals, FortiGate tears down the IPsec SA and routes traffic elsewhere, preventing black-holed packets over a silently failed peer.

A mismatch in phase1 encryption or integrity algorithms causes the responder to reject the initiator's proposal, producing the 'no acceptable proposal' error. IKEv2 requires both peers to agree on identical encryption and integrity algorithms during SA negotiation, so verifying these settings on both gateways resolves the failure.

For a route-based IPsec tunnel, the phase 2 selectors define the proxy IDs exchanged with the peer, while a static route directs matching traffic into the tunnel interface. Setting the local selector to 192.168.10.0/24 and the remote to 10.20.0.0/16 matches the cloud provider's requirement, and the route ensures only that destination is sent through the tunnel.

A 502 Bad Gateway means the FortiGate's ZTNA proxy could not establish a connection to the protected backend server. Authentication succeeded, so the failure lies upstream of the client, pointing to an unreachable or down backend.

A ZTNA proxy rule requires an application mapping object to define the protected application's FQDN, port, and certificate. Without that mapping, the rule has no target to proxy, so FortiGate rejects creation until the mapping is defined and referenced.

Endpoint compliance checks are evaluated by FortiClient EMS, which tags endpoints and signals the FortiGate ZTNA gateway; the gateway terminates sessions when a tag is revoked. Adjusting the compliance rules in EMS resolves the failing check that causes the recurring session teardown.

Acting as a SAML IdP requires a local user database to authenticate users against, plus the SAML IdP settings defining entity ID, endpoints and signing certificate. Both are prerequisites for issuing assertions to ZTNA service providers.

In ZTNA, device posture is enforced through ZTNA rules that reference EMS tags. The FortiGate retrieves tags from FortiClient EMS and uses them in the ZTNA rule to allow or deny access based on device compliance. This is the correct method to enforce EMS-based compliance for ZTNA.

In FortiGate ZTNA reverse-proxy mode, the access proxy rule defines the authentication and authorization conditions. If the rule does not explicitly require a client certificate, users without one can still pass if they meet other criteria. The administrator must edit the access proxy rule to require a valid client certificate. This is the most likely cause because the symptom is selective bypass of certificate enforcement while other authentication still works.

SAML SSO requires a user group configured with the SAML authentication method, plus an SSL VPN portal that references it. The group binds the IdP assertion to FortiGate policy, and the portal determines what authenticated users may access.

The access proxy terminates client TLS on 443 and forwards to the real service. Mapping external port 443 to destination 10.0.1.100 on port 8080 lets the ZTNA rule reach the internal application listening on 8080 while clients connect on the standard HTTPS port.

The log indicates the IKE SA negotiated selectors but no firewall policy permits that traffic. FortiGate requires an explicit policy matching source, destination and the VPN tunnel interface; without it, packets are dropped before entering the tunnel.

ZTNA tags with posture checks let FortiClient EMS evaluate endpoint antivirus and OS patch status, then assign tags that the access proxy rule matches. This enforces the stated requirement that only up-to-date devices reach the sensitive application.

If the ZTNA rule lacks a device posture check that references EMS tags, then tags are not enforced. The rule may allow access based solely on user authentication. This is the most likely cause because the FortiGate is connected to EMS and tags exist, but the rule is not configured to use them. This is the correct answer.

Setting the phase1 authentication method to 'signature' replaces pre-shared key authentication with digital certificate exchange, satisfying the requirement for PKI-based IKEv2 authentication. FortiGate then validates peer certificates against the configured CA, using RSA or ECDSA signatures during the IKEv2 exchange rather than a shared secret.