Technical Tip: IPSec Remote Access using Certificate + Username/Password Authentication for User-Based Access Control

[Jaye17]

Description	This article describes how to implement IPsec remote access (dial-up) using certificate and username/password authentication to control user access to the resources over the tunnel by assigning different user definitions on individual firewall policy with varying subnets accessible over the tunnel. This implementation uses IKEv1 and XAUTH.
Scope	FortiGate. IPsec IKEv1.
Solution	When administrators are migrating from SSL VPN and would like to leverage the same benefits it offers wherein various user groups can be added under Authentication/Portal Mapping and the same user groups can be added under firewall policy to control access to internal resources, this method can achieve the same result. Note that this was tested on IKEv1 using a combination of X.509 and XAUTH.   Configure the dialup IPsec tunnel following the documentation below. This article assumes that all the required certificates were already imported to FortiGate and to the end user machine: Dialup IPsec VPN with certificate authentication  Once set up, modify the following configurations on FortiGate. On FortiGate, create local or remote users. Here, local users is used. Create two users to test their assigned access later in this document. For scalability purposes, it is recommended to reference user groups when configuring firewall policies, instead of individual users. Refer to this KB article: Technical Tip: Procedure to add multiple user group in XAUTH in dial-up IPsec VPN configuration  config user local edit "User1" set type password set passwd xxxx next edit "User2" set type password set passwd xxxx next end Under the IPsec phase 1 configuration, enable XAUTH and choose 'Inherit from Policy'. This option will only be visible if IKEv1 is selected. CLI: config vpn ipsec phase1-interface edit <VPN-name> set xauthtype auto next end  Consider if split-tunneling should be enabled/disabled. If disabled, no other changes are needed for the access to internal subnets, but users would need additional firewall policies in order to access Internet resources while connected to VPN. If split-tunneling is enabled, ensure that all the subnets that are going to be accessible over the tunnel must be added in the 'Accessible Networks' after selecting 'Enable IPv4 Split Tunnel'. This will ensure that all routes will be installed on the end user machine. In this example, 'IPV4 Split Tunnel' is enabled and both subnets configured later in firewall policies are included in accessible networks, as follows. Note that even though all clients that connect to this VPN will have routes to all applicable subnets, access will be controlled using firewall policies, based on the configured access for each user or user group. Create two separate firewall policies that have different destination subnets and add the user definitions on each firewall policy, as required.    Note the access granted for each user based on the above firewall policies: User1 can access 10.38.10.0/24  User2 can access 10.40.8.0/24 Modify the following configurations on the FortiClient settings. Before the changes, the sign-on window would look like this, as Authentication (EAP) has been set to disabled. Select the menu beside the VPN name, select 'Edit the selected connection.' Under Authentication (EAP), select either 'Prompt on login' or 'Save login.'   Select 'Save'. The login page now would look like this.  Supply the configured password as per the local account created. Select 'Connect' Test for User 1. This user (User1) is configured to have access to 10.38.10.0/24, not the subnet 10.40.8.0/24. Note that both routes will be available when checking the route print on the device. Test the connectivity to both subnets. Ping to 10.40.8.0/24 fails while ping to 10.38.10.0/24 succeeds.  Disconnect User1 and connect using User2 credentials. User2 is configured to have access to the 10.40.8.0/24 subnet, not the 10.38.10.0/24. Test ping connectivity on both subnets. Ping to 10.40.8.1 now works while ping to 10.38.10.1 fails.  On FortiGate, the CLI configuration with the combination of certificate authentication (X.509) and XAUTH will be as follows: config vpn ipsec phase1-interface     edit "DialUp-Cert"         set type dynamic         set interface "port2" set authmethod signature      <----- Sets the authentication to user certificate.         set mode aggressive set peertype peergrp      <----- Sets the type of peer the connection is expected from.         set net-device disable         set mode-cfg enable         set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1         set dhgrp 14 set xauthtype auto            <----- sets the XAUTH value to Inherit from policy.         set nattraversal forced         set certificate "FGT_IPsec" set peergrp "pki-users"        <----- Identifies the peer-group configured on FortiGate.         set ipv4-start-ip 10.53.35.2         set ipv4-end-ip 10.53.35.25         set dns-mode auto         set ipv4-split-include "DialUp-Cert_split"              set unity-support disable     next end IKEv2 configurations: In FortiGate v7.4.2 and later, similar functionality can be achieved using IKEv2, which supports additional features including SAML user authentication. See FortiGate v7.4.0 New Features Guide | IPsec IKEv2 VPN 2FA with EAP and certificate authentication Related articles: Technical Tip: Procedure to add multiple user group in XAUTH in dial-up IPsec VPN configuration  Technical Tip: How to configure dialup tunnel with LDAP integrated certificate authentication  Technical Tip: Certificate authentication for IKEv2 VPN with RADIUS or LDAP user authentication Technical Tip: Certificate Authentication for FortiClient remote access dialup IPsec clients with SA...