FortiGate IPsec VPN setup for remote users (FortiClient)

This guide walks through building a remote‑access IPsec VPN on a FortiGate firewall for users connecting with FortiClient. We’ll go from user creation, to tunnel setup, to firewall policies, to client config — with explanations at each step so readers understand why they’re doing what they’re doing, not just what to click.

Step 1: Create VPN users and group

Before you build the VPN tunnel, you need user identities that FortiGate can authenticate.

1.1 Create a VPN user

Where: User & Device → User Definition → Create New

What to do:

• Type: Local user
• Username: something like vpn.john
• Password: strong, non‑reused password

Why this matters: FortiGate needs an account to validate when FortiClient connects. In production, this might come from LDAP/AD, but local users are perfect for labs or small environments.

1.2 Create a VPN user group

Where: User & Device → User Groups → Create New

What to do:

• Group Name: e.g., VPN-RemoteUsers
• Members: Add your VPN user(s), such as vpn.john

Why this matters: Policies and VPN configurations usually reference groups, not individual users. This makes it easy to onboard/offboard users by simply adding/removing them from the group later.

Good practice: Create dedicated groups like:

• VPN-Admins
• VPN-Staff
• VPN-Contractors

and treat permissions differently if needed.

Step 2: Launch IPsec VPN wizard

Now you’ll create the actual remote‑access IPsec tunnel.

2.1 Start the IPsec wizard

Where: VPN → IPsec Wizard → Create New

What to choose:

• VPN Type: Remote Access

This tells FortiGate that clients (FortiClient) will connect from the outside, not site‑to‑site.

2.2 Basic tunnel parameters

• Name: e.g., RA-VPN-FortiClient
• Interface: Your WAN interface, e.g., wan1

This is the interface that receives VPN traffic from the internet.

2.3 Authentication settings

• Authentication Method: Pre-shared Key
• Choose a strong, random key (store it securely)
• User Group: Select VPN-RemoteUsers (the group you created)

Why this matters:

• The pre‑shared key (PSK) is used by both the FortiGate and FortiClient to authenticate the tunnel.
• The user credentials (username/password) authenticate the user.
• The user group links your tunnel configuration to the users who are allowed to connect.

Step 3: Configure network settings

Here you define which internal networks VPN users can access and what IP addresses they’ll receive.

3.1 Local interface and subnet

In the wizard, you’ll see options like:

• Local Interface: Usually your internal side, but depending on FortiOS version this may show WAN in the wizard summary. Conceptually, the local side is the LAN/network behind the FortiGate.
• Local Subnet: The network you want users to reach, e.g.:
• 192.168.10.0/24 for a VLAN10/server network

Why this matters: This tells the VPN which internal network(s) will be reachable once connected.

3.2 Create a client address range (IP pool)

VPN clients must receive an IP from a pool that doesn’t overlap with existing networks.

Where to create the pool: Network → IP Pools → Create New

Example:

• Name: POOL-RA-VPN
• Range: 10.10.10.10 – 10.10.10.50

Then in the wizard or VPN settings, select this pool as the Client Address Range.

Why this matters:

• Keeps VPN client addresses separate and easy to identify in logs.
• Avoids IP conflicts with your internal subnets.

Tip: Use a completely different range (like 10.10.10.x) from your internal LANs (192.168.x.x) for clarity.

Step 4: Phase 1 & Phase 2 settings

This is where you define the cryptographic and negotiation parameters for the tunnel.

4.1 Phase 1 (IKE negotiation)

Key parameters:

• IKE Version: IKEv2 (recommended)
• Encryption/Authentication: AES256 / SHA256
• DH Group: 14 or higher (stronger key exchange)
• NAT Traversal: Enabled

What this does:

• Phase 1 establishes a secure control channel between FortiClient and FortiGate.
• IKEv2 is more modern, resilient, and handles network changes better than IKEv1.
• NAT Traversal helps if the client is behind NAT (which is almost always true for home/office users).

4.2 Phase 2 (data encryption)

Key parameters:

• Encryption/Authentication: AES256 / SHA256
• Perfect Forward Secrecy (PFS): Enabled
• Local Subnet: The internal network, e.g. 192.168.10.0/24 (VLAN10)
• Remote Subnet: The VPN client IP pool, e.g. 10.10.10.0/24 (if that’s how FortiOS represents it)

What this does:

• Phase 2 defines how actual user data (RDP, HTTP, SMB, etc.) is encrypted.
• PFS ensures session keys are not reused; if one key is compromised, past sessions stay safe.

Common pitfall: If the Local Subnet doesn’t match what your users need (e.g., you forget to include a specific VLAN), they won’t be able to reach those resources even though the VPN is “connected.”

Step 5: Firewall policies

Even with the tunnel up, FortiGate will block traffic by default unless you create the right policies.

5.1 Policy 1 — Allow VPN clients to access internal network (e.g., VLAN10)

Where: Policy & Objects → IPv4 Policy → Create New

Example configuration:

• Name: VPN-to-VLAN10
• Incoming Interface: IPsec tunnel interface (e.g., RA-VPN-FortiClient)
• Outgoing Interface: Internal VLAN interface (e.g., VLAN10)
• Source: POOL-RA-VPN (client IP pool) or VPN-RemoteUsers (depending on your design)
• Destination: 192.168.10.0/24 or specific server(s)
• Service: ALL (or restrict to RDP/HTTPS/etc. for tighter security)
• Action: ACCEPT
• NAT: Disabled (not needed for internal access)

Why this matters: This policy is what actually allows VPN clients to reach your internal network. Without it, the VPN connects, but traffic dies at the firewall.

5.2 Policy 2 — Allow VPN clients to access the internet (optional “full tunnel”)

If you want VPN users’ internet traffic to go through the FortiGate (e.g., for filtering/logging):

• Name: VPN-to-Internet
• Incoming Interface: IPsec tunnel interface (RA-VPN-FortiClient)
• Outgoing Interface: wan1
• Source: POOL-RA-VPN
• Destination: ALL
• Service: ALL (or restrict as needed)
• Action: ACCEPT
• NAT: Enabled

Why this matters:

• This turns your VPN into a full‑tunnel setup.
• All client traffic (including web browsing) goes to FortiGate first, then to the internet.

If you do not want this (you prefer split tunnel), you can skip this policy and configure split tunneling in Phase 2 instead.

Step 6: Configure FortiClient (remote user device)

Now you configure the client so it knows where and how to connect.

6.1 Install FortiClient VPN

• Download the VPN‑only version from Fortinet’s site (no need for full endpoint suite in labs).
• Install on Windows/macOS as usual.

6.2 Create a new IPsec VPN connection

In FortiClient:

1. Go to Remote Access
2. Click Add a new connection (IPsec)

Typical settings:

• Connection Name: Office VPN or Lab VPN
• Remote Gateway: Public IP or FQDN of your FortiGate WAN
• Example: 203.0.113.50 or vpn.example.com
• Pre‑shared Key: Same PSK you configured in Phase 1
• Username/Password: The VPN user created earlier (e.g., vpn.john)

Save the profile so users can connect with one click.

Step 7: Test connectivity

Once everything is in place, verify that the VPN isn’t just connecting, but actually passing traffic.

7.1 Connect via FortiClient

• Click Connect on the profile.
• Make sure the status shows Connected and an IP address from your pool (e.g., 10.10.10.10).

7.2 Test internal access

From the VPN client:

• Ping a server in 192.168.10.0/24 (or your internal range)
• Try RDP, SSH, or opening a web app hosted in that network

If it works, Phase 2 + firewall policy are correct.

7.3 Check logs if something fails

On FortiGate:

• Go to Log & Report → VPN Events
• Also check Forward Traffic logs to see if traffic is being dropped by a policy

Why this matters: Logs tell you whether:

• The tunnel is failing to negotiate (Phase 1/2 issue)
• Traffic is hitting a deny policy
• The wrong subnet or IP pool is being used

Step 8: Split tunnel vs full tunnel

This is about how much traffic goes through the VPN.

8.1 Split tunnel

• Only traffic destined for specific internal networks (e.g., 192.168.10.0/24) goes through the VPN.
• All other traffic (e.g., YouTube, general browsing) uses the user’s local ISP.

Where to configure:

• In the IPsec Phase 2 settings, enable Split Tunnel
• Accessible Networks: add only the internal networks you want, e.g. 192.168.10.0/24

Pros:

• Less load on your FortiGate and WAN
• Better performance for users’ general internet browsing

Cons:

• Internet traffic is not inspected by FortiGate

8.2 Full tunnel

• All traffic from the VPN client goes through the FortiGate.
• Requires:
• Phase 2 to include 0.0.0.0/0 or appropriate settings
• A VPN‑to‑Internet policy with NAT enabled (like Policy 2 earlier)

Pros:

• Centralized control and logging
• Apply web filtering, security profiles, etc.

Cons:

• More bandwidth usage on your WAN
• Users’ internet performance depends on your FortiGate and upstream link

Ah — great catch, Ernest. Your FortiGate VPN article absolutely deserves a Learnings section and a Conclusion to match the structure and polish of your other Medium guides. Here are both sections written in the same tone and style as your previous articles, ready to drop into the end of the piece.

Learnings

Setting up an IPsec VPN on a FortiGate isn’t just about clicking through a wizard — it’s about understanding how each component works together. Here are the key takeaways from this configuration:

1. User identity drives access control

Creating users and grouping them properly ensures you can scale access cleanly. Policies become easier to manage when tied to groups instead of individual accounts.

2. IP pools and internal subnets must be planned intentionally

A dedicated VPN IP pool prevents conflicts and makes troubleshooting far easier. Matching the correct internal subnets in Phase 2 is essential for routing to work.

3. Phase 1 and Phase 2 settings define tunnel stability and security

IKEv2, AES256, SHA256, DH14, and PFS aren’t just “recommended defaults” — they directly impact tunnel reliability, negotiation speed, and cryptographic strength.

4. Firewall policies decide what VPN users can actually reach

Even if the tunnel is “up,” nothing works until the correct policies are in place. This is the most common point of failure for new admins.

5. Split tunnel vs full tunnel changes the user experience

Split tunnel gives users speed and convenience. Full tunnel gives you control and visibility. Choosing the right one depends on your environment’s security posture.

6. Logs are your best friend

FortiGate’s VPN logs and forward traffic logs tell you exactly where a failure is happening — negotiation, authentication, routing, or policy.

Conclusion

Building a remote‑access IPsec VPN on a FortiGate is a powerful way to give users secure access to internal resources from anywhere. Once you understand how users, groups, IP pools, Phase 1/2 settings, and firewall policies fit together, the entire process becomes predictable and repeatable.

Whether you’re supporting remote staff, connecting to your homelab, or building a production‑grade VPN environment, this setup gives you:

• Strong encryption
• Reliable connectivity
• Granular access control
• Flexible split/full tunnel options
• Clear logging for troubleshooting

With this foundation in place, you can expand the design further — adding MFA, integrating with Active Directory, or building role‑based access policies.