Authentication and VPN
Identity and tunnels
User authentication starts with user objects: local users, or remote servers referenced as LDAP, RADIUS, TACACS+, PKI or FSSO. Firewall policies match user groups, not individual users, and a policy with multiple groups matches if the user belongs to any of them. For LDAP, distinguish simple binding from regular binding (which performs a bind with the user's own credentials), and verify the server with diagnose test authserver ldap. Authentication timeout and captive-portal settings decide how long identity is remembered and how users are prompted.
IPsec site-to-site VPN has two negotiation stages. Phase 1 agrees on IKE version, remote gateway, authentication (PSK or certificate), and proposals (encryption, authentication algorithm, DH group). Phase 2 defines the IPsec proposals, PFS, and the selectors - the local and remote subnets. Selectors must mirror each other; a mismatch is a common reason the tunnel comes up but no traffic passes. A static route for the remote subnet pointing at the tunnel, plus a firewall policy pair, complete the picture. Dial-up tunnels add dynamic peers and mode-config address assignment.
SSL VPN uses a portal that offers web mode and/or tunnel mode; tunnel mode requires FortiClient and honours split-tunneling and route settings in the portal. Authentication rules are evaluated in order to choose the portal.
Rule of thumb: if phase 1 is down, look at PSK/certificate, IKE version and proposals; if phase 1 is up but traffic fails, look at phase 2 selectors, routes, and policies - in that order.