Agentless VPN security best practices

Securing remote access to network resources is a critical part of security operations. Agentless VPN allows administrators to configure, administer, and deploy a remote access strategy for their remote workers. Applying the proper levels of security are integral to providing optimal performance and user experience and keeping user data safe.

The guidelines in this topic outline how to employ security best practices to protect your data.

Information about Agentless VPN throughput and maximum concurrent users is available on your device's datasheet; see Next-Generation Firewalls Models and Specifications.

Do not set the virtual IP addresses as the destination address in a firewall policy when using Agentless VPN, as it will result in no destination address being accessible. Please note that the FortiOS Agentless VPN does not support mapping the virtual IP to the actual one.

Ensure you always upgrade your FortiGate to the latest FortiOS firmware version. This ensures you are running the latest Agentless VPN security enhancements to protect your VPN deployment.

Agentless VPN settings

• Define your minimum supported TLS version and cipher suites

• Limit log in attempts and block duration

• Limit users to one Agentless VPN session at a time

• Use a custom listening port for Agentless VPN

• Disable Agentless VPN

• Enable server hostname

Authentication

• Integrate with authentication servers

• Use a non-factory SSL certificate for the Agentless VPN portal

• Use multi-factor authentication

• Use multi-factor authentication with authentication servers

• Disable case sensitivity for remote users using authentication servers and MFA

• Deploy user certificates for remote Agentless VPN users

Authorization

• Properly administer firewall policies and profiles against only the access level required for the remote user

• Set the default portal to a custom VPN portal with Agentless VPN disabled

• Limit incoming access to specific hosts or geography based addresses

• Limit incoming access using local-in policies with specific hosts, geography based addresses, or schedules

• Limit incoming access using a virtual IP, loopback interface, and firewall policy with Internet Services or an external feed or schedule

Agentless VPN settings

Define your minimum supported TLS version and cipher suites

Minimum and maximum supported TLS version can be configured in the FortiGate CLI. The cipher algorithm can also be customized.

See How to control the SSL version and cipher suite for Agentless VPN for more information.

Limit log in attempts and block duration

To prevent brute force attacks, limit log in attempts and configure the block duration:

config vpn ssl settings
   set login-attempt-limit 2    
   set login-block-time 60          
   set login-timeout 30
end

These are the default values. The FortiGate will block attempts to connect to Agentless VPN for 60 seconds after two unsuccessful log in attempts.

This configuration enhances Agentless VPN security by limiting failed login attempts (login-attempt-limit 2), temporarily blocking an IP for 60 seconds after two consecutive failed attempts (login-block-time 60), and defining a 30-second window for consecutive login attempts (login-timeout 30). If two failed attempts occur within 30 seconds of each other, they are considered consecutive and trigger a block. However, if the second attempt occurs after 30 seconds, it resets the login attempt count. These settings help mitigate brute-force attacks by restricting repeated login attempts within a short period.

Modify the values as needed for your requirements.

Limit users to one Agentless VPN session at a time

To prevent attacks from a compromised user, you can limit a user to one Agentless VPN session at a time by going to VPN > Agentless VPN Portals, editing a portal, and enabling Limit Users to One Agentless VPN Connection at a Time. This option can also be configured in the CLI:

config vpn ssl web portal
    edit < portal name >
        set limit-user-logins enable
    end
end

Use a custom listening port for Agentless VPN

To prevent external attacks targeting the default Agentless VPN port 443, use a custom port for Agentless VPN.

The Agentless VPN listening port can be configured from the GUI on the VPN > Agentless VPN Settings page by changing the Listen on Port field from the default 443 to any other port. To change the listening port in the CLI:

config vpn ssl settings
    set port <port number>
end

After changing the Agentless VPN listening port, ensure that end users are informed of the new port. Users must update the Agentless VPN web portal URL in their browsers, replacing 443 with the newly assigned port.

Make sure that the selected port is not in use by other services on the firewall.

Disable Agentless VPN

After the Agentless VPN settings have been configured, Agentless VPN can be disabled when not in use.

To disable Agentless VPN in the GUI:

1. Go to VPN > Agentless VPN Settings.

2. Set Agentless VPN status to Disable.

3. Click Apply.

If the FortiGate has VDOMs configured, select the appropriate VDOM, and repeat the steps to disable Agentless VPN for that specific VDOM.

See How to disable Agentless VPN functionality on FortiGate for more information.

Enable server hostname

Enabling server hostname ensures that if a page redirection occurs, the FortiGate server hostname is used in the host field of the HTTP header instead of a client-provided host field.

config vpn ssl settings
    set server-hostname <redirect host name>
end

Authentication

Integrate with authentication servers

For networks with many users, integrate your user configuration with existing authentication servers through LDAP, RADIUS, or FortiAuthenticator. When integrating with existing authentication servers, these users are referred to as remote users.

By integrating with existing authentication servers, such as Windows AD, there is a lower chance of making mistakes when configuring remote users and remote user groups, reducing your administration effort. Also, credentials for remote users are kept on the authentication servers themselves and are not stored on the FortiGate, unlike credentials for local users.

See Agentless VPN with LDAP user authentication and Agentless VPN with RADIUS on Windows NPS for more information.

It is best practice to integrate with encrypted protocols on authentication servers such as LDAPS instead of LDAP, and RADSEC over TLS instead of RADIUS. See Configuring client certificate authentication on the LDAP server and Configuring a RADSEC client for more information.

Use a non-factory SSL certificate for the Agentless VPN portal

Your certificate should identify your domain so that a remote user can recognize the identity of the server or portal that they are accessing through a trusted CA.

The default Fortinet factory self-signed certificates are provided to simplify initial installation and testing. If you use these certificates you are vulnerable to man‑in‑the‑middle attacks, where an attacker spoofs your certificate, compromises your connection, and steals your personal information. It is highly recommended that you purchase a server certificate from a trusted CA to allow remote users to connect to Agentless VPN with confidence. See Procuring and importing a signed SSL certificate for more information.

Use multi-factor authentication

Multi-factor authentication (MFA) ensures that the end-user is who they claim to be by requiring at least two factors - a piece of information that the user knows (password), and an asset that the user has (OTP). A third factor, something a user is (fingerprint or face), may be enabled as well. FortiToken Mobile is typically used for MFA.

FortiGate comes with two free FortiTokens, and more can be purchased from the FortiToken Mobile iOS app or through Fortinet partners.

See Agentless VPN with FortiToken mobile push authentication for more information.

2FA, a subset of MFA, can also be set up with email tokens. See Email Two-Factor Authentication on FortiGate for information.

Use multi-factor authentication with authentication servers

Users configured with MFA, such as FortiToken Mobile tokens and email tokens on the FortiGate, are still essentially local users with user credentials stored on the FortiGate.

You should therefore consider using a combination of MFA and authentication servers for optimal security. See Agentless VPN with LDAP-integrated certificate authentication, Agentless VPN with RADIUS and FortiToken mobile push on FortiAuthenticator, and RADIUS integrated certificate authentication for Agentless VPN for more information.

Disable case sensitivity for remote users using authentication servers and MFA

When using remote users with authentication servers and MFA, it is possible for MFA to be bypassed if the case of the entered username is not an exact match. To prevent this, ensure case sensitivity is disabled for each remote user that has been configured on the FortiGate with authentication server and MFA settings. See Agentless VPN for remote users with MFA and user sensitivity for more information.

Deploy user certificates for remote Agentless VPN users

This method of 2FA uses a user certificate as the second authentication factor. This is more secure, as it identifies the end user using a certificate. The configuration and administration of this solution is significantly more complicated, and requires administrators with advanced knowledge of the FortiGate and certificate deployment.

See Agentless VPN with certificate authentication for more information.

Authorization

Properly administer firewall policies and profiles against only the access level required for the remote user

Users do not all require the same access. Access should only be granted after careful considerations. Typically, users are placed in groups, and each group is allowed access to limited resources.

Using Agentless VPN simplifies defining the control structure for mapping users and groups to the appropriate resources.

See Agentless VPN multi-realm for more information.

Set the default portal to a custom VPN portal with Agentless VPN disabled

In the Agentless VPN settings, it is mandatory in the Authentication/Portal Mapping section to configure a portal for All Other Users/Groups or what can be considered a default portal for other users who are not specifically mapped to access Agentless VPN portals.

When the Authentication/Portal Mapping does not match users or groups that you have specifically mapped to access Agentless VPN portals, you can create a custom Agentless VPN portal and disable web-mode using the CLI, and then set default portal to that custom portal. This configuration is analogous to the implicit deny policy in firewall policies, in that this custom portal can deny all other users and groups.

For a default portal with web-mode disabled, users deemed part of All Other Users/Groups can still access the Agentless VPN portal. Once these users try to log in to the portal, access will be denied. Users deemed part of All Other Users/Groups should be unable to successfully establish Agentless VPN connection in this case.

To disable web-mode in custom Agentless VPN portal and apply it in Agentless VPN settings:

1. Using CLI, edit the Agentless VPN web portal and disable web mode.

   config vpn ssl web portal
       edit "custom-web-portal"
           set web-mode disable
       next
   end

2. Apply the custom web portal to Agentless VPN:

   • Using the GUI:

     1. Go to VPN > Agentless VPN Settings.

     2. Under Authentication/Portal Mapping, click All Other Users/Groups > Edit.

     3. Under Portal dropdown, select custom-web-portal.

     4. Click OK.

     5. Click Apply.

   • Using the CLI:

     config vpn ssl settings
         set default-portal "custom-web-portal"
     end
     

Limit incoming access to specific hosts or geography based addresses

The simplest method for limiting incoming access is specifying source addresses in the Agentless VPN settings.

• If you require schedules and geography based addresses, and are comfortable using the CLI, then consider configuring local-in policies as described in To limit incoming access to specific hosts based on their source IP addresses in the CLI.

• If you require Internet Services using ISDB or external feeds, or schedules and geography based addresses, and are more comfortable using the GUI, then consider configuring a VIP, loopback, and firewall policy as described in To limit incoming access to specific hosts based on their source IP addresses in the GUI.

To limit incoming access to specific hosts based on their source IP addresses in the GUI:

1. Create address objects or groups with the source IP addresses you need to allow access to Agentless VPN.

2. In VPN > Agentless VPN Settings under Restrict Access, select Limit access to specific hosts and in the Hosts field select address objects or groups corresponding to specific source IP addresses for hosts that you need to allow.

3. To block specific source IPs while allowing all others, enable Negate Source, and select the address objects or groups representing the restricted hosts.

To limit incoming access to specific hosts based on their source IP addresses in the CLI:

config vpn ssl settings
    set source-address <source address 1> ... <source address n>
    set source-address-negate {disable | enable}
end

With this CLI, you can limit incoming access to hosts from specific countries by specifying geography-based addresses as the source addresses. See Geography based addresses for more information.

Limit incoming access using local-in policies with specific hosts, geography based addresses, or schedules

As an alternative to configuring source addresses in the Agentless VPN settings, you can configure local-in policies to allow and deny specific source addresses.

The configuration workflow is:

1. Create a new custom service corresponding to the Agentless VPN listening TCP port.

2. (Optional) Create new geography based addresses that can be specified as the source addresses for the allow and deny local-in policies that are created.

3. (Optional) Configure new schedules that can be specified as the schedule for the allow and deny local-in policies that are created.

4. Create a local-in policy using the Agentless VPN custom service to allow specific source addresses.

5. Create a local-in policy using the Agentless VPN custom service to deny specific source addresses. This is required since there is no implicit deny local-in policy defined by default.

Note that extra care should be taken when configuring a local-in policy, as an incorrect configuration could inadvertently deny traffic for IPsec VPN, dynamic routing protocols, HA, and other FortiGate features.

The source IP address objects that are used can be address objects or groups, or geography based address objects. New schedules can be created and applied to the local-in policies to impose schedule-based access restrictions.

You can also deny all access to Agentless VPN by creating a deny local-in policy using source address all and Agentless VPN custom service without creating a corresponding local-in policy to allow the Agentless VPN custom service.

Limit incoming access using a virtual IP, loopback interface, and firewall policy with Internet Services or an external feed or schedule

Agentless VPN access can be moved to a secondary IP address or any other WAN IP address defined on a FortiGate interface by using a virtual IP (VIP), loopback interface, and WAN-to-loopback firewall policy.

The configuration workflow is as follows:

1. Configure the Agentless VPN firewall policy from the ssl.<VDOM> interface to the internal interface or interfaces, ensuring that you specify the users and groups (required), and addresses or address groups (optional) in the policy's Source field. See Agentless VPN for remote users.

2. Create a new loopback interface and specify an IP address that is not being used by any other interface on the FortiGate. This IP address can be a private IP address within the RFC 1918 range.

3. Create a new VIP with the following settings:

   • External IP address/range configured as the secondary WAN IP address, or any other WAN IP address that is available for the WAN interface.

   • IPv4 address/range configured as the IP address assigned to the loopback interface.

   • Port forwarding enabled with External service port and Map to IPv4 port with the Agentless VPN listening port.

4. Create a new WAN interface to loopback interface firewall policy with the VIP as the destination address.

5. Under VPN > Agentless VPN Settings, set Listen on Interface(s) to the newly created loopback interface.

6. (Optional) Create a new deny firewall policy, configure Internet Services as source addresses in the new policy, and place it above the WAN-to-loopback firewall policy.

7. (Optional) Create a new deny firewall policy, configure an IP address external feed, configure the external feed as a source address in the new policy, and place it above the WAN-to-loopback firewall policy.

8. (Optional) Configure a new schedule and apply it to the WAN-to-loopback firewall policy.

This configuration gives you the option to deny access to Agentless VPN from specified hosts. You can create a new deny firewall policy, apply Internet Services using the ISDB or external feed objects as source addresses and place the deny policy above the WAN-to-loopback firewall policy.

You also have the option of creating a new schedule and applying it to the WAN-to-loopback firewall policy to allow Agentless VPN access during a specified time or days of the week.

Finally, you can disable all Agentless VPN access by disabling the WAN-to-loopback firewall policy.