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).

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).

Topology:

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

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: 172.16.0.0/24) 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: 172.16.0.0/24

- interface: port2

Second one (for vpn client pool):

- name: source_ip_pools

- type: subnet

- IP/Netmask: 192.168.100.0/24

- 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 192.168.100.0/24 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 (172.16.0.2), by going to 'Quick connection', select ping application and enter client1's ip address. You should receive the message: '172.16.0.2' 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).

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 - https://repo.fortinet.com/repo/6.4/ubuntu/DEB-GPG-KEY | sudo apt-key add -
# add to /etc/apt/sources.list the deb path
sudo sh -c 'echo "deb [arch=amd64] https://repo.fortinet.com/repo/6.4/ubuntu/ /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).

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

eve@ubuntu:~$ ifconfig vpn
vpn: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
        inet 192.168.100.1  netmask 255.255.255.255  destination 192.168.100.1
[...]

See also the routing table:

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

For test, ping client1 from branch1:

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

--- 172.16.0.2 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

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
/var/log/forticlient
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 192.168.0.0/24 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).

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 0.0.0.0:50997 to 127.0.0.1:1812 length 77
	User-Name = "student"
	User-Password = "stud123"
	NAS-IP-Address = 127.0.1.1
	NAS-Port = 0
	Message-Authenticator = 0x00
	Cleartext-Password = "stud123"
Received Access-Accept Id 189 from 127.0.0.1:1812 to 0.0.0.0:0 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 172.16.0.2