Realms are a feature on the FortiGate that I have written about in the past, but I never really did a detailed dive into them and how and when to use them.
When a customer tells me they want to assign different policies to different users connecting to the FortiGate via VPN, my first thought is realms
. Realms allow you to define different authentication methods, assign different ranges of IP addresses, provide different customized portals (company vs D.B.A.) etc.
fqdn/corporate
to corporate.fqdn
ssh
and ping
only.Here are the ingredients for the realm
configuration.
In a previous article, I wrote about using a normal user to bind to AD. I will use that same configuration here.
Her we see the basic LDAP configuration.
Below we can see the User Group
we are creating using the Remote Group
option and then choosing the VPN-Users
Active Directory group.
Below we see the completed remote group
showing the name and the AD group below.
Now we are going to create a Local-Contractor
group that will be, as its name implies, LOCAL to the firewall.
Under User & Device
(6.2 and below) or User and Authentication
then User Groups
, then Create
Now we are going to create a contractor
user.
Under User & Device
(6.2 and below) or User and Authentication
you will see User Definition
then Create
.
Choose Local User
then choose
Now we need to enter the Username
and Password
Optionally, you can enter an email.
Note: If you are using the email as 2-factor, you will require this email field to be filled out.
You will need to enable the User Group
You then need to choose the group (in our case Local-Contractors
)
Now lets jump over to System
then Feature Visibility
then enable SSL VPN Realms
Hit Apply
Now we can create the realms. Go to VPN
then choose SSL-VPN Realms
and finally Create New
Lets create the corporate
realm
Simply create a new realm and name it. We will modify this later but for now, pay attention to the blue box that shows the https://10.2.2.121/corporate
Next we will create the contractor
realm.
Now we will create two Firewall Address object
Here we can see that we created a Corp-VPN-Pool
with a subnet of 10.10.10.0/24
We also created a Contractor-VPN-Pool
using a different 10.10.11.0/24
Lets create the Corporate Portal
You can see above that we are using the subnet we created named Corp-VPN-Pool
and we are also sending all DNS destined for myinfoseclab.local
to my internal DNS servers.
On the Contractor Portal
we are using the Contractor-VPN-Pool
and we are using the system DNS (In our case, FortiGuard Labs).
Here we see the two realms we created.
Now we need to set up the authentication for the different portals in their respective realms. This is under VPN
then SSL-VPN Settings
.
Her we can see that none of the portals we created are listed.
User Group
we cerated earlier.Specify
under the Realm
section.realm
from the drop-down ( /contractors
)Portal
. In this case Contractor Portal
Note the we chose the Local-Contractors
user group which is the local firewall group with the member contractor01
.
User Group
we cerated earlier.Specify
under the Realm
section.realm
from the drop-down ( /corporate
)Portal
. In this case Corporate Portal
Note that in this Authentication Section, we have used the Active Directory group we added to the AD
group we configured earlier.
The finished portal mapping
We now need to create the policies to permit the traffic per realm.
For the contractors, we are allowing them to ping
and ssh
to the certain IPs
we discussed in the Recipe
We can see that it references the Source as Contractor-VPN-Pool
and well as the Local-Contractors
group.
Her we see the Corporate
policy. We can see the Corp-VPN-Pool
as the source
network with the AD-Corporate Users
and some additional ports.
Her we see the finished policies for the remote access to internal. Now we will configure an Internet policy.
Finished Policy
Since I always use Central NAT
I need to create a SNAT Policy. You will need to go to your Policy & Objects
then Central SNAT
and Create New
Below we are creating one single policy where there is NO NAT
coming from either network address going to all
via the Outgoing Interface
which is port2
.
Since we set split tunnel disabled when we created the portal, we need to create a NAT allowing Internet access.
Her we see that we have the NAT
enabled and we are using Outgoing Interface Address
Thanks to my friend Matt Sherif that blogs at UltraViolet Networks, he allowed me to link to his article from InfoSecMonkey we can change the behavior of the realm link. Rather than using:
https://vpn.myinfoseclab.com/corporate to https://corporate.myinfoseclab.com
You will obviously need to create an external DNS entry pointing to your new virtual host. Once you edit this in the CLI, you will see it in the GUI allowing you to modify it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.