Lab 10. Fortigate Remote Access VPN



After configuring HA between the two available firewalls, we decided for our employees to offer them remote access (work from home). This will be possible using SSL-VPN feature and an authentication profile using 1FA (we can also configure 2FA, but due to limited budget, we do not have this part available).

Lab infra

As we will require a remote user, create a new Linux node (you can use the already existing image called: linux-ubuntu-18.04-server_machine), use for 'First Eth MAC Address' the following format 50:00:00:byte_2_eveng_ip:byte3_eveng_ip+3:byte4_eveng_ip and connect it to Network Cloud (connected to Management Cloud0).


Note: you can keep the configuration already made on the latest lab (with IPSec tunnels on both firewalls).


e1. Tunnel split [5p]

The first task is a quick start to SSL-VPN on fortigate: configure 'tunnel split' for letting traffic for a specific subnet or multiple ones. For example: let remote user access only the first branch (in our case, the subnet: where they may have some internal documentation.

e1.1: Go to Policy and Objects > Address and create 2 new address objects:

First one (for branch1):

- name: internal_subnet1

- type: subnet

- IP/Netmask:

- interface: port2

Second one (for vpn client pool):

- name: source_ip_pools

- type: subnet

- IP/Netmask:

- interface: leave any

e1.2: For the beginning, we will use only local authentication, which means that credentials are stored locally on the firewall device. Go to User & Authentication > User definition and create the local user test1 with password fortigate.

e1.3: Create a group for the user test1. Go to User & Authentication > User Groups, create new:

- name: testgroup

- type: firewall

- members: test1

e1.4: Create the ssl-vpn portal by going to VPN > SSL-VPN Portals, create new:

- name: ssl_vpn_tunnel_split

- enable tunnel mode and split tunneling

- Routing Address: internal_subnet1 (only the traffic to this network will be accepted)

- Source IP Pools: source_ip_pools (ip pool that will be used for allocating ip addresses to clients)

Keep the rest of config as it is.

e1.5: Configure ssl-vpn settings by going to VPN > SSL-VPN Settings:

- Listen on Interface(s): port1 (mgmt interface that has access to Cloud area and also remote clients)

- Listen on Port: 10443 (use a custom one)

- keep for portal certificate the self-signed one

- keep the logout time to 300 seconds (after 5 minutes of inactivity, disconnect the user automatically)

- Tunnel Mode Client Settings > Specify custom IP Ranges > select address source_ip_pools (this way the source ip from range will be let to access internal networks. If we keep the default ip pools here, clients will receive an ip from pool configured on Portal above)

- Authentication/Portal Mapping > All Other Users/Groups > select tunnel access. Add another entry for user group configured above testgroup and portal ssl_vpn_tunnel_split

- click apply

e1.6: At last, configure the firewall policy:

- from SSL.VPN to port2

- source: select address all (already defined) and user tesgroup

- destination: internal_subnet1

- service ALL

- NAT disabled

- keep the rest as they are

e1.7: After firewall configuration, we need to check SSL-VPN configuration: on Remote device, go to Firefox and type address: https://fw_address:10443 (for fw_address use the private ip from port1). Authenticate and see the welcome page.

Check if you can access the ip address of client1 (, by going to 'Quick connection', select ping application and enter client1's ip address. You should receive the message: '' is reachable.

FortiClient is the agent that needs to run on client's side in order to create the VPN tunnel (same as Cisco AnyConnect and Palo Alto's GlobalProtect).

The system administrator can define other types of tests that can be pushed to portal's page. When clients are connecting to this page, they might firstly try to run them to see if the required resources are available, and after that they can download the installer for agent.

This can be done by going to VPN > SSL-VPN Portals > select the portal from above > Predefined Bookmarks > New Bookmark, and add a name, select the protocol (can be ssh), add the host and ip address of client and save. After a refresh on the portal's page, you may see the Bookmarks on top. Click on icon, then a new tab should appear, with a console to connect to machine:

e1.8: As FortiClient download link is not included in portal webpage, we need to install it directly from cli:

# install gpg key
wget -O - | sudo apt-key add -
# add to /etc/apt/sources.list the deb path
sudo sh -c 'echo "deb [arch=amd64] /bionic multiverse" >> /etc/apt/sources.list'
# update and install the package
sudo apt-get update
sudo apt-get install forticlient

e1.9: Go to FortiClient GUI > Remote Access > add a new connection:

- connection name: SslVpnToHQ

- remote gateway: firewall address for port1

- customize port: 10443

- no client certificate and prompt on login

Save and login user credentials from e1.2 (accept portal certificate).

In case you cannot login to ssl-vpn portal (no certificate warning appears), you need to do the following (workaround for this Linux bug): close the window from 'X' (DO not kill the application), then start it again from Application's Icon (seen above on taskbar) > FortiClient and try to login again to portal.

e1.10: Check the newly configured interface for vpn:

eve@ubuntu:~$ ifconfig vpn
        inet  netmask  destination

See also the routing table:

eve@ubuntu:~$ ip r s
[...] via dev vpn scope link dev vpn proto kernel scope link src metric 450 
# see that branch1 route is injected

For test, ping client1 from branch1:

eve@ubuntu:~$ ping -c 5
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=63 time=1.69 ms
64 bytes from icmp_seq=2 ttl=63 time=2.57 ms
64 bytes from icmp_seq=3 ttl=63 time=2.79 ms
64 bytes from icmp_seq=4 ttl=63 time=5.44 ms
64 bytes from icmp_seq=5 ttl=63 time=4.00 ms

--- ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4011ms
rtt min/avg/max/mdev = 1.690/3.300/5.441/1.301 ms

We can also configure for an user definition, MFA, using FortiTokens (email or SMS are used for enabling the FortiToken application) - see them on User & Authentication > FortiTokens. But, this requires special licenses which are not currently available for us.

When authenticating to a portal, using this solution, we are required to introduce credentials (first layer of auth - 'something you know'), then on the second one to enter the OTP from the software token generator ('something you have/own').

FortiClient extra

If you encounter other issues on your remote user machine when connecting to Fortinet firewall to establish the tunnel, you may check the logs from the path:

eve@ubuntu:$ pwd
eve@ubuntu:$ ll
total 44
drwxr-xr-x  4 root root   4096 Jan 21 23:57 ./
drwxrwxr-x 16 root syslog 4096 Jan 22 00:06 ../
-rw-r--r--  1 root root    781 Jan 21 23:59 epctrl.log
-rw-r--r--  1 root root    746 Jan 21 23:57 fctc.log
-rw-r--r--  1 root root   1078 Jan 21 23:59 fctsched.log
drwxr-xr-x  2 root root   4096 May 31  2021 fmon_log/
-rw-r--r--  1 root root    137 Jan 21 23:57 libvcm.log
-rw-r--r--  1 root root   3554 Jan 21 23:59 sslvpn.log
-rw-r--r--  1 root root   4503 Jan 21 23:57 update.log
drwxr-xr-x  2 root root   4096 May 31  2021 vcm_log/
# from this list, you can verify sslvpn.log file 

Known issues that are identified based on logs:

1. The agent's user interface does not properly work (the workaround is described above on step e1.9):

20220122 20:00:56.765 [sslvpn:INFO] main:370 Load profile: SslVpnToHQ
20220122 20:00:56.807 [sslvpn:INFO] main:118 Get DBUS session bus address
20220122 20:00:57.844 [sslvpn:INFO] main:162 DBUS session bus address not found

2. Wrong subnet used for vpn clients:

20220122 00:13:56.765 [sslvpn:INFO] sslvpn:739 Login successful
20220122 00:13:56.807 [sslvpn:INFO] main:1112 State: Configuring tunnel
20220122 00:13:57.844 [sslvpn:INFO] main:1112 State: Connected
20220122 00:13:57.857 [sslvpn:EROR] vpn_connection:837 IO write local failed. [-1 of 33]
20220122 00:13:57.857 [sslvpn:EROR] vpn_connection:1379 Error: Disconnected because of error: IO write local failed.
20220122 00:13:57.857 [sslvpn:INFO] vpn_connection:1493 /remote/logout
20220122 00:13:57.875 [sslvpn:INFO] sslvpn:751 Logout successful

See the error 'IO write local failed' - this is due to a misconfiguration on the Fortigate machine (the initial source ip pool was for tunnel clients, but this range is already used by the second branch, which means the ip cannot be assigned to another interface, in this case, ssl.root).

e2. Remote authentication [5p]

Besides local authentication, we can use LDAP/RADIUS/TACACS+ servers (remote ones).

As in our topology clients from both branches do not have Internet access, we are going to use a new Linux node (same config as above, but mac address will be 50:00:00:byte_2_eveng_ip:byte3_eveng_ip+4:byte4_eveng_ip) that is also connected to Cloud0 network.

e2.1: Go to radius_server device and install + configure freeradius:

root@ubuntu:/# apt-get install freeradius
root@ubuntu:/# vim /etc/freeradius/3.0/clients.conf
# add here the following lines:
client forti {
ipaddr = FORTI_port1_mgmt_address # change here with port1 ip
secret = fortigate
root@ubuntu:~# vim /etc/freeradius/3.0/users

# add here the user 'student' + password 'stud123'
student Cleartext-Password := "stud123"

# restart service
root@ubuntu:~# service freeradius restart

# test also the configuration file
root@ubuntu:~# freeradius -CX
Configuration appears to be OK

# in the end, test locally radius auth
root@ubuntu:~# radtest student stud123 localhost 0 testing123
Sent Access-Request Id 189 from to length 77
	User-Name = "student"
	User-Password = "stud123"
	NAS-IP-Address =
	NAS-Port = 0
	Message-Authenticator = 0x00
	Cleartext-Password = "stud123"
Received Access-Accept Id 189 from to length 20

e2.2: Go to forti device > User & Authentication, create new:

- User type Remote RADIUS user

- username student and radius server > create > add ip for radius_server device + secret fortigate (test also connectivity and user credentials)

e2.3: Add the new user to the already existing group testgroup

e2.4: Go again to remote Linux device and try to authenticate to ssl-vpn portal using student:stud123. Check again ping to

sred/lab9.txt ยท Last modified: 2023/01/13 17:04 by horia.stoenescu
CC Attribution-Share Alike 3.0 Unported Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0