VPN configuration becomes much easier when it is treated as routing, identity, cryptography, and policy working together. The Fortinet NSE4_FGT_AD-7.6 exam expects administrators to understand how FortiGate uses IPsec for secure network-layer tunnels and how SSL VPN can provide remote-access connectivity through web or tunnel modes.
IPsec commonly connects sites, cloud networks, and remote users with encrypted tunnels at the network layer. SSL VPN is oriented toward remote access and can expose selected web resources or provide a client tunnel, depending on the design. The right choice depends on the endpoint, application, routing requirements, authentication model, and operational constraints—not simply on which wizard is easier to complete.
For a broader protocol foundation, the site’s explanation of IPsec site-to-site VPN tunnels complements the FortiGate-specific behavior covered here.
IPsec creates a protected network-layer path
IPsec protects IP traffic by establishing security associations that define peers, cryptographic parameters, and the traffic that should be carried through the tunnel. FortiGate deployments often use route-based VPNs so the tunnel appears as a logical interface that can participate in routing and firewall policy.
Thinking of the tunnel as an interface is useful because it separates tunnel establishment from traffic authorization. The VPN can be up while no user traffic passes because a route is missing, a firewall policy is absent, or the wrong prefixes are being selected. Conversely, routing can point toward a tunnel that is not successfully negotiated.
A complete design therefore asks four independent questions: can the peers establish IKE, can the IPsec security associations form, is the destination routed into the tunnel, and do firewall policies allow traffic across the tunnel interface?
Phase 1 and Phase 2 solve different problems
In common FortiGate terminology, Phase 1 establishes the secure relationship between peers using IKE. It includes peer identification, authentication, encryption and integrity choices, and other parameters required to create the IKE security association. Both sides must have compatible settings.
Phase 2 defines the IPsec security associations that protect actual data traffic. Traffic selectors or network definitions determine which traffic is eligible, and the peers must agree on compatible cryptographic proposals. A Phase 1 that is up does not prove Phase 2 is correct.
This distinction is essential during troubleshooting. If IKE never establishes, inspect peer reachability, UDP ports, NAT traversal, identities, authentication, and Phase 1 proposals. If Phase 1 succeeds but user traffic fails, move to Phase 2 selectors, routes, policies, and return-path behavior.
Routing determines whether traffic enters the tunnel
Route-based IPsec depends on the routing table. A destination prefix must point toward the appropriate tunnel interface or be learned through a routing protocol over the tunnel. If a more specific route points elsewhere, the packet will not enter the VPN even when the VPN status appears healthy.
Dynamic routing can be used across suitable VPN designs to improve scale and convergence. Static routes remain common for smaller deployments. Whatever the method, avoid overlapping addressing unless the design explicitly handles it, because ambiguous or conflicting prefixes make both routing and security policy harder to reason about.
Return routing is just as important. A site-to-site tunnel is bidirectional, and the remote network must know how to send the response back through the correct path. Many apparent firewall problems are actually asymmetric routing problems.
Firewall policies authorize VPN traffic
FortiGate requires policy for traffic crossing between interfaces, including VPN interfaces. Site-to-site designs typically need policies that permit the required source networks, destination networks, and services in the appropriate direction. Avoid broad any-to-any rules when the business requirement is narrower.
NAT is usually not required between private networks in a conventional site-to-site VPN, but there are exceptions such as overlapping address spaces or third-party requirements. If NAT is used, document it clearly because the translated identity affects routing, logging, and the remote peer’s policy.
Security profiles may be attached to VPN traffic when inspection is required. That adds protection but also changes performance and troubleshooting. First prove that the tunnel, route, and policy work; then isolate any inspection-related issue.
SSL VPN is built around remote user access
FortiGate SSL VPN can provide web mode for selected browser-accessible resources or tunnel mode for broader network access through a client. Authentication and authorization are therefore central to the design. The user’s identity, group membership, portal assignment, and accessible networks should all align.
Split tunneling determines whether only corporate destinations use the VPN or whether all client traffic is sent through the organization. Split tunneling can reduce bandwidth and preserve direct internet access, while full tunneling gives the organization more control over user traffic. The choice is a security and operations decision, not merely a performance setting.
Address pools for remote clients must not conflict with protected networks. DNS behavior should also be intentional so internal names resolve correctly when the user is connected. A tunnel that establishes but cannot resolve internal services may look like a routing failure when the actual problem is DNS.
Certificates and identity reduce avoidable trust problems
VPNs rely on authentication as well as encryption. Pre-shared keys can be appropriate in some site-to-site scenarios, while certificates provide stronger identity and scale in others. Remote access may integrate with local users, LDAP, RADIUS, MFA, or other identity systems depending on the environment.
Certificate validation failures can result from expired certificates, hostname mismatch, untrusted issuers, incomplete chains, or incorrect system time. These problems often appear during an outage after the underlying network has not changed at all. Certificate lifecycle therefore deserves the same operational attention as firewall rules and routing.
Least privilege should guide remote-access authorization. Successfully authenticating to the VPN should not imply access to every internal subnet. User groups and policy should expose only what the role needs.
IPsec and SSL VPN fail in recognizable patterns
For IPsec, separate peer establishment from protected traffic. Confirm internet reachability, IKE negotiation, Phase 2 state, routes, firewall policy, selectors, and return path. For SSL VPN, separate authentication from network access. Confirm the user can authenticate, receives the expected portal or tunnel settings, obtains a valid client address, resolves names, and has policy to the destination.
Packet capture and VPN diagnostics are especially valuable because they show whether negotiation packets leave and return. If IKE requests leave with no response, the issue may be upstream or remote. If the tunnel is established and encrypted packets move but the application fails, inspect inner routing and policy rather than changing cryptographic proposals.
This evidence-first sequence prevents endless trial-and-error changes that can make two peers less compatible with every attempt.
Choose VPN technology from the workload
Site-to-site network integration, dynamic routing, and stable infrastructure links often point toward IPsec. Remote users who need controlled access from varied locations may fit SSL VPN or remote-access IPsec depending on endpoint strategy and organizational standards. There is no universal answer that ignores identity, routing, scale, and supportability.
For certification preparation, practice drawing the packet path from client to protected service and back. Mark the encryption boundary, tunnel interface, route, firewall policy, identity decision, and any NAT. If you can explain each step, most VPN scenarios become structured troubleshooting rather than memorization.
That operational reasoning is the real objective: know what a healthy tunnel proves, what it does not prove, and which layer to examine next.
Remote-access design must account for endpoint posture
A remote-access tunnel extends enterprise reachability onto a device that may be outside the physical perimeter. That makes endpoint security, client version, certificate trust, operating-system support, and multifactor authentication part of the VPN architecture. Granting network access to an unmanaged endpoint can undermine the segmentation that the firewall otherwise enforces.
Access should therefore be aligned with identity and role. Contractors, administrators, and general employees may need different portals, address pools, destinations, or authentication requirements. The same user may also need different access when connecting from a managed corporate device versus an unmanaged personal system, depending on organizational tooling and policy.
Operational change control matters for VPNs
VPN changes affect both ends of a dependency. Changing an IKE proposal, certificate, peer address, routing advertisement, or authentication source can cause an outage even when the FortiGate configuration itself is syntactically valid. Coordinate changes with the remote peer or client population, define rollback, and preserve the old working parameters until the new tunnel is verified.
Fortinet certifications span different security and operations responsibilities, yet IPsec and SSL VPN troubleshooting share one useful habit: isolate negotiation, routing, authorization and endpoint behavior. A change that fixes one phase can conceal a different failure if the workflow is tested only end to end.
Document tunnel dependencies before an incident
Every production VPN should have a concise record of peer addresses, authentication method, protected networks, routing method, certificate ownership, expected proposals, monitoring, and business owner. That information shortens outages because the responder can compare live state with the intended design instead of reverse-engineering the tunnel under pressure.
Dependencies outside FortiGate should be included as well: upstream NAT devices, ISP paths, DNS names, identity providers, certificate authorities, and remote administrators. A tunnel may fail because any one of those components changed. Good documentation does not replace diagnostics, but it tells the engineer which assumptions are worth testing first.