CCNA Advanced VPN and Zero Trust Questions

The ZTNA server on the FortiGate defines the access proxy that protects internal applications. It includes the virtual host name, the server certificate used for TLS, and the application mappings that specify which internal resources are published and how they are accessed. Authentication and authorization are enforced through the ZTNA policy that references the ZTNA server, ensuring users only reach authorized applications.

FortiGate is the ZTNA gateway.

NAC policies are the rule engine that evaluates a device's security posture and host attributes, then applies the matching VLAN assignment to the switch port or wireless SSID. This satisfies the requirement for dynamic, posture-based VLAN assignment rather than static port configuration.

The ZTNA proxy on the FortiGate terminates the HTTPS session and acts as a reverse proxy, inspecting and forwarding traffic to the internal application. This satisfies the requirement for brokered access without exposing the app directly.

ZTNA posture checks inspect endpoint attributes such as antivirus presence and signature currency, then apply tags to compliant devices. FortiGate enforces access policy against those tags, so only endpoints meeting the antivirus and up-to-date requirement reach the corporate network.

Firewall policies govern whether traffic is permitted through the tunnel; an established IPsec tunnel with no passing traffic typically indicates missing or misordered policies blocking the interesting traffic. FortiGate requires explicit policies permitting traffic between the VPN interfaces, so checking these first addresses the stem's constraint of a tunnel that is up but not forwarding data.

Authentication alone does not grant access; the ZTNA proxy rule matches on device tags, so a missing required tag causes the policy to deny the session despite FortiClient showing 'Connected'. Assigning the correct tag to the client restores the match and unblocks the application.

The ZTNA access proxy terminates the client tunnel and enforces authentication and posture checks before forwarding traffic to the protected application. It is the component that validates the user's identity and device compliance as part of the ZTNA server configuration. This directly performs the verification the administrator requires for access to the internal application.

FortiClient EMS is the management plane that issues and maintains endpoint ZTNA tags, and it synchronises those tags to the FortiGate. Without this server, the FortiGate access proxy has no authoritative source of device posture, so tag-based policy enforcement cannot occur.

Phase 2 handles child SA rekeying, so PFS is negotiated there. Enabling pfs plus dhgrp 14 forces a fresh Diffie-Hellman exchange using group 14 on each rekey, delivering the forward secrecy the administrator requires for the IPsec tunnel.

Certificate-based IPsec requires a local certificate whose subject or name matches the phase1 configuration. If it is absent from the FortiGate keystore, or its name differs from the one referenced in phase1, IKE cannot present a valid identity, producing the 'no suitable certificate found' error.

Reachability testing isolates transport-layer failures before deeper ZTNA inspection. Since FortiClient reports "Connection refused", the TCP handshake to the gateway's access port is likely failing — often due to routing, firewall policy, or an incorrect port. Confirming IP and port reachability satisfies the stem's requirement to diagnose connectivity before examining ZTNA tags or Microsoft Entra ID integration.

A host check policy evaluates the endpoint's compliance, including FortiClient EMS tags, during the SSL VPN connection handshake before the user is assigned an address from the pool. If the endpoint fails the check, the FortiGate can deny or restrict access immediately. This directly enforces the requirement that compliance be validated before tunnel access is granted.

FortiClient EMS compliance rules allow administrators to define endpoint posture requirements, such as up-to-date antivirus signatures, and enforce them. When integrated with FortiGate ZTNA, the FortiGate can query FortiClient EMS for device compliance status and grant or deny access based on those rules. This is the correct component for enforcing endpoint compliance in a ZTNA deployment.

ZTNA access proxy evaluates endpoint posture — OS version, antivirus state, disk encryption — before granting application access, enforcing zero-trust checks per session. It satisfies the granular, posture-based policy requirement that conventional firewall rules cannot express.

In an ADVPN hub-and-spoke topology, the hub must act as a BGP route reflector to propagate routes between spokes. By configuring the hub as a route reflector and the spokes as clients, the hub can reflect routes learned from one spoke to other spokes. This enables spoke-to-spoke communication over dynamic tunnels.

The 'diagnose wad debug enable category ztna' command enables debugging for ZTNA processing in the WAD daemon. It provides detailed logs about ZTNA rule matching, including source, destination, and user information. This is essential for troubleshooting why a ZTNA rule is not matching traffic. It shows the evaluation process and any errors.

When phase2 selectors are missing, it indicates that phase2 negotiation has not completed or failed. Enabling IKE debug with 'diagnose debug application ike -1' will show the detailed exchange, including proposals, selectors, and any error messages. This is the most effective way to identify why phase2 is not establishing, such as mismatched proposals or proxy IDs. The debug output will pinpoint the failure.

ZTNA policy matching depends on the tag names being identical between what FortiClient EMS sends and what the firewall policy references. If the tag is misspelled or not received, the policy will not match even if the device is compliant. Verifying tag reception and name matching is the most direct way to diagnose why compliant users are denied.

If the tag is not synchronized, the FortiGate will not see the device as compliant, even if it has the tag in EMS. This causes the ZTNA policy to deny access. Synchronization issues often stem from expired certificates or network problems.

DPD is the IPsec feature that detects when a peer becomes unreachable. When enabled, the FortiGate sends periodic probes or waits for idle traffic before probing. If the peer fails to respond, DPD marks the tunnel as down and triggers renegotiation or failover. Setting DPD mode to on-idle or always ensures detection occurs and the tunnel can be automatically re-established without manual intervention.

The proxy forwards successfully and the server replies, so the failure lies in the returned content: the application generates links or redirects referencing internal addresses that remote clients cannot resolve. That matches the blank page after delay despite a healthy ZTNA tunnel.

Setting authmethod to signature makes phase1 use X.509 certificates for peer authentication rather than a pre-shared key, satisfying the requirement to replace PSKs with PKI. FortiGate then validates the peer certificate against the configured local or CA certificate.

FortiGate must be configured as an EMS connector so it can poll FortiClient EMS and import the ZTNA tag. Without this connector, the firewall has no visibility of the 'AntiVirus enabled' tag, so the ZTNA rule cannot match device posture and enforcement fails.

Firewall policies are evaluated top-down, and the first matching policy is applied. If a broader deny or restrictive policy appears above the ZTNA tag-based policy and matches the user's source, destination, or service, the ZTNA policy is never reached. This is the most common reason a correctly tagged device still gets denied despite the EMS connector showing Connected and the tag being visible in inventory.

In IPsec VPN, phase2 selectors define the traffic that is allowed over the tunnel. If the local and remote subnets configured in phase2 do not match the actual source and destination addresses of the traffic, the FortiGate will not route that traffic into the tunnel. This is a common misconfiguration. Even if the tunnel is up, mismatched selectors will cause traffic to be dropped or sent unencrypted, depending on routing. The administrator should verify that the phase2 selectors exactly match the subnets defined in the firewall policies and address objects.

A ZTNA proxy destination matches the exact IP-and-port pair, so 10.0.10.100:443 covers only port 443. Traffic to 8443 and 9090 matches no rule and is dropped. Separate rules, or a destination covering all three ports, are required.

The FortiGate's ZTNA proxy terminates the client TLS session, performs SSL inspection, then opens a separate connection to the internal application server, forwarding the decrypted traffic onward. This satisfies the stem's requirement that traffic reaches the server after inspection, since the FortiGate itself acts as the forwarding proxy rather than an external access broker.

FortiClient performs the endpoint posture checks for disk encryption and OS patch level, then reports compliance to EMS. These checks generate the tags that the FortiGate evaluates, so FortiClient is essential to enforce the stated conditions.

ZTNA tag-based enforcement is implemented by referencing the ZTNA server in the policy and using the compliance tag as a matching condition. Only devices that have the tag will match the allow policy, and all others will fall through to the implicit deny. This directly enforces the requirement without needing a separate deny rule.

The phase2 selector 10.0.1.0/30 overlaps the tunnel interface subnet, so traffic sourced from 10.0.1.1 matches the encryption domain and is routed into the tunnel rather than reaching the remote gateway. FortiGate requires selectors distinct from the tunnel IP range to avoid this routing conflict.

To use EMS tags in ZTNA rules, FortiGate must be integrated with FortiClient EMS via a fabric connector. This allows FortiGate to receive dynamic tag information about endpoints. After synchronization, the EMS tags become available as source objects in ZTNA rules. This is the essential step to enforce compliance based on EMS tags.

The access proxy defines the protected internal application and terminates ZTNA traffic, enforcing certificate and posture checks before forwarding. Without this proxy rule on the FortiGate, no ZTNA policy can validate the user certificate and compliant antivirus required by the stem.

ADVPN shortcut negotiation relies on IKE and ESP packets reaching the spoke peers directly. When spokes are behind NAT, NAT-T must be enabled on every peer so that the traffic is encapsulated in UDP and the NAT devices can maintain the mappings. This allows the hub to relay the shortcut proposal and the spokes to establish the direct tunnel.

FortiNAC enforces access decisions at the network edge using device identity and posture assessment, satisfying the stem's requirement for network access control. It profiles endpoints, checks compliance, and dynamically assigns VLANs or blocks access, which is the primary function distinguishing it from firewalling or authentication alone.

Placing the non-compliant endpoint into a quarantine VLAN isolates it at layer 2, so it can reach only remediation resources and cannot route to production subnets. This directly satisfies the stem's requirement to quarantine any endpoint failing antivirus compliance, enforced by the FortiNAC policy action.

SAML assertions are signed by the IdP, so the FortiGate must hold and trust the IdP signing certificate to validate them. Without that certificate imported, signature validation fails, authentication never completes, and users are repeatedly redirected to the IdP login.

With both phases up and policies permitting traffic, the failure lies beyond IKE negotiation. FortiGate only forwards traffic into a tunnel when a route to the remote subnet points out the IPsec interface; without it, packets follow the default route instead. Verify the routing table for the correct static or dynamic route.

ZTNA tags carry the endpoint's compliance posture, including antivirus status, from FortiClient to the FortiGate. The access proxy then evaluates these tags in firewall policy, so only devices with current antivirus satisfy the stem's requirement to reach corporate resources.

X.509 certificate authentication validates the peer's certificate against a trusted CA, so only devices holding corporate-issued certificates complete IKE negotiation. This enforces the corporate-owned certificate constraint that preshared keys or plain user credentials cannot guarantee.

The phase 2 selector defines the interesting traffic for the IPsec SA. It specifies the local and remote subnet pairs that are permitted through the tunnel. If the selector does not match the peer's encryption domain, the tunnel may fail to establish or traffic may be dropped. Configuring the selector to match the peer's required subnets ensures only that traffic is encrypted and sent through the SA.

ZTNA tags from FortiClient EMS satisfy the antivirus-compliance constraint: FortiClient reports endpoint posture, including antivirus status and signature currency, to EMS, which maps compliant devices to dynamic tags. FortiGate ZTNA policies then permit access only to tagged devices, enforcing health checks before the sensitive application is reached.

Auto-discovery enabled confirms the gateway runs ADVPN hub behaviour: it exchanges shortcut offers and forwards spoke subnet routes so spokes can build direct tunnels. The two peers and two tunnels reflect the hub's multiple spoke connections.

A phase1 'up' but phase2 'down' means IKE SA negotiation succeeded, so the mismatch lies in the phase2 proposal parameters. FortiGate's phase2 selectors, encryption, authentication, and PFS settings must match the third-party peer exactly; any difference in these attributes prevents the IPsec SA from establishing.

ZTNA rules require every configured condition to match; the 'Compliant' ZTNA tag is mandatory alongside SAML authentication. With the device untagged, the rule does not match, so the FortiGate ZTNA proxy denies the user's access to the internal application.

Tunnel mode is mandatory because it encapsulates all traffic in the SSL VPN tunnel, giving the client a persistent virtual interface that survives underlying network changes. This satisfies the always-on requirement: when the user's physical link switches, the tunnel re-establishes automatically rather than dropping to split-tunnel behaviour.

FortiClient EMS supplies endpoint compliance telemetry — patch level and management status — to FortiNAC, which enforces the production VLAN policy through its device profiling and network access rules. Without EMS integration, FortiNAC cannot verify patch currency, so the corporate-managed, up-to-date constraint fails.

SAML authentication can succeed while authorisation fails: the ZTNA proxy rule matches on user group membership, so if the IdP-asserted group is absent from the rule's allowed group, access is denied. Checking group mapping first isolates this authorisation mismatch.

INVALID_KE_PAYLOAD is the standard IKE notification sent when the responder cannot accept the proposed Diffie-Hellman group, prompting the initiator to retry with another group. Repeated renegotiation every few minutes indicates the FortiGate keeps offering a group the third-party gateway rejects. Aligning the phase 1 DH group with the remote gateway's supported group resolves the mismatch and stabilizes the tunnel.

ZTNA access-proxy policies match on EMS connector tags that represent live endpoint posture, so each new proxy connection is evaluated against current compliance state. Binding the access-proxy policy to the EMS connector tag is what makes posture dynamic and per-connection, which is exactly the behaviour requested for protecting the internal web applications behind the ZTNA server.

GRE/IPsec encapsulation adds overhead, so large OSPF hello or DBD packets can exceed the path MTU. If fragmentation is blocked, DBD packets carrying the master/slave election data never arrive intact, leaving neighbours stuck in EXSTART despite the tunnel being up.

FortiClient tunnels application traffic to the FortiGate's access proxy, so the gateway and its access proxy rule must exist before FortiClient can forward anything. Without this rule, FortiClient has no ZTNA destination to send traffic to, and access control cannot be enforced.

Inline CASB enforcement occurs only when the CASB profile is referenced by the access proxy rule handling the SaaS traffic. Creating the profile without attaching it leaves inspection inactive, so uploads pass uninspected. Attaching the profile makes the DLP sensor evaluate the upload stream and block content matching the credit card pattern.

DPD sends periodic encrypted probes (R-U-THERE) through the tunnel and expects replies. When the remote FortiGate stops responding within the configured retry limits, the local FortiGate tears down the stale IKE SA and routes traffic through an alternate path, satisfying the requirement to detect an unreachable peer.

An overly aggressive DPD retry interval causes the FortiGate to declare the peer dead before replies arrive, tearing down the IKE SA and forcing renegotiation; the gateway cycles up then down, matching the observed flapping.

SSL VPN tunnel mode permits traffic only through firewall policies referencing the SSL VPN tunnel interface. Web access works because an existing policy allows HTTP/HTTPS, but ICMP echo has no matching policy, so pings are dropped. Adding an ICMP-accepting policy on that interface restores reachability.

The error means the FortiGate cannot build a chain to a trusted root for the peer's certificate. Importing the issuing CA certificate into the local store lets the FortiGate validate the peer's certificate chain, resolving the 'unable to get local issuer certificate' failure.

FortiGate ZTNA can use dynamic tags received from FortiClient EMS to enforce endpoint compliance. The ZTNA policy can match on these tags, ensuring only compliant devices access the protected resource. This is the correct method for integrating EMS compliance checks into ZTNA access decisions.

ZTNA tags with device posture checks have FortiClient EMS inspect the endpoint and assign a tag only when antivirus is installed and running. The access proxy rule then matches that tag, satisfying the requirement that only protected devices reach the application.

A ZTNA tag is a dynamic attribute, typically populated by FortiClient EMS, describing device compliance and posture. FortiGate ZTNA rules match these tags to decide whether a device is permitted, enforcing zero-trust access based on verified device state rather than network location.

The internal hosts must know how to reach the VPN client subnet. Without a return route pointing back to the VPN IP pool, replies are dropped or sent to the default gateway, so traffic never returns to the tunnel.

ADVPN with IKEv2 lets spokes establish on-demand shortcuts directly between themselves, bypassing the hub for spoke-to-spoke traffic. The hub still handles initial route exchange, but once traffic flows, spokes negotiate a direct tunnel, satisfying the requirement to avoid hub routing while retaining centralised policy control.

NAT traversal (NAT-T) encapsulates IPsec packets in UDP to allow them to pass through NAT devices. The keepalive frequency setting sends periodic keepalive packets to maintain the NAT mapping and prevent the NAT session from timing out. This is crucial for reliability when a peer is behind NAT, as it keeps the UDP port open and avoids intermittent failures due to NAT session expiration.

To enforce EMS group membership, the FortiGate must have a user group that corresponds to the Finance group in EMS. This is typically done by creating a user group and selecting the EMS connector as the source, then specifying the Finance group. The ZTNA rule then references this user group as a source condition. This ensures that only users in the Finance group can access the application. This is the required configuration.

The ZTNA proxy rule defines the destination IP and port used when forwarding the client's request to the internal application. If these are wrong, the FortiGate accepts the session but forwards it to an unreachable or incorrect server, so traffic never arrives.

The access rule must include a condition matching the specific ZTNA tag so FortiGate only admits devices carrying that EMS-assigned attribute. Without this tag condition, the rule cannot distinguish compliant devices from others, defeating the zero-trust requirement.

Integrating FortiClient EMS allows the FortiGate to receive device posture tags, such as compliance status. These tags can then be used in firewall policies to enforce that only compliant devices access applications. Without this integration, the FortiGate cannot verify device posture, and ZTNA would not be able to enforce Zero Trust principles based on device health. This is a critical component for compliance enforcement.

IKEv2 negotiation events are only captured once the IKE log filter is applied and debug output is active; without enabling IKE debugging, 'diagnose vpn ike log-filter' produces no output, so the tunnel's failure remains invisible.

When the remote peer has a dynamic IP and is behind NAT, the FortiGate must listen on all interfaces (local gateway 0.0.0.0) and accept any remote gateway (remote gateway 0.0.0.0). The peer ID is then used to authenticate the remote peer by its FQDN, ensuring only that peer can connect. This is the correct configuration for dynamic IP with peer ID verification.

NAT-T encapsulates IKE and ESP in UDP (typically port 4500) so that NAT devices can translate the traffic and maintain state. When a peer is behind NAT, enabling NAT-T on the Phase 1 interface allows the tunnel to establish and rekey reliably, because the NAT device can track the UDP flow. Without NAT-T, ESP packets may be dropped or mishandled, causing rekey failures.

ZTNA access proxy rules forward traffic to the real application using the configured destination IP and port. If these are wrong, the FortiGate cannot reach the backend service, so users fail to connect even though the policy matches and the application is otherwise reachable.

ZTNA on FortiGate requires the access proxy, configured via the ZTNA proxy settings, to intercept and broker user traffic to the internal web application. This proxy enforces the zero-trust policy, verifying identity and posture before granting access rather than relying on network location.

A dynamic phase 1 with remote-gw 0.0.0.0 lets the hub accept connections from any spoke IP, satisfying the requirement for multiple spokes with dynamic addresses on a single interface. Static remote-gw would permit only one peer.

The ZTNA proxy on FortiGate terminates user connections and initiates separate sessions to the protected server, so users never reach 10.1.1.100 directly. This intermediary role satisfies the Zero Trust requirement of brokering access to the internal application.