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

[Dparaskevas]

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

[funkylicious]

have a read at this - https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-use-multiple-groups-with-EAP-for-IK... , especially the " In the firewall policy, the source IP needs to be set to 'all'  to trigger the authentication and successfully connect to the VPN. " part and give it a try.

i would also do a debug similar to what's described in the article to see the auth method and the decision it takes.

L.E. in regards to XAUTH, source :

In IKEv1, this behavior is achieved by setting the XAUTH configuration to 'Inherit from policy'.

In IKEv2, this behavior is achieved via CLI, by enabling EAP and setting 'eap-identity' to 'send-request', but leaving the 'authusrgrp' value blank.

[funkylicious]

just to be on the same page.

all those networks should be visible on the client with route print, but you should be able only access the CCTV subnet 10.10.X.0/24 and not the rest.

if not, try using ikev1 and see.

[Dparaskevas]

Hi everyone,

I believe I have finally identified the root cause of the issue, or at least the correct direction.

In the end, the problem was not so much the configuration itself, but rather the design logic I was using, which was heavily influenced by how SSL VPN firewall policies work. From what I now understand, this logic does not translate directly to IPsec.

To explain with an example:

With SSL VPN, our usual approach  for us is to build firewall policies based on:

• the same source address (SSL VPN IP pool),

• the same source user or user group,

• and different destination networks.

For example, if a user needs access to two different subnets, we can simply:

• create one rule for subnet A,

• another rule for subnet B,
  both matching the same user or group.example:

If later we want to allow an additional user to access subnet B (for example the CCTV network), we simply add that user to the existing firewall rule. 

example:

However, I have realized that this exact logic cannot be applied in the same way to IPsec dial-up VPN. 

As a result, to achieve the desired behavior with IPsec, the logic needs to be reversed:

• If a user must have access to multiple internal networks, those destinations need to be covered by a single firewall policy

• This means that the user groups referenced in the firewall policies must be designed accordingly, so that they can be matched within one rule instead of being spread across multiple overlapping rules

example:

In other words, user group design becomes more important, and access must be aggregated per rule, rather than extended incrementally per destination as we commonly do with SSL VPN.

I hope the above explanation makes sense.
I may not be 100% correct, as this is my first full IPsec dial-up deployment, but this approach appears to be working correctly for me at the moment. I would really appreciate any feedback or confirmation from others on whether this aligns with best practices.

Thank you very much to everyone for your time and assistance.

Kind regards,

[Toshi_Esumi]

You might have 

  set ipv4-split-exclude ...
in your phase1-interface config. Change it to like:
    set ipv4-split-include "10.10.40/24net"
after configureing the address object you want to let them access.

Toshi