VPN: IPsec and SSL
IPsec: the parameters must pair up
Phase 1 negotiates the IKE SA: IKE version, remote gateway type, main versus aggressive mode, encryption/integrity/DH proposals, authentication (PSK or certificate), and DPD. Phase 2 negotiates the IPsec SA: proposals, PFS group, and selectors (local/remote subnets). The single most common failure in questions is a proposal or PFS mismatch - both peers must agree, and "automatic" negotiation still cannot bridge a different PFS setting.
Deployment models: policy-based (two policies with mirrored source/destination address pairs, no tunnel interface) and route-based (a tunnel interface with a static route pointing into it and policies permitting the tunnel interface). Route-based is required for dynamic routing and dial-up hubs.
Dial-up hub trap: a static remote gateway needs a known peer IP; for dynamic peers use a dial-up phase 1 with IKEv2, or IKEv1 in aggressive mode when using a pre-shared key. NAT traversal is on by default; if a device in the path mangles the traffic, verify UDP 500/4500.
SSL VPN: portal, then policy
SSL VPN is configured as tunnel IP range + authentication + portal mapping, then permitted by a firewall policy whose incoming interface is ssl.root. Portals choose web or tunnel mode, define split tunneling (routing addresses), and usually add host checking. Traps: a user authenticating successfully but reaching nothing means the ssl.root policy or split-tunnel routes are wrong; groups must be mapped to a portal; deep-inspection or web-filter profiles on the SSL VPN policy break tunnel traffic if applied carelessly. Newer FortiOS releases have been trimming SSL VPN features in favour of IPsec and ZTNA - always confirm the version in the question.