Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Dparaskevas
New Contributor II

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

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

dpar
dpar
13 REPLIES 13
funkylicious
SuperUser
SuperUser

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"
"jack of all trades, master of none"
Dparaskevas

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

dpar
dpar
Dparaskevas

Update: ok now for sure i dont know whats going on.
I tried with the same user but from different pc with different version of forticlient and i am getting this output:

 

Screenshot 2026-01-16 205753.png
which is not correct also becouse from firewall policies i mustot have access to all these networks

dpar
dpar
funkylicious

ok, so the routes/subnets you have defined in the object that you are using in split-tunnel are ok. ( usually the FCT injects a default route instead of specific subnets sometimes, dont know why this happens. i just reinstall FCT and/or delete the vpn profile and re-create it and then it works )

 

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-FortiClient-not-installing-split-tun... 

 

based on the firewall rules you have previously posted, i would expect only towards CCTV to work, since in the rest you dont have the IPsec-Clients group defined.

 

also, i'm not a big fan of NAT'ing traffic from vpn to lan, so i would disable those.

 

if it still doesnt work, please do a diag debug flow capture ( you should disable npu-offload just to make sure that you capture all the traffic either under phase-1 or in the firewall rule [ auto-asic-offload ] ) and lets see that traffic arrives at the firewall and what decision it takes in regards to the traffic ( i would suggest focusing your debug on a single destination )

 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Using-filters-to-review-traffic-traversing... 

 https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiGate-Disable-Hardware-Acceleration/ta... 

 

also, you can post a sanitized phase-1 config just to make sure that everything is in order.

"jack of all trades, master of none"
"jack of all trades, master of none"
Dparaskevas

I would expect the same, having access only on the cctv network but sudenly i got access to all networks. 
here is phase 1 conf

config vpn ipsec phase1-interface
    edit "Dialup-IPSEC"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set ipv4-dns-server1 8.8.8.8
        set proposal aes128-sha1 aes256-sha256
        set comments "ike 2"
        set dhgrp 5
        set eap enable
        set eap-identity send-request
        set ipv4-start-ip 10.200.101.2
        set ipv4-end-ip 10.200.101.200
        set ipv4-split-include "Dialup-IPSEC_split"
        set save-password enable
        set psksecret
dpar
dpar
funkylicious

try unset authusrgrp , under phase-1 and reconnect and see if it still works for others or just CCTV net.

"jack of all trades, master of none"
"jack of all trades, master of none"
Dparaskevas

I have already done this.
authusrgrp is currently unset under Phase1; i think it just does not appear in the show output because it displays parameters that are explicitly set.

I confirmed the behavior after reconnecting the clients, and the issue remains the same, all local networks are still reachable

dpar
dpar
funkylicious

is the user local on FGT or is it via a external LDAP or RADIUS which connects ?

"jack of all trades, master of none"
"jack of all trades, master of none"
Dparaskevas

users are local

dpar
dpar
Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors