Three weeks ago, a client's FortiGate SSL VPN was brute-forced. The attacker tried 50,000 username/password combinations over 48 hours. FortiGuard blocked 49,997 of them. But those 3 that got through? They were valid credentials. The attacker was inside the network in minutes.
This is why SSL VPN deployment matters. Done right, it's a secure gateway for remote workers. Done wrong, it's an open door for attackers. Let's make sure yours is done right.
What is FortiGate SSL VPN?
FortiGate SSL VPN (also called FortiClient VPN or web-mode/full-mode VPN) creates an encrypted tunnel between remote users and your internal network. Users authenticate through the FortiGate, then access internal resources as if they were in the office.
There are two modes: web mode runs in a browser and works for basic applications. Full tunnel mode installs a client and routes all traffic through the VPN. Most enterprises use full tunnel mode for security.
Why SSL VPN Matters for Remote Work
Post-pandemic, 60% of our clients have hybrid workforces. SSL VPN is how they securely access internal resources. But here's the risk: every VPN endpoint is a potential attack vector.
The 2023 Citrix Bleed vulnerability affected thousands of SSL VPNs. FortiGate wasn't affected, but it shows why proper deployment, patching, and monitoring are critical.
How to Deploy FortiGate SSL VPN
Step 1: Enable the VPN Portal
Go to VPN > SSL-VPN Portals. Create a new portal or modify the default. Set the tunnel mode to 'Full Tunnel' for maximum security. Configure the IP address pool - we recommend a dedicated subnet like 10.212.0.0/22 that's separate from your internal networks.
Step 2: Configure SSL VPN Settings
Go to VPN > SSL-VPN Settings. Enable SSL-VPN on the WAN interface. Set the port (default 10443). Choose your server certificate - never use the self-signed default certificate for production. Upload a proper certificate from a trusted CA.
Step 3: Set Up Authentication
Go to User & Authentication > User Definition. Create local users or, better yet, integrate with your existing Active Directory or LDAP. We always recommend AD integration - it means one less password to manage.
Enable MFA (Multi-Factor Authentication). This is non-negotiable. Without MFA, your VPN is one password breach away from compromise. FortiGate supports FortiToken, Google Authenticator, and SMS-based MFA.
Step 4: Create SSL VPN Policies
Go to Policy & Objects > Firewall Policy. Create a policy that allows SSL-VPN-Web or SSL-VPN-Tunnel interface to access specific internal resources. Apply security profiles: antivirus, web filter, and IPS.
Key principle: least privilege. Remote users should only access what they need. A marketing person doesn't need access to the database server. A developer doesn't need access to the HR system.
Step 5: Split Tunneling Configuration
Split tunneling routes only corporate traffic through the VPN, while personal internet traffic goes directly. This reduces bandwidth usage and improves user experience.
In the portal configuration, set 'Routing Address' to your internal subnets. This tells the VPN client which traffic to tunnel and which to let through.
Best Practices
1. Use certificate-based authentication where possible. It's more secure than passwords and can't be brute-forced.
2. Set session timeouts. We configure 8-hour max sessions for regular users, 24 hours for IT staff.
3. Monitor VPN logs. FortiGate logs every connection attempt. Review these weekly for suspicious patterns.
4. Keep FortiGate firmware updated. SSL VPN vulnerabilities are patched regularly. Don't skip updates.
5. Use the SSL VPN wizard for initial setup, then fine-tune the configuration manually. The wizard handles certificate generation and basic policy creation.
Common Mistakes
Mistake 1: No MFA. This is the #1 SSL VPN vulnerability. Every year, we see breaches caused by VPN accounts without MFA. Enable it on day one.
Mistake 2: Overly permissive policies. Granting VPN users access to everything defeats the purpose of having a firewall. Use ACLs to restrict access by user group.
Mistake 3: Using the default certificate. Self-signed certificates trigger browser warnings and can't be verified. Always use a proper CA certificate.
Conclusion
FortiGate SSL VPN is a solid solution for remote access, but only if deployed with security in mind. Enable MFA, restrict access with policies, use proper certificates, and monitor logs. The setup takes a few hours; the peace of mind is worth it.
Next step: Check your current SSL VPN configuration. Do you have MFA enabled? Are policies restrictive? If not, fix those two things today.
Want to go deeper? Explore [Protect security services](/en/products/protect), [industry solutions](/en/solutions), or [get a security assessment](/en/contact).
FAQ
Q: How many concurrent SSL VPN users can FortiGate support? A: Depends on the model. A FortiGate 100F supports about 200 concurrent users. A 600E supports 1,000+.
Q: Is SSL VPN slower than IPsec? A: Slightly, because of the TLS overhead. For most users, the difference is negligible. SSL VPN's advantage is easier deployment through firewalls.
Q: Can I use SSL VPN with FortiClient? A: Yes. FortiClient is Fortinet's free VPN client. It supports both SSL VPN and IPsec and is available for Windows, Mac, iOS, and Android.
Q: Should I use split tunnel or full tunnel? A: Full tunnel is more secure (all traffic inspected). Split tunnel is more efficient (less bandwidth). Choose based on your security requirements.
Threat Landscape and Current Attack Vectors
Understanding the current threat landscape is essential for making informed security decisions. In 2025, the most common attack vectors include ransomware (up 150% from 2024), supply chain attacks (targeting software vendors and managed service providers), credential stuffing (exploiting password reuse across services), and zero-day exploits (targeting unpatched vulnerabilities).
According to the 2025 Verizon Data Breach Investigations Report, 68% of breaches involve a human element (phishing, stolen credentials, or errors). This means technology alone is not enough - you need people, processes, AND technology working together.
Implementation Roadmap
We recommend a phased approach to implementation. Phase 1 (Weeks 1-4): Assessment and design. Document current state, identify gaps, design target architecture. Phase 2 (Weeks 5-8): Deploy core components. Install and configure the primary solution in a test environment. Phase 3 (Weeks 9-12): Pilot testing. Deploy to 20-30% of users, collect feedback, refine configuration.
Phase 4 (Weeks 13-16): Full deployment. Roll out to remaining users with minimal disruption. Phase 5 (Weeks 17-20): Optimization. Fine-tune policies, optimize performance, and document procedures. This timeline works for most medium enterprises (200-500 users).
Compliance and Regulatory Considerations
If your organization is subject to regulatory requirements (PCI DSS, HIPAA, ISO 27001, GDPR), ensure your implementation addresses these requirements from the start. Retrofitting compliance is significantly more expensive than building it in. We recommend creating a compliance matrix that maps each regulatory requirement to specific technical controls.
Common compliance gaps we see: insufficient audit logging (PCI DSS requires 12 months of logs), missing encryption at rest (required by HIPAA and GDPR), inadequate access controls (required by ISO 27001), and missing incident response procedures (required by all frameworks).