Skip to main content
Dparaskevas
Visitor III
January 16, 2026
Question

Asking for best Practice for Migrating SSL VPN to IPsec Dial-Up

  • January 16, 2026
  • 1 reply
  • 2020 views

Hello everyone,

 

We are managing the infrastructure of several environments where a FortiGate firewall is in place. Currently, we are using SSL VPN to provide remote user access to internal networks.

As Fortinet is gradually deprecating SSL VPN, the time has come (perhaps later than ideal) to migrate this service to IPsec Dial-Up VPN. However, after multiple tests, I have not yet been able to clearly identify the best-practice approach for implementing this migration, especially in terms of access control logic. I would like to explain our current setup and the challenges we are facing.

Current SSL VPN Implementation

With SSL VPN, we are used to (and quite comfortable with) the following model:

  • A single SSL VPN tunnel (split-tunnel)

  • All users connect to this tunnel

  • Access to internal resources is controlled purely through firewall policies

  • Policies are based on user groups / users, allowing granular access per destination, service, or port

This model is clean, scalable, and easy to manage.

Challenge with IPsec Dial-Up VPN

I am unable to replicate this exact logic with IPsec Dial-Up VPN. The two possible approaches I have identified so far are the following (please note that I may not be entirely correct, and I am open to correction):

1) Multiple Dial-Up Tunnels per Destination

Create different Dial-Up IPsec tunnels depending on the destination network.

Example:

  • User 1 needs access to 10.10.1.0/24

  • User 2 needs access to 10.10.2.0/24

In this case:

  • Create one Dial-Up tunnel allowing access to 10.10.1.0/24

  • Create another Dial-Up tunnel allowing access to 10.10.2.0/24

  • Each user connects to the tunnel assigned to them

However, this approach becomes extremely difficult to scale, especially when dealing with many users, each requiring access to different destinations, ports, or services.

2) Single Dial-Up Tunnel with Per-User Assigned IP Addresses

All users connect to one IPsec Dial-Up tunnel, and each user is assigned a static IP address via the configuration. Firewall policies are then written using source IP addresses to control access.

While this approach is closer to what we want, it still feels sub-optimal, as it lacks the equivalent of user or user-group objects as policy sources, which is something we can easily do with SSL VPN. Managing access purely based on source IPs per user feels cumbersome and error-prone.

Request for Guidance

It is very possible that both of the above approaches are not optimal, and this is the main reason I am opening this thread.

I would really appreciate your input on:

  • What is considered best practice for IPsec Dial-Up user access on FortiGate

  • How you personally implement user-based access control with IPsec VPN

  • What you would do differently if you were in my position

  • Any recommended design patterns or Fortinet documentation references

Thank you very much in advance for your time and valuable input.

Kind regards,
Dimitris

1 reply

funkylicious
SuperUser
SuperUser
January 16, 2026

hi,

i would create a single tunnel and control the user's access based on the group, so in phase1 XAUTH you enable inherit from policy the users/groups and the in the firewall policies select the ipsec range assigned to the clients and user group(s).

"jack of all trades, master of none"
Dparaskevas
Visitor III
January 16, 2026

Hi,

thank you for the reply.

I have already tested this approach, so it is very possible that I am missing something in the configuration.

The firewall rules are shown in the Screenshot 2026-01-16 194405.pngscreenshot.










However, on the client side, after the tunnel is established, the routing table looks like the second screenshot:

Screenshot 2026-01-16 194451.png
1st is my lan gateway, 2nd is vpn gateway.

Additionally, based on my understanding, I would normally expect to see a specific route on the client side for 10.10.40.0/24, which is the destination subnet of the first firewall rule where the user group is matched.

 

So I am not sure if I am missing a required setting or this routing behavior is expected when using inherit from policy