CCNA Advanced VPN and Zero Trust Questions

SAML SSO requires the FortiGate to have a certificate that the IdP trusts for signing assertions. Option D is correct because the FortiGate needs to import a CA-signed certificate (or use a self-signed) to sign SAML requests and also to establish the trust relationship with the IdP.

OSPF requires stable network types and correct interface configuration. For ADVPN, OSPF should use point-to-point network type to avoid DR elections and ensure proper neighbor relationships.

Phase 2 negotiation can also fail due to mismatched traffic selectors (local and remote subnets).

The SAML assertion consumer service (ACS) URL must exactly match the endpoint configured on the FortiGate. If the IdP's ACS URL lacks a trailing slash that the FortiGate expects, the SAML response will be sent to an incorrect or mismatched endpoint, causing the redirect to fail. This is a common misconfiguration in SAML SP setups where URL normalization differs between the SP and IdP.

In a Zero Trust Network Access (ZTNA) architecture, the FortiGate ZTNA gateway acts as the policy enforcement point (PEP). It terminates encrypted ZTNA tunnels from FortiClient agents, inspects traffic against configured access policies, and enforces decisions based on identity, device posture, and context. This is distinct from the control plane (FortiClient EMS) or logging (FortiAnalyzer).

FortiClient EMS (Endpoint Management Server) manages FortiClient endpoints and can enforce compliance policies. It integrates with FortiGate to provide device posture information via ZTNA tags, enabling access control based on compliance.

For ADVPN shortcuts to be established, three conditions must be met: (A) The spoke tunnel interfaces must be in the same IP subnet to allow direct routing. (D) Auto-discovery must be enabled in the phase1 settings on all spokes to exchange shortcut information. (E) The hub must have routes to all spoke local subnets so it can forward shortcut initiation packets. Option B is incorrect because spokes can have dynamic IP addresses with ADVPN. Option C is incorrect because 'set shortcuthub enable' is not required; the hub functions as a shortcut hub by default.

A ZTNA proxy requires a configured application mapping (defining the internal server) and a firewall policy that permits traffic from the ZTNA gateway to the internal server.

The 'diagnose vpn ike stats' output shows one IKE SA (phase 1) and two IPsec SAs (phase 2). This is normal for a single VPN tunnel when using IPsec with both inbound and outbound SAs, or when the tunnel is configured with separate SAs for different traffic selectors. The presence of two IPsec SAs under one IKE SA does not indicate an error or vulnerability; it is the expected behavior for a standard IPsec VPN tunnel.

Common certificate issues include: the certificate's Common Name (CN) does not match the peer's IP address, or the certificate has expired. Also, the certificate must have the 'IPsec tunnel' extended key usage (EKU) and the subject alternate name (SAN) must include the peer's IP.

INITIAL_CONTACT is a notify message sent by an IKE peer to indicate that it has rebooted or lost its state. When the remote peer sends this, it means the peer has restarted, causing the tunnel to re-establish. This is normal behavior after a reboot but if frequent, indicates instability at the remote end.

DPD sends keepalive messages to detect peer reachability. If the peer does not respond, the tunnel is marked down, allowing failover. Key renegotiation is handled by IKE lifetime settings, not DPD.

The ZTNA tag requires 'Antivirus = running', which means the FortiGate must receive a compliance report from the FortiClient EMS indicating that a supported antivirus is active. Symantec is not in FortiGate's supported antivirus list, so the EMS reports the antivirus status as 'not compliant', causing the ZTNA rule to deny access even though the user has antivirus running.

Shortcut tunnels require that the hub propagates routes without setting itself as next-hop (next-hop-self disabled), and that spokes have overlapping routing information so they know the other spoke's subnet via BGP. Options B and D are correct: BGP must be configured on all spokes to exchange routes, and the hub must not set next-hop-self so that the next-hop remains the remote spoke's tunnel IP.

The 'no acceptable proposal' error occurs when the two peers cannot agree on a set of parameters. Common causes are mismatched encryption/integrity algorithms (phase1 proposal) or mismatched Diffie-Hellman groups.

For shortcut tunnels to be established, the hub must have 'add-route' enabled so that it advertises routes to other spokes. Without this, spokes will not know how to reach each other directly and will continue to route through the hub.

FortiGate can act as an IdP by creating a SAML IdP user and configuring the service provider metadata.

A user group must be created to reference the RADIUS server as an authentication method. This group is then applied to the SSL VPN portal or firewall policy, allowing FortiGate to forward authentication requests to the RADIUS server. Without the user group, the RADIUS server cannot be associated with SSL VPN authentication.

The 502 Bad Gateway error indicates that the ZTNA proxy successfully received the request but could not get a valid response from the backend server. Therefore, the most likely cause is that the backend server is unreachable from the FortiGate (option A). The other options would result in different errors.

ADVPN requires policy-based routing or routing protocol to propagate routes and trigger shortcut setup. Without a routing protocol like BGP/OSPF, spokes will not learn routes to other spokes, and shortcut negotiation fails.

A ZTNA proxy rule maps an external FQDN/port to an internal application. The error means the application mapping (which defines the internal server) is missing or misconfigured.

The FortiGate logs explicitly indicate that the ZTNA session is being terminated due to an endpoint compliance check failure. This means the FortiGate is enforcing compliance rules defined in FortiClient EMS, and when the endpoint fails those checks (e.g., missing antivirus updates, firewall disabled), the session is dropped. Reviewing and adjusting the compliance rules in EMS allows the administrator to align the requirements with the actual endpoint posture or correct the misconfiguration causing the failure.

BGP routes must be allowed by a firewall policy on the loopback or interface used for BGP. Even if the VPN tunnel is up, BGP traffic (TCP port 179) may be blocked by the local-in policy or by the VPN interface's firewall policy if not explicitly allowed.

FortiGate can be a SAML IdP, providing authentication to service providers. It requires a configured user database (e.g., local users, LDAP) and a SAML IdP profile.

'No acceptable proposal' in IKEv2 phase1 indicates a mismatch in proposal parameters. Encryption algorithm mismatch (A) and authentication method mismatch (E: pre-shared key vs certificate) can both cause this error. Phase2 mismatches (B) occur later, not during initial exchange.

For SAML SSO on SSL VPN, you must configure a user group with SAML authentication, then assign an SSL VPN portal that uses that group. The FortiGate acts as SP. RADIUS/LDAP are not required.

When the IdP session timeout is shorter than the SP session timeout, the SP will consider the user's session expired and force re-authentication even though the FortiGate still has a valid local session. This mismatch causes the SP to initiate a new SAML authentication flow, prompting the user for credentials again. The SAML single logout URL (A) affects logout behavior, not re-authentication triggers, and an unsigned assertion (B) would cause a different error, not repeated credential prompts.

When DPD is disabled, the FortiGate does not send DPD probes to verify the remote peer's liveliness. Without DPD or any other keepalive mechanism (such as IKE keepalives, which are not used in standard IPsec VPNs), the tunnel will remain in the 'UP' state indefinitely even if the remote peer goes down. This means the tunnel will never detect peer failure, leading to blackholed traffic until the administrator manually intervenes or the tunnel is re-established by other means.

If users can authenticate at the IdP but not via FortiGate SP, the problem is likely that the FortiGate entity ID or ACS URL does not match what is registered at the IdP.

For ZTNA access proxy, the external port is the port clients connect to (typically 443 for HTTPS), and the mapped port is the internal server port (8080). The destination is the internal server IP. Therefore, option D is correct: external port 443, mapped port 8080, destination 10.0.1.100.

The error indicates that the IKE SA exists but no firewall policy matches the traffic to use the tunnel. The tunnel interface is likely configured but the policy to allow traffic through the tunnel is missing or incorrect.

ZTNA tags with posture checks allow the FortiGate to verify endpoint compliance (e.g., antivirus version, OS patch level) before granting access to a ZTNA-published application. The FortiGate collects posture data from the FortiClient endpoint and compares it against configured compliance rules; only devices that meet the requirements receive the appropriate ZTNA tag and are allowed through the ZTNA proxy.

DPD (Dead Peer Detection) with auto-negotiation allows the FortiGate to detect peer unreachability and automatically re-establish the tunnel using an alternate path if configured.