Zero Trust Network Access: Hands On Lab

ZERO TRUST NETWORK ACCESS
Hands On Lab
FortiGate 7.0 | FortiClient EMS 7.0 | FortiClient 7.0

Zero Trust Network Access Hands On Lab
Contents
Zero Trust Network Access Hands On Lab .................................................................................................... 1
1. Lab Intro .................................................................................................................................................... 2
1.1 ZTNA Key Concept ............................................................................................................................... 2
1.2 ZTNA vs traditional SSL VPN or IPsec VPN Teleworking solutions ...................................................... 4
1.3 Lab Topology & Preparations.............................................................................................................. 6
1.4 Exercise: Exploring the pre-defined environment .............................................................................. 9
1.5 Basic ZTNA configurations ................................................................................................................ 13
2. FortiGate <-> EMS <-> FCT connection ................................................................................................... 13
2.1 Establishing Device Identity and Device Trust Context with FortiClient EMS .................................. 13
2.2 Lab Exercise: Connect FortiClient and FortiGate to EMS .................................................................. 16
2.3 Lab Exercise: Configure EMS ZTNA tagging rules.............................................................................. 18
3. HTTPS Access Proxy................................................................................................................................. 24
3.1 Concept: Understanding SSL certificate based authentication ........................................................ 24
3.2 Lab Exercise: Configure basic HTTPS Access Proxy with SSL certificate based authentication ........ 27
3.3 Lab Exercise: Configure HTTPS Access Proxy with basic local user authentication and ZTNA tags .. 35
3.4 Lab Exercise: Configure HTTPS Access Proxy with LDAP user authentication and ZTNA tags .......... 41
4. TCP Forwarding Access Proxy ................................................................................................................. 42
4.1 Concept: Understanding TCP Forwarding Access Proxy ................................................................... 42
4.2 Lab Exercise: Configure basic TCP Forwarding Access Proxy for RDP and SSH................................. 43
4.3 Lab Exercise: Configure authentication and security posture check for TCP Forwarding Access
Proxy ....................................................................................................................................................... 50
5. ZTNA IP/MAC filtering mode ................................................................................................................... 54
5.1 (Optional) Lab Exercise: Basic ZTNA IP/MAC filtering example on on-net users .............................. 54
Appendix A: ZTNA Troubleshooting & Debugging ...................................................................................... 60
Appendix B: Documentation References .................................................................................................... 61
Change Log .................................................................................................................................................. 62
1
1. Lab Intro
In this lab, we examine a sample Teleworking solution based on a Tunnel Mode SSL VPN and contrast
that against using a ZTNA Access Proxy for remote access to specific applications. We will go step by step
into configuring the required components, from the FortiClient EMS server, to FortiGate and FortiClient.
Along the way, we will also review key concepts and introduce debug commands to help verify and
troubleshoot the connections.
1.1 ZTNA Key Concept

Zero Trust Network Access (ZTNA) is an access control method that uses client device identification,
authentication, and Zero Trust tags to provide role-based application access. It gives administrators the
flexibility to manage network access for On-net local users and Off-net remote users. Access to
applications is granted only after device verification, authenticating the user’s identity, authorizing the
user, and then performing context based posture checks using Zero Trust tags.
Full ZTNA vs IP/MAC filtering

ZTNA has two modes: Full ZTNA and IP/MAC filtering:
 Full ZTNA allows users to securely access resources through a SSL encrypted access proxy. This
simplifies remote access by eliminating the use of VPNs.
 IP/MAC filtering uses ZTNA tags to provide an additional factor for identification to implement
role-based zero trust access, typically for local on-net users. For remote users, IP/MAC filtering is
paired with VPNs.
ZTNA Telemetry, Tags and Policy enforcement
2
When On-net and Off-net FortiClient endpoints register to FortiClient EMS, device information, log on
user information, and security posture are all shared over ZTNA telemetry with the EMS server. Clients
also make a certificate signing request to obtain a client certificate from the EMS that is acting as the
ZTNA Certificate Authority (CA).
Based on the client information, EMS applies matching Zero Trust tagging rules to tag the clients. These
tags, and the client certificate information, are synchronized with the FortiGate in real-time. This allows
the FortiGate to verify the client's identity using the client certificate, and grant access based on the
ZTNA tags applied in the ZTNA rule.
Access proxy
The FortiGate access proxy can proxy HTTP and TCP traffic over secure HTTPS connections with the
client. This enables seamless access from the client to the protected servers, without needing to form
IPsec or SSL VPN tunnels.
HTTPS access proxy:
The FortiGate HTTPS access proxy works as a reverse proxy for the HTTP server. When a client connects
to a webpage hosted by the protected server, the address resolves to the FortiGate’s access proxy VIP.
The FortiGate proxies the connection and takes steps to authenticate the user. It prompts the user for
their certificate on the browser, and verifies this against the ZTNA endpoint record that is synchronized
from the EMS. If an authentication scheme, such as SAML authentication, is configured, the client is
redirected to a captive portal for sign-on. If this passes, traffic is allowed based on the ZTNA rules, and
the FortiGate returns the webpage to the client.
3
TCP forwarding access proxy (TFAP):
TCP forwarding access proxy works as a special type of HTTPS reverse proxy. Instead of proxying traffic
to a web server, TCP traffic is tunneled between the client and the access proxy over HTTPS, and
forwarded to the protected resource. The FortiClient endpoint configures the ZTNA connection by
pointing to the proxy gateway, and then specifying the destination host that it wants to reach. An HTTPS
connection is made to the FortiGate’s access proxy VIP, where the client certificate is verified and access
is granted based on the ZTNA rules. TCP traffic is forwarded from the FortiGate to the protected
resource, and an end to end connection is established.
1.2 ZTNA vs traditional SSL VPN or IPsec VPN Teleworking solutions

ZTNA differs from traditional SSL VPN or IPsec VPN teleworking solutions in that it simplifies remote
access while adding additional security checks to authenticate the identity of the device and the user,
and to verify the overall security posture of the endpoint. Remote users only need to register with the
EMS server, then access the web resources directly from its browser.
Migrating from a traditional Teleworking solution to ZTNA is possible, once you understand the
components that drive the SSL VPN or IPsec VPN solution vs a ZTNA access proxy solution. Here, we
examine a SSL VPN Web and Tunnel mode solution that is pre-configured in this lab environment.
 Some AD users are members of the Remote-Allowed group in the AD fortiad.info

 These remote users can connect to the FortiGate using SSL VPN tunnel mode, and access both
the Web server and FortiAnalyzer
 Other FortiGate local users are able to connect to the FortiGate using SSL VPN web mode. They
too have HTTP access to both the Web server and FortiAnalyzer
 Any users not belonging to above groups do not remote access
In this simple scenario, it is possible to migrate to using ZTNA for HTTPS access and continue to use the
same authentication server and groups to authenticate your remote users. In addition, by integrating
with EMS, we can also ensure device identification is performed using client certificates, and security
posture is checked before allowing the remote user into the website. We can even configure ZTNA
IP/MAC filtering mode for on-net devices to provide similar access control while users are on the
network.
4
Note that in our topology, Auth, Web Server and EMS are all hosted on a Windows Server. However, in
normal circumstances, these are likely hosted on separate servers.
More advanced Teleworking scenarios

There are, of course, more advanced Teleworking setups that can achieve very similar results as the
ZTNA solution above. For example, using the built-in Host check option in the SSL-VPN portal, you can
enforce certain restrictions such as the presence of Realtime AV and/or Firewall before a host is allowed
to connect. You can also restrict by Specific OS versions.
You can also define client certificate requirements on the SSL VPN Settings page, and apply PKI users
access control. You can even apply ZTNA IP/MAC filtering on SSL VPN connections to enhance your
5
security posture check for remote teleworking users. Finally, you can define other types of
authentication like SAML for user authentication.
As we step through this lab, we will see how these are all integrated into the ZTNA solution. By default,
clients are issued client certificates from FortiClient EMS, and FortiGate verifies the client certificate
upon access. ZTNA tags are selected from the ZTNA rules to enforce security posture checks to ensure
endpoint devices meet security requirements before connecting.
1.3 Lab Topology & Preparations
Topology:
6
Devices & Networks:
Device Port/Service Address Gateway
FortiGate port1 (Clients_LAN) 10.0.1.254/24
port2 (DMZ) 10.88.0.254/24
port3 (WAN) 10.0.3.254/24 10.0.3.1
port4 (MGMT) 172.16.7.1/24
Windows Server Ethernet 10.88.0.1/24 10.88.0.254
Ethernet2 (MGMT) 172.16.7.2/24
EMS Server HTTPS 10.88.0.1:443
Web Server HTTP 10.88.0.1:8080
HTTPS 10.88.0.1:9443
FortiAnalyzer port1 10.88.0.2/24 10.88.0.254
port2 (MGMT) 172.16.7.4/24
Windows 10 Client eth1 (On-net-10.0.1.0) 10.0.1.2/24 10.0.1.254
eth2 (Remote-10.0.3.0) 10.0.3.2/24 10.0.3.1
MGMT-172.16.7.0 172.16.7.3/24
There is only one Windows 10 client in the environment. We use two network interfaces to simulate an
On-net client vs. Off-net. When acting as on-net client, set eth1 interface to enabled, and eth2 to
disabled. When acting as Remote, set eth1 interface to disabled, and eth2 to enabled.
This lab guide assumes the Windows logon user is Tom Smith in the FortiAD.Info domain. Note that this
user does not have Administrative privileges, therefore Windows UAC will prompt for credentials. You
will use the information below later in the Hands-On portion of the lab.
When changing the status of an interface, Windows will prompt for administrative privileges:
1. Open Control Panel > Network & Internet > Network Connections
2. Right click on interface, and set status to enable or disable

3. When prompted, enter:
a. Username: administrator
b. Password: fortinet
7
Logging into Windows as Administrator may bypass these UAC prompts. However, your
experience may vary against the instructions and outputs from the lab.
Users & User Groups:

In this lab, two different sets of users are defined:
Active Directory fortiad.info:
User Group (Member Of) User Password

Domain Users, Remote-Allowed Tom Smith (tsmith) fortinet
Domain Users, Remote-Allowed Roberto Kilombo (rkilombo) fortinet
Domain Users Lisa Hansen (lhansen) fortinet
FortiGate local users:
User Group User Password

sslvpn_group ljames fortinet
sslvpn_group pparker fortinet
none jarmstrong fortinet
8
1.4 Exercise: Exploring the pre-defined environment
In this exercise, the goal is to get familiar with the topology and play with the pre-defined Teleworking
setup. While most enterprise setup will have endpoints managed by EMS with endpoint profiles and
remote access pre-defined, this exercise is aimed at getting familiar with the VPN configurations.
Therefore, this lab does not assume the endpoints are managed by the EMS server, hence no remote
access tunnels are defined yet.
Getting Started in the FNDN Lab Environment

The instructor will provide you with a Passphrase for the individual lab environments. The same
Passphrase is used for everyone, but FortiDemo will provide access only to your personal lab
environment.
1. Using a web browser, access the CSE Lab at: https://fndn.fortinet.net/cse

2. Fill in the information requested including the Passphrase provided by your instructor, then
respond to the reCAPTCHA prompts and click Sign In.
9
After signing in, you will see the details of your lab. Keep this page open
in a tab in your browser as an easy reference to Your Training instance
and the administrative login IDs and passwords to the different
infrastructure components in your lab.
Tasks:
1. Initialize the lab Windows Server and Windows Client by logging into them once (the first login is
slow as they initialize their profiles. Login using the credentials in Your Training instance (see
above image)
a. On the CSE Hands On Labs web page, click Display next to Windows Server then login
with the credentials provided in the Your Training instance pane.
(administrator\fortinet)
b. Click Display next to Windows Client and login with the credentials provided in the Your
Training instance pane. (tom smith\fortinet)
c. Wait for the Windows 10 machine to initialize then:
i. Enable the eth1 (on-net) interface and disable eth2 (off-net) interface
responding to the Windows UAC prompts with administrative credentials
(administrator\fortinet)
ii. Open FortiClient and connect it to the EMS server via IP address 10.88.0.1 to
reset the expired FortiClient license. This will reenable the features needed in
the next section.
10
Review the FortiGate VPN Gateway settings, users, and policies. Establish VPN connections
Tasks:
1. Login to the FortiGate and review the existing settings.
a. Review the LDAP server, local users and user groups
b. Review the SSL-VPN Portal and SSL-VPN Settings
c. Examine the pre-defined firewall policies
2. You should be logged into the Windows 10 machine as Tom Smith. Manually establish an SSL
VPN tunnel mode connection to the Fortigate using the personal VPN feature of FortiClient:
a. Move the device back to “off-net” by ensuring eth2 is enabled, and eth1 is disabled
b. Ping the gateway at 10.0.3.254.
i. Open Command Prompt using the short cut on the Windows Task Bar. Test
communication with a ping command to 10.0.3.254
c. Establish an SSL VPN tunnel mode connection to the FortiGate using FortiClient
i. Open the FortiClient console. Under Remote Access, click Configure VPN
d. Enter the following settings and click Save
VPN SSL-VPN
Connection Name sslvpn-tunnel
Remote Gateway 10.0.3.254
Customize port Enabled. Port 10443
11
e. In the login screen, you will connect using one of the AD users belonging to the Remote-
Allowed group. Use UserID: tsmith with Password: fortinet
You will be stuck at 40% if you do not approve the SSL certificate. The
SSL certificate warning may pop-up in the background behind other
windows.
f. Once connected, open a browser and browse to the web server at

https://10.88.0.1:9443. Also browse to FAZ at https://10.88.0.2
Optional exercise: Disconnect the tunnel and try logging in with user lhansen.
Can you think of the reason the tunnel fails to connect? Hint: On the FortiGate,
what User Group does lhansen belong to? What User Groups are allowed by
policy?
3. On the Windows 10 machine, establish SSL VPN web mode connection

a. Open a browser and connect to https://10.0.3.254:10443
b. Login with UserID: ljames with Password: fortinet. Either of the local users that belong
to the sslvpn_group in the previous table will work
c. Browse to the pre-defined shortcut for Webserver
d. Browse to the pre-defined shortcut for FAZ
e. Browse to the pre-defined shortcut for EMS
12
Optional exercise: Logout from the web portal. Try logging in with user
jarmstrong. What is the outcome? Why is jarmstrong’s permission denied? Hint:
What User Group does jarmstrong belong to? What User Groups are allowed by
policy?
Review & Summary

In the previous exercise, a simple functioning example of SSL VPN setup is configured. Using LDAP
authentication, you are able to establish a tunnel mode connection with users in the Remote-Allowed
group, but failed when using a user not in the group
Using local authentication, you can login to the SSL VPN web portal to access the web resources using
users in the sslvpn_group. However, users not in this group failed to login with permission denied. This is
because the the SSL VPN Portal mapping is configured such that All Other Users/Group hits the no-
access portal.
Once this exercise is completed, disconnect your VPNs.
2. FortiGate <-> EMS <-> FCT connection

Understanding Basic ZTNA configurations
To deploy full ZTNA, the following components will be configured in order:
 Configure the FortiClient EMS and connect the FortiGate using fabric connector.
 Ensure FortiClient EMS connection is established, and ZTNA Tags can be retrieved
 On the FortiGate, configure the ZTNA Server. Here you will define the access proxy VIP and the
real servers that clients will be connecting to
 Configure a ZTNA rule to allow access
 Configure a firewall policy in Full ZTNA mode to redirect traffic to your ZTNA Server
 Configure authentication scheme and policy
The lab guide will take you through the steps in detail and explore the background concept behind each
component of the ZTNA solution.
2.1 Establishing Device Identity and Device Trust Context with FortiClient EMS
How device identity is established through client certificates, and how device trust context is established
between FortiClient, FortiClient EMS, and the FortiGate, are integral to ZTNA.
13
Device Role: FortiClient
FortiClient endpoints provide the following information to FortiClient EMS when they register to the
EMS:
 Device information (network details, operating system, model, and others)

 Logged on user information
 Security posture (On-net/Off-net, antivirus software, vulnerability status, and others)
It also requests and obtains a client device certificate from the EMS ZTNA Certificate Authority (CA)
when it registers to FortiClient EMS. The client uses this certificate to identify itself to the FortiGate.
Device Role: FortiClient EMS

FortiClient EMS issues and signs the client certificate with the FortiClient UID, certificate serial number,
and EMS serial number. The certificate is then synchronized to the FortiGate. EMS also shares its EMS
ZTNA CA certificate with the FortiGate, so that the FortiGate can use it to authenticate the clients.
FortiClient EMS uses zero trust tagging rules to tag endpoints based on the information that it has on
each endpoint. The tags are also shared with the FortiGate.
Device Role: FortiGate

The FortiGate maintains a continuous connection to the EMS server to synchronize endpoint device
information, including primarily:
 Forticlient UID
 Client certificate SN
 EMS SN
 Device credential (user/domain)
 Network (IP & MAC address and routing to the FortiGate)
14
When a device's information changes, such as when a client moves from on-net to off-net, or their
security posture changes, EMS is updated with the new device information and then updates the
FortiGate. The FortiGate's WAD daemon can use this information when processing ZTNA traffic.
Certificate management on FortiClient EMS

FortiClient EMS has a default_ZTNARootCA certificate generated by default that the ZTNA CA uses to
sign CSRs from the FortiClient endpoints. Clicking the refresh button revokes and updates the root CA,
forcing updates to the FortiGate and FortiClient endpoints by generating new certificates for each client.
Do not confuse the EMS CA certificate (ZTNA) with the SSL certificate. The latter is the server
certificate that is used by EMS for HTTPS access and fabric connectivity to the EMS server.
EMS can also manage individual client certificates. To revoke the current client certificate that is used by
the endpoint: go to Endpoint > All Endpoints, select the client, and click Action > Revoke Client
Certificate.
15
2.2 Lab Exercise: Connect FortiClient and FortiGate to EMS
Goals for this exercise:
 Configure the FortiGate, so that local and remote users can connect and register to FortiClient
EMS
 Configure the FortiGate EMS Fabric connector to connect to FortiClient EMS
 Verify the FortiGate<-->EMS connection
Configuring the FortiGate to allow local and remote access to FortiClient EMS:
To allow local FortiTelemetry access:
1. Login to the FortiGate instance with the provided credentials (see Your Training instance tab)
2. Go to Policy & Objects > Firewall Policy.
3. By default, there is a rule to allow local clients connected on LAN to access FortiClient EMS and
FAZ on DMZ. Disable this rule.
4. Create a new firewall policy called LANtoEMS-Telemetry, and configure these settings
Name LANtoEMS-Telemetry
Incoming Interface Clients_LAN (port1)
Outgoing Interface DMZ (port2)
Source All
16
Destination EMS
Schedule Always
Service PING, Telemetry
The Telemetry service must be created, with
TCP port 8013
Action Accept
NAT Disable
5. Click Ok to finish
To allow remote FortiTelemetry access from the ‘Internet’ or ‘Off-Net’:
1. Go to Policy & Objects > Virtual IPs.

2. Create a port forwarding VIP called Telemetry-VIP, and enter these settings
Name Telemetry-VIP
Interface WAN (port3)
External IP address/range 0.0.0.0
Mapped IP address/range 10.88.0.1
Port Forwarding Enabled
Protocol TCP
External service port 8013
Map to port 8013
3. Click OK to save.
4. Right-click on the new VIP object, and select “Create firewall policy using this object”
5. Create a new policy called WANtoEMS-Telemetry, and enter these settings
Name WANtoEMS-Telemetry
Incoming Interface WAN (port3)
Source All
Destination Telemetry-VIP
Schedule Always
Service Telemetry
Action Accept
NAT Disable
6. Click OK to save.
Testing FortiClient registration:
1. Login to the Windows 10 machine with the user Tom Smith, and password fortinet
2. Ensure the eth2 port is enabled, and eth1 port is disabled.
3. From the cmd prompt, ping 10.0.3.254 to verify you can reach the FortiGate WAN.
4. On the installed FortiClient, go to Zero Trust Telemetry.
5. Register to FortiClient EMS by entering its IP address 10.0.3.254. Click connect.
17
In the real world, we would create and use DNS entries and refer to EMS using an FQDN. Likely
an internal DNS record pointed to 10.88.0.1 and an external DNS record pointed to 10.0.3.254
(our simulated Internet facing interface).
Configure the FortiGate EMS Fabric connector to connect to FortiClient EMS:
1. On the FortiGate, go to Security Fabric > Fabric Connectors.

2. Click Create New and click FortiClient EMS.
3. Enter EMS-Server for connector name.
4. Enter 10.88.0.1 for the IP address of the EMS.
5. Click OK.
6. A window appears to verify the EMS server certificate. Click Accept.
7. Login to the FortiClient EMS Server using the HTTPS connection link on Your Training instance
tab.
a. Use the credentials from Your Training instance (admin/$ecurityFabric).
b. Navigate to Administration > Fabric Devices.
8. Authorize the FortiGate.
9. Back on the FortiGate, refresh the connection status and now the connection will display
Successful.
Verifying the FortiGate<->EMS connection

There are several ways to verify, besides looking at the GUI EMS Connector page. These are some
debugs that can be run on CLI:
Description Command
Verify FGT<->EMS connectivity # diag endpoint fctems test-connectivity <EMS>
Verify FortiClient EMS’s certificate # exec fctems verify <EMS>
Dump EMS connectivity info # diag test application fcnacd 2
Run real-time fcnacd debugs # diag debug app fcnacd -1
# diag debug enable
2.3 Lab Exercise: Configure EMS ZTNA tagging rules

 Configure ZTNA Rules based on presence of a file on the endpoint, and whether user is logged
into an Active Directory (AD) Domain
 Verify the ZTNA tags are sync'd between FortiClient, EMS and FortiGate
 Use debug commands to verify tags
Configuring ZTNA Rules

To configure a Zero Trust Tagging Rule for detecting a virus.txt file:
1. Login to the FortiClient EMS using provided FortiDemo credentials (admin/$ecurityFabric)
18
2. Go to Zero Trust Tags > Zero Trust Tagging Rules
3. On the top right, click +Add
4. Enter name “Malicious-File-Detected”
5. For Tag Endpoint As, manually type “Malicious-File-Detected” and press Enter
6. Add a Rule.
7. Select Windows OS
8. Select Rule Type “File”
9. Type a File name such as C:\virus.txt. Then click Save.
10. Click Save to save this Zero Trust Tagging Rule
To configure a Zero Trust Tagging Rule for detecting logged in AD = FortiAD.info:
1. Login to the FortiClient EMS using provided FortiDemo credentials (admin/$ecurityFabric)

2. Go to Zero Trust Tags > Zero Trust Tagging Rules
3. On the top right, click +Add
4. Enter name “FortiAD.Info”
5. For Tag Endpoint As, manually type “FortiAD.Info” and press Enter
6. Add a Rule.
7. Select Windows OS
8. Select Rule Type “Logged In Domain”
9. Set Domain FortiAD.Info. Then click Save.
10. Click Save to save this Zero Trust Tagging Rule
19
If you have registered and logged in to the PC as user Tom Smith from the previous exercise, Zero Trust
Tags > Zero Trust Monitor will display the Windows 10 device tagged as FortiAD.Info. If you did not login
to the domain, log out of the PC and login again now as Tom Smith.
Additionally, it is useful to display the ZTNA tags on the FortiClient itself.
To configure the ZTNA tag to display on the FortiClient:
1. In EMS, go to Endpoint Profiles > Manage Profiles. Edit the Default profile.
2. Change from Basic to Advanced settings (top right of window)
3. On the System Settings tab, under UI, enable Show Host Tag on FortiClient GUI.
4. Save changes.
On the Windows 10 FortiClient, when you click on the User avatar, this will show currently detected
Zero Trust Tags.
20
Verify ZTNA tags are sync'd between FortiClient, EMS and FortiGate
On-net Client:
Before verifying your ZTNA tags on the FortiGate, first switch the Windows 10 machine back to on-net
by disabling eth2 and enabling eth1. When the device is on-net with its gateway pointed to the
FortiGate, EMS identifies this device as directly connected, and will return the IP of the endpoints
associated with the ZTNA tags. This allows the FortiGate to display the ZTNA tags and IPs associated with
the tags on the FortiGate’s GUI.
Verify ZTNA tags on the FortiGate for endpoints that are on-net:
1. On the FortiGate, go to System > Feature Visibility and enable Zero Trust Network Access.
2. Go to Policy & Objects > ZTNA. Then navigate to the ZTNA Tags page.
3. ZTNA tags should be displayed on the page.
4. Hover over the FortiAD.Info tag to see the IP address of the endpoint.
21
5. From the CLI, use the following commands to display the dynamic addresses:
# diag firewall dynamic list
# diag firewall dynamic address
6. Use the following command to display the endpoint record for the Windows 10 device.
# diag endpoint record list
Optional: Verifying device info such as ZTNA tags in the ZTNA cache
The ZTNA cache holds information about a device, its uid, certificate S/N, gateway info, tags and more
for verifying access control over the ZTNA proxy. This info is not cached until a ZTNA connection is made
from the client. However, this can be triggered from running the following command, usually several
times.
# diag endpoint wad-comm find-by ip-vdom 10.0.1.2 root

UID:
status code:pending
Domain:
User:
Cert SN:
EMS SN:
Routes(0):
Tags(0):

UID: 9A016B5A6E914B42AD4168C066EB04CA
status code:ok
Domain: fortiad.info
User: tsmith
Cert SN:0
EMS SN: FCTEMS8821002599
Routes(1):
- route[0]: IP=10.0.1.2, VDom=root
22
Tags(3):
- tag[0]: name=all_registered_clients
- tag[1]: name=Low
- tag[2]: name=FortiAD.Info
Similarly, running the following wad debug command will display the tags for the particular endpoint.
# diag wad dev query-by uid <FortiClient UID>
Running the following command displays the ZTNA cache learned by the WAD daemon:
# diag test application fcnacd 7

ZTNA Cache:
-uid 9A016B5A6E914B42AD4168C066EB04CA: { "domain": "fortiad.info",
"user_name": "tsmith", "client_cert_sn":
"17D81F3A358D6D8C996F37B4ADF955FF946262D1", "gateway_route_list": [ {
"gateway_info": { "fgt_sn": "FGVM02TM20008184", "interface": "port1",
"vdom": "root" }, "route_info": [ { "ip": "10.0.1.2", "mac": "02-09-0f-00-
01-02", "route_type": "direct" } ] } ], "ems_sn": "FCTEMS8821002599",
"tags": [ "Low", "all_registered_clients", "FortiAD.Info" ] }
Remote Client:
When an endpoint is remote, FortiClient EMS does not return the IP info associated with its
ZTNA tags when EMS communicates with the FortiGate. Consequently, the FortiGate does not see the IP
address of the remote endpoints in the Policy & Objects > ZTNA > ZTNA Tags page. Nor does it display
the IP address from the # diag firewall dynamic list command.
To demonstrate:
1. On the Windows 10 machine, disable eth1 and enable eth2 to simulate a remote client.
2. The FortiClient will quickly connect back to the EMS server.
3. From the EMS Server, go to All Endpoints and observe the IP of the endpoint is now 10.0.3.2.
Expanding on Network Status > eth2, you should see the gateway 10.0.3.1.
4. Go to the FortiGate, and open Policy & Objects > ZTNA > ZTNA Tags.
5. Hover over the FortiAD.Info tag. The IPs of the FortiGate is not displayed
6. From the CLI run:
7. Notice that the Number of Routes: (0), meaning there are no routes pointing to FortiGate as its
gateway.
8. (Optional) From the CLI, also run the following command.
9. Notice how the output differs from when the device was on-net.
23
10. Also notice that the ZTNA tag info is available to the ZTNA cache, despite this info not appearing
on the ZTNA Tags GUI page.
Even though EMS by default does not return the IP info of endpoints that are not directly
connected to the FortiGate, this does not affect full ZTNA mode because the tags are available to the
WAD daemon and ZTNA cache. When an endpoint makes a connection to the ZTNA proxy, it looks up
the ZTNA tag from the ZTNA cache.
While this does not affect full ZTNA mode, customers looking for visibility into the remote IPs that are
associated with each tag can enable a new option in FortiClient EMS 7.0.0. Enabling this option forces all
tags to be returned to the FortiGate, regardless of whether the endpoint is directly connected.
To enable Send tag info from all FortiClients on FortiClient EMS:
1. On the FortiClient EMS, navigate to Administration > Fabric Devices

2. Select the FortiGate. Then click Edit.
3. By default, “Filter tag IPs from specific FortiGates” is checked. Uncheck this option and Save.
4. FortiClient EMS will now Send tag info from all FortiClients.
5. To observe the change on the FortiGate’s ZTNA page, either one of these must occur
a. A tag has been updated
b. Manually trigger host tags to be sync by running # diag test application
fcnacd 5
6. On the Policy & Objects > ZTNA > ZTNA Tags page, hover over FortiAD.Info to see the remote IP
have been added.
This setting is generally not recommended because of all the additional IPs that could be
returned in a large environment, as well as conflicts and overlapping that may occur when
multiple FortiGates are registered to EMS or when vdoms are used. Therefore, enable this
setting with caution.
For the remainder of this lab, it is recommended to disable the “Send tag info from all FortiClients”
setting.
3. HTTPS Access Proxy

3.1 Concept: Understanding SSL certificate based authentication
A client certificate is obtained when an endpoint registers to EMS. FortiClient automatically submits a
CSR request and the FortiClient EMS signs and returns the client certificate. This certificate is stored in
the operating system's certificate store for subsequent connections. The endpoint information is
synchronized between the FortiGate and FortiClient EMS. When an endpoint disconnects or is otherwise
unregistered from EMS, its certificate is removed from the certificate store and revoked on EMS. The
endpoint once again obtains a certificate when it is connected to EMS.
24
By default, client certificate authentication is enabled on the access proxy, so when the HTTPS request is
received, the FortiGate's WAD process challenges the client to identify itself with its certificate. The
FortiGate makes a decision based on the following possibilities:
1. Client responds with correct certificate which can extract client UID and client certificate SN
a. If the client UID and certificate SN matches the record on the FortiGate, client is allowed
to continue with ZTNA proxy rule processing.
b. If the client UID and certificate SN does not match the record on the FortiGate, client is
blocked from further ZTNA proxy rule processing.
FortiGate also has a configuration to accept or block an empty client certificate.
2. Client clicks cancel during the certificate challenge and responds with an empty client certificate
a. If the empty-cert-action is accept, client is allowed to continue with ZTNA proxy rule
processing.
b. If the empty-cert-action is block, client is blocked from further ZTNA proxy rule
processing.
The client-cert and empty-cert-action options can be configured from the CLI in 7.0.0 only.
To configure:
config firewall access-proxy
edit <name>
set client-cert { enable | disable }
set empty-cert-action { accept | block }
next
end
Example
In this example, a client connects to qa.fortinet.com and is prompted for a client certificate.
 client-cert is set to enable, and empty-cert-action is set to block.

 The ZTNA server is configured, and a ZTNA rule is set to allow this client.
 The domain resolves to the FortiGate access proxy VIP.
Scenario 1:
When prompted for the client certificate, client clicks OK and provides a valid certificate that is verified
by the FortiGate.
25
Result:
Client passes SSL certificate authentication and is allowed to the website.
Scenario 2:
When prompted for the client certificate, client clicks cancel, resulting in an empty cert response to the
access proxy.
26
Result:
Because the certificate response is empty and empty-cert-action is set to block, the WAD daemon
blocks the connection.
3.2 Lab Exercise: Configure basic HTTPS Access Proxy with SSL certificate based
authentication
In this first ZTNA server setup example, you will attempt to configure a basic setup with only SSL
certificate based authentication.
 Configure a functioning HTTPS Access Proxy for a remote user

 Locate the client certificate on the Windows machine, and match this to the info on FortiGate
and EMS
 Verify the behavior of the options set client-cert enable/disable and set
empty-cert-action accept/block
Topology:
In our topology:
 We will edit the host file in Windows to simulate a real-world URL (this is not mandatory, the IP
Address can be used, but humor us)
 We will connect to a web server running the default Windows IIS test page
 We will dedicate IP address 10.0.3.10 for the external HTTPS Access Proxy VIP address to our IIS
Web Server
To configure HTTPS access proxy VIP from the FortiGate GUI:
1. Go to Policy & Objects > ZTNA, and click on the ZTNA Servers tab.
2. Click Create New to create a new server
3. Enter name ZTNA-webserver
4. Under Network, enter the External interface port3 and External IP 10.0.3.10. Enter the external
port 9443.
27
5. Under Services and Servers, choose the Default certificate that your clients will be presented
with when connecting to the access proxy VIP. We will use Fortinet_SSL.
To define the real server mapping:
1. Under Services/server mapping, click Create New

2. For Virtual Host, select Any Host.
3. In our example, simply leave as default “/”.
Note: Specifying a Path like “/fortigate” would allow customers to match a URL such as
“webserver.mydomain.com/fortigate” for example.
4. Under Servers, click Create New to create a new server mapping.
5. Specify 10.88.0.1, and port 9443. Click OK.
6. Click OK to complete the setup.
To configure ZTNA rules to control access:
1. Go to Policy & Objects > ZTNA, and click the ZTNA Rules tab.
2. Click Create New to create a new rule
3. Enter the Name ZTNA-Allow-All.
4. Leave source as all.
5. For the time being, do not select any ZTNA tag.
6. Select a ZTNA server ZTNA-webserver.
7. Set action to Accept.
8. Enable Logging All Traffic.
9. Configure the remaining options as needed. For example, apply Security Profiles to the traffic.
10. Click Ok to complete.
To configure a firewall policy for full ZTNA:
1. Go to Policy & Objects > Firewall Policy. Click Create New.

2. Enter a name ZTNA-WAN
3. Enable the ZTNA toggle, and select Full ZTNA.
4. Configure your Incoming interface as (WAN) port3 and Source as all.
5. Select the ZTNA server ZTNA-webserver
6. Set Service to All
7. Disable NAT on the Firewall/Network Options
8. Configure the remaining settings as needed. Note that UTM processing of the underlying traffic
happens at the ZTNA Rule.
Review the CLI configs that were generated:

config firewall vip
edit "ZTNA-webserver"
set type access-proxy
set extip 10.0.3.10
set extintf "port3"
set server-type https
set extport 9443
set ssl-certificate "Fortinet_SSL"
28
next
end
set vip "ZTNA-webserver"
set client-cert enable
config api-gateway
edit 1
set service https
config realservers
edit 1
set ip 10.88.0.1
set port 9443
next
end
next
end
next
end
config firewall proxy-policy
edit 1
set name "ZTNA-Allow-All"
set proxy access-proxy
set access-proxy "ZTNA-webserver"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set logtraffic all
next
end
config firewall policy
edit 6
set name "ZTNA-WAN"
set srcintf "port3"
set dstintf "any"
set srcaddr "all"
set dstaddr "ZTNA-webserver"
set action accept
set service "ALL"
set inspection-mode proxy
set logtraffic all
next
end
Testing the remote access to the HTTPS access proxy

Now that the FortiClient EMS and FortiGate are configured, it is time to test the HTTPS access proxy
remote connection.
Configure the host file to map webserver.ztnademo.com to 10.0.3.10:
29
1. On the Windows 10 device, ensure that you are connected to the remote network (eth2
enabled, eth1 disabled)
2. Using the Windows Search on the Windows Task bar, search for Notepad then Right Click on the
Notepad icon and choose Open as administrator and authenticate with the administrator
credentials.
3. Choose File, Open in Notepad - locate and open the hosts file under
C:\Windows\System32\drivers\etc\hosts
4. Create a new line:
10.0.3.10 webserver.ztnademo.com
5. Save the file.
6. From command prompt, ping webserver.ztnademo.com. Verify it resolves to 10.0.3.10. The
actual ping will not be successful – you just want to be sure that it resolves a simulated DNS
entry.
Testing the connection
1. Open the FortiClient App. Under Zero Trust Telemetry, ensure you are connected to the EMS
server via 10.0.3.254.
2. Open up the Microsoft Edge browser. Type https://webserver.ztnademo.com:9443
Note: You may use Chrome browser, however any bookmark / shortcuts there are not
accurate
3. First, you will receive a warning that the connection is not private (secure). If you show the
certificate, you will see this matches the Fortinet_SSL Factory certificate specified in the ZTNA
server configs. Click Advanced, and continue to webserver.ztnademo.com
4. The browser will prompt for the client certificate to use. Choose the EMS signed certificate and
click OK
30
5. The webpage should now be opened.
Optional tasks:
 Try also creating the HTTPS Access Proxy for EMS portal and FortiAnalyzer GUI access
 In Forward Traffic logs, look for logs that allowed your traffic to the web server (Hint: Look for
Policy Type: proxy-policy)
Locating the certificate in the certificate store, and matching the certificate on FortiGate and
EMS
1. Open windows search and look for User Certificate. Open Manage User Certificates.
31
2. In the User Certificate store, open folder Personal > Certificates.
3. Choose the FCT issued cert and view its properties by double-clicking the cert. Looking at
Details, you will find the SN of the certificate, which matches the record on FortiClient EMS and
the FortiGate.
32
4. Looking at Details, find the SN of the certificate.
5. On the FortiGate use the following command to get the matching SN for the endpoint record for
this device. Note other matching info

Record #1:
IP Address = 10.0.3.2
MAC Address = 02:09:0f:00:03:03
MAC list = 02:09:0f:00:04:03;02:09:0f:00:03:03;
VDOM = (-1)
EMS serial number: FCTEMS8821002599
Client cert SN: 35483DF3F37BDD4E3E15284409F840E99B717C07
Public IP address: 35.237.65.68
Quarantined: no
Online status: online
Registration status: registered
On-net status: on-net
Gateway Interface:
FortiClient version: 7.0.0
AVDB version: 1.0
FortiClient app signature version: 13.364
FortiClient vulnerability scan engine version: 2.30
FortiClient UID: 9A016B5A6E914B42AD4168C066EB04CA
Host Name: LISAHANSEN
OS Type: WIN64
OS Version: Microsoft Windows 10 Professional Edition, 64-bit
(build 19042) (version 2009)
Host Description:
Last Login User: tsmith
…
online records: 1; offline records: 0; quarantined records: 0
6. Other commands that return the Certificate SN:

ZTNA Cache:
-uid 9A016B5A6E914B42AD4168C066EB04CA: { "tags": [
"all_registered_clients", "Low", "FortiAD.Info" ], "domain":
"fortiad.info", "user_name": "tsmith", "client_cert_sn":
"35483DF3F37BDD4E3E15284409F840E99B717C07", "ems_sn":
"FCTEMS8821002599" }
# diag endpoint wad-comm find-by uid 9A016B5A6E914B42AD4168C066EB04CA

status code:ok
User: tsmith
Cert SN:35483DF3F37BDD4E3E15284409F840E99B717C07
Routes(0):
Tags(3):
33
- tag[1]: name=Low
7. Finally, on the FortiClient EMS, locate the device under Endpoints > All Endpoints. Under
Configuration, the fields FortiClient ID and ZTNA Serial Number displays matching info as the
FortiClient and FortiGate
Verify the behavior of the options set client-cert enable/disable and set empty-cert-action
accept/block
By default, the access proxy is configured to enable client-cert, and accept empty-cert-action.
# show full firewall access-proxy
set vip "ZTNA-webserver"
set empty-cert-action accept
next
end
In 7.0.1, empty-cert-action will default to block
34
As a test, try the following:
1. Clear your web browser cache, and restart the browser.

2. Access https://webserver.ztnademo.com:9443
3. When prompted for the cert, click cancel.
Does the page continue to load?
This behavior will be similar to when a device without FortiClient installed tries to open the webpage.
FortiGate challenges the client for a cert. When the client does not provide a client cert due to no
FortiClient installed, or user manually clicks cancel, a null cert is returned in response. The webpage
loads.
Next, experiment with setting empty-cert-action to block. Clear your browser cache and repeat the
steps above. What behavior do you see? Your page should now be blocked. This is the same outcome
for users with no FortiClient or unsupported FortiClient version.
Finally, experiment with setting client-cert disabled. Clear your browser cache and repeat the same
steps. What behavior do you see? Notice that the browser does not prompt you for a certificate.
Review & Summary

In review, in this basic setup, client certificate is used to verify the identity of the endpoint to
authenticate the device. These following debugs help verify the presence of matching endpoint records
and info such as client UID and client certificate SN on the FortiGate. If these info are missing or
incomplete, client certificate authentication may fail. Further diagnosis may be needed to determine the
reason for the missing record.
Description Command
Display endpoint record list, and # diagnose endpoint record list <ip>
optionally filter by endpoint IP
Query endpoint by client UID # diagnose endpoint wad-comm find-by uid

<uid>
Query endpoint by client ip-vdom pair # diagnose endpoint wad-comm find-by ip-vdom
<ip> <vdom>
Query from wad diagnose command by # diagnose wad dev query-by uid <uid>
uid
Query from wad diagnose command by # diagnose wad dev query-by ipv4 <ip>
IP
Check fcnacd ZTNA and route cache # diagnose test application fcnacd 7
# diagnose test application fcnacd 8
3.3 Lab Exercise: Configure HTTPS Access Proxy with basic local user authentication and
ZTNA tags
In this exercise, we will extend the solution to include performing user authentication with local users,
and Security Posture checks with ZTNA tags.
35
 Configure local user authentication using authentication scheme and authentication rules
 Configure ZTNA rules to apply security posture check using ZTNA tags
 Verify user authentication for a user
 Verify the behavior when security posture changes
Topology:
In our topology:
 We will re-use the local user and group definitions for user authentication
 Use the ZTNA tags defined in previous lab exercises
FortiGate local users:
User Group User Password

sslvpn_group ljames fortinet
sslvpn_group pparker fortinet
none jarmstrong fortinet
Configure local user authentication

Authentication scheme and rules:
An Authentication scheme and rule have to be configured in order to trigger user authentication. The
Authentication scheme defines what method of authentication will be applied. It is similar to how
authentication is performed for Explicit Proxy. Currently, ZTNA supports basic and SAML methods. In our
example, basic HTTP authentication is used, so users will be prompted for username and password
when they first connect to a webpage through the HTTPS access proxy.
To configure an authentication scheme from GUI:
1. From System > Feature Visibility, enable Explicit Proxy in order for the Authentication Rules page
to be visible.
36
2. Go to Policy & Objects > Authentication Rules, and select Authentication Schemes from the top
right.
3. Click Create New > Authentication Scheme.
4. Enter Name ZTNA-Auth-scheme.
5. Select Method Basic.
6. Leave User Database as Local.
7. Click OK to complete.
An authentication rule specifies which proxy sources and destinations will require authentication, and
which authentication scheme to apply. In our example, we will use active authentication through the
basic HTTP prompt, and apply to all sources.
To configure an authentication rule from GUI:
1. Select Authentication Rules from the top right.

2. Click Create New > Authentication Rules.
3. Enter Name ZTNA-Auth-rule.
4. Select Source Address to All.
5. Leave Protocol as HTTP.
6. Enable Authentication Scheme, and select ZTNA-Auth-scheme.
Applying the user group to a ZTNA rule:

A user or user group must be applied to a ZTNA rule(s) in which you want to control user access. The
authenticated user from the authentication scheme and rule must match the user or user group in the
ZTNA rule.
To apply a user group to the ZTNA rules:
1. Go to Policy & Objects > ZTNA > ZTNA Rules. Edit ZTNA-Allow-All.
2. Under Source, add a new entry. On the slide-in window, select User. Then choose sslvpn_group.
Configure ZTNA rules to apply security posture check using ZTNA tags
So far we have not used ZTNA tags in our policy. In this exercise, we will modify the ZTNA rule to allow
users who are logged into FortiAD.Info domain, and deny users whose security is compromised with the
Malicious-File-Detected tag.
To apply ZTNA tag in our Allow rule:
2. Under ZTNA Tag, select the FortiAD.Info tag.
To create a Deny rule above the Allow rule:
1. Create a new rule called ZTNA-Deny-Malicious.
37
2. Set source All, and user sslvpn_group.
3. Under ZTNA Tag, select the Malicious-File-Detected tag.
4. Under ZTNA Server, select ZTNA-webserver.
5. Set Action to Deny.
6. Enable Log Violation traffic.
8. Move this policy above the ZTNA-Allow-All policy.
Insert empty policy above a ZTNA rule does not work in 7.0.0
Testing the remote access to the HTTPS access proxy with user authentication
Now that user authentication is configured on the FortiGate, it is time to test the HTTPS access proxy
remote connection.
Test 1: Access allowed using a user in the sslvpn_group
1. On the Windows 10 machine, ensure network adapter is configured to be remote. Ensure user is
connected to the EMS server.
2. Open Windows Edge. Clear any previous cache.
3. Browse to https://webserver.ztnademo.com:9443.
4. The browser will prompt for the client certificate to use. Choose the EMS signed certificate and
click OK.
5. The client certificate will be verified by the FortiGate to authenticate your identity. When that
passes, user will be prompted for their username and password.
6. Enter username/password and Sign in.

7. After user authentication passes, the FortiGate will perform a posture check on the ZTNA group.
8. Once that passes, user will be allowed access to the website.
9. Clear your cache, and close the browser.
10. Check the FortiGate forward traffic logs.
38
11. Go to Dashboard > Users & Devices. Open the Firewall Users widget.
12. Note the user and the Method in which it is logged in. Similarly, using command # diag
firewall auth list displays the logged in user.
13. In the GUI, right click on the user and click Deauthenticate. Click OK to confirm.
Test 2: Access denied using a user that does not belong to the sslvpn_group
1. Repeat the previous steps to access https://webserver.ztnademo.com:9443.

2. Choose user jarmstrong, and authenticate.
3. This user will result in the Access Denied page. The page you requested has been blocked by a
firewall policy restriction.
4. Clear your cache, and close the browser.
5. Check the FortiGate forward traffic logs to see the Deny traffic log
6. Check the Firewall Users widget. Is the user logged in? Why does this user get denied?
7. Deauthenticate this user before moving to the next test.
Verify the behavior when Security Posture changes

In this test, you will create a file under C:\virus.txt to simulate an event that triggers the Malicious-File-
Detected tag to be detected.
1. Open the notepad as an administrator. Create some dummy text.

2. Save the file on C:\virus.txt.
3. On the FortiClient, click your avatar to view the currently detected tags. It may take a minute to
see the tag updated.
39
4. Open the browser. If you have not cleared your cache from the previous session, clear it now
and re-open the browser.
5. Browse to https://webserver.ztnademo.com:9443.
6. Login as a valid user.
7. Even after the user is authenticated, the user is denied access.
8. In what ways can you confirm user was successfully authenticated from FortiGate GUI and CLI?
9. Can you confirm which policy was used to deny the user?
10. From CLI, can you use debugs from previous exercises to identify what are the tag(s) associated
with the endpoint?
Once the exercise is complete, remove the C:\virus.txt file and deauthenticate the user from the
FortiGate.
Review & Summary

By this exercise, you should be familiar with the sequence of events that occur before a user is
allowed/denied access. First, client certificate authentication takes place. Second, user authentication
takes place. Logged in user is checked against user group in the ZTNA rule. Lastly, ZTNA tags are checked
to determine the matching rule.
40
3.4 Lab Exercise: Configure HTTPS Access Proxy with LDAP user authentication and ZTNA
tags
In this exercise, you will configure LDAP user authentication to replace the previous local user
authentication.
 Re-configure previous lab exercise to use LDAP instead

 Verify user authentication using Active Directory users
Topology:
Active Directory fortiad.info:
User Group (Member Of) User Password

Domain Users, Remote-Allowed Tom Smith (tsmith) fortinet
Domain Users, Remote-Allowed Roberto Kilombo (rkilombo) fortinet
Domain Users Lisa Hansen (lhansen) fortinet
Configure LDAP user authentication

Update the previous example to use the pre-configured LDAP server LDAP-fortiad.
To configure an authentication scheme from GUI:
1. Go to Policy & Objects > Authentication Rules, and select Authentication Schemes from the top
right.
2. Edit ZTNA-Auth-scheme.
3. Change User Database to Other.
4. Select the LDAP server LDAP-fortiad.
The authentication rule will remain the same, as it triggers the ZTNA-Auth-scheme for basic
authentication.
41
The user group in which you want to control access must also be applied to the ZTNA rule(s). The group
returned by the LDAP server from the authentication scheme and rule must match the user or user
group in the ZTNA rule. In this exercise, use the pre-defined LDAP user group called LDAP-Remote-
Allowed-Group.
To apply the user group to the ZTNA rules:
2. Under Source, remove sslvpn_group and add LDAP-Remote-Allowed-Group.
4. Next, edit the ZTNA-Deny-Malicious rule and repeat the steps above.
Testing the remote access to the HTTPS access proxy with user authentication
Using the steps from the previous exercise, try accessing the webpage again using different AD users.
4. TCP Forwarding Access Proxy

4.1 Concept: Understanding TCP Forwarding Access Proxy
Now that you are familiar with the concept of HTTPS Access Proxy, the idea of a TCP Forwarding Access
Proxy is also very similar. TCP forwarding access proxy works as a special type of HTTPS reverse proxy.
TCP traffic is tunneled between the client and the access proxy over HTTPS, and forwarded to the
protected resource over TCP using the original upper layer protocol.
To illustrate, in the above example, an end user tries to RDP to a windows server on 10.88.0.1. An HTTPS
connection is made to the FortiGate’s access proxy VIP, where the client certificate is verified and access
is granted based on the ZTNA rules. The FortiGate proxies this connection, and forwards the actual
TCP/3389 traffic from the FortiGate to the protected resource. Therefore, to establish the end to end
connection, it is broken into 2 sessions with FortiGate acting as the reverse proxy for the protected
resource.
42
4.2 Lab Exercise: Configure basic TCP Forwarding Access Proxy for RDP and SSH
In this example, you will attempt to configure TCP Forwarding on the FortiGate, and the corresponding
ZTNA Connection Rules on the FortiClient to proxy the connections to the access proxy.
 Configure a functioning TCP Forwarding Access Proxy to SSH to the FortiAnalyzer

 Configure a functioning TCP Forwarding Access Proxy to RDP to the Windows server
 Analyze the traffic that flows between the Remote client and the respective servers
Topology:
In our topology:
 We will dedicate IP address 10.0.3.11 and port 8443 for the external Access Proxy VIP address
7.0.0 does not fully support TCP Forwarding Access Proxy configurations from the GUI.
Therefore, the following exercise will attempt to configure the access proxy configurations
from CLI. Once created, you may view in the GUI but do not make changes there and do not
expect the GUI to reflect your CLI config.
Configure a functioning TCP Forwarding Access Proxy to SSH to the FortiAnalyzer

To configure VIP and Access Proxy from the FortiGate CLI:
config firewall vip
edit "ZTNA-tcp-server"
set type access-proxy
set extip 10.0.3.11
set extintf "port3"
set server-type https
set extport 8443
set ssl-certificate "Fortinet_SSL"
next
end
43
set vip "ZTNA-tcp-server"
config api-gateway
edit 1
set service tcp-forwarding
config realservers
edit 1
set address "FAZ"
set mappedport 22
next
end
next
end
next
end
Note:
1. The mapped addresses must be address objects. Therefore, we use the FAZ address that was
created before.
2. The mappedport specifies which port is allowed to be used here. A mappedport can be a port, or
a port range. If unspecified, then any port is allowed.
To configure ZTNA rules to control access:
3. Enter the Name ZTNA-TCP.
4. Leave source as all.
5. Do not select any ZTNA tag.
6. Select the ZTNA server ZTNA-tcp-server.
To configure a firewall policy for full ZTNA:
1. Go to Policy & Objects > Firewall Policy. Click Create New.

2. Enter a name ZTNA-TCP
3. Enable the ZTNA toggle, and select Full ZTNA.
4. Configure your Incoming interface as (WAN) port3 and Source as all.
5. Select the ZTNA server ZTNA-tcp-server
6. Set Service to All
7. Disable NAT on the Firewall/Network Options
8. Configure the remaining settings as needed.
44
Review the remaining CLI configs that were generated:
config firewall proxy-policy
edit 3
set name "ZTNA-TCP"
set proxy access-proxy
set access-proxy "ZTNA-tcp-server"
set srcaddr "all"
set dstaddr "all"
set action accept
set logtraffic all
next
end
edit 9
set name "ZTNA-TCP"
set srcintf "port3"
set dstintf "any"
set srcaddr "all"
set dstaddr "ZTNA-tcp-server"
set action accept
set service "ALL"
set inspection-mode proxy
set logtraffic all
next
end
To configure ZTNA Connection Rules on the FortiClient:
1. Open the FortiClient on the Windows 10 machine

2. Go to ZTNA Connection Rules, and click Add Rule.
3. Configure the following settings:
Rule Name SSH-FAZ

Destination Host 10.88.0.2:22
Proxy Gateway 10.0.3.11:8443
Mode Transparent
Your Destination Host is the real IP address and port of the server
4. Click Create
Without configuring this rule, your Windows machine will not proxy your connection to 10.88.0.2
through the FortiGate, and the connection will fail.
Testing remote access to the TCP forwarding access proxy

In this basic example, we did not configure any ZTNA tags or additional authentication. We will simply
connect via SSH to the FortiAnalyzer on 10.88.0.2.
45
1. Ensure that your eth2 is connected, and eth1 is disabled.

3. Open Windows Command prompt using the shortcut on the Task Bar and test an SSH session to
FortiAnalyzer.
4. At the prompt, type: ssh admin@10.88.0.2
5. Reply to the RSA key fingerprint warning with ‘Yes’
6. Login as “admin”, password “fortinet”
7. You should receive a FortiAnalyzer CLI login prompt. This signals that the connection is
successful.
Analyzing the traffic
Now that the connection is made, let’s examine the traffic from the FortiGate. We will sniff for traffic on
the WAN (port3) interface, and then on the DMZ (port2) interface.
1. Open the FortiGate CLI console from the GUI

2. Type the following command:
# diag sniffer packet port3 'host 10.0.3.11' 4 0 l
3. Minimize this CLI console and open another one
4. Type the following command in the second console:
# diag sniffer packet port2 'host 10.88.0.2' 4 0 l
5. Go back to the Windows 10 client where you have the SSH session opened.
6. Type in any commands and press enter. For example, get sys stat
7. On the FortiGate CLI consoles, you will see some outputs similar to the following:
FortiGate-VM64-KVM # diag sniffer packet port3 'host 10.0.3.11' 4 0 l
Using Original Sniffing Mode
46
interfaces=[port3]
filters=[host 10.0.3.11]
2021-05-26 16:25:48.199356 port3 -- 10.0.3.2.64946 -> 10.0.3.11.8443: psh
394280683 ack 3444512781
2021-05-26 16:25:48.199432 port3 -- 10.0.3.11.8443 -> 10.0.3.2.64946: ack
394280769
2021-05-26 16:25:48.202454 port3 -- 10.0.3.11.8443 -> 10.0.3.2.64946: psh
3444512781 ack 394280769
2021-05-26 16:25:48.245333 port3 -- 10.0.3.2.64946 -> 10.0.3.11.8443: ack
3444512867
...
FortiGate-VM64-KVM # diag sniffer packet port2 'host 10.88.0.2' 4 0 l

Using Original Sniffing Mode
interfaces=[port2]
filters=[host 10.88.0.2]
2021-05-26 16:25:48.199968 port2 -- 10.88.0.254.13813 -> 10.88.0.2.22: psh
3667788748 ack 3589909222
2021-05-26 16:25:48.202236 port2 -- 10.88.0.2.22 -> 10.88.0.254.13813: psh
3589909222 ack 3667788812
2021-05-26 16:25:48.202291 port2 -- 10.88.0.254.13813 -> 10.88.0.2.22: ack
3589909286
...
As you can see from the above captures, the WAN interface (port3) has a connection with the client
(10.0.3.2) over port 8443, which is the HTTPS port that we defined in the access-proxy VIP
configurations.
On the other end, between the FortiGate and the FortiAnalyzer, the TCP connection on port 22 is
established.
If traffic is not passing the TCP Access Proxy, you can use the above sniffer commands to verify where
the problem lies. Whether the connection isn’t being established between the FortiClient and FortiGate,
or between the FortiGate and the protected resource.
Configure a functioning TCP Forwarding Access Proxy to RDP to the Windows server
In this next task, we will piggy back on the previous configurations, and add to it a mapping to the
Windows server. Some settings such as the VIP, ZTNA rule and firewall rule do not need to be modified.
Only the necessary additions are described below
To configure access proxy from the FortiGate CLI:

config api-gateway
edit 1
config realservers
edit 2
set address "EMS"
set mappedport 3389
next
end
47
next
end
next
end
Note:
In the access-proxy configurations, in order for both mapped servers to work concurrently, they must be
defined under the same api-gateway. Therefore, in the example above we have defined another
realserver mapping to the Windows server with port 3389.
To configure ZTNA Connection Rules on the FortiClient:
1. Open the FortiClient on the Windows 10 machine

2. Go to ZTNA Connection Rules, and click Add Rule.
3. Configure the following settings:
Rule Name RDP-EMS

Destination Host 10.88.0.1:3389
Proxy Gateway 10.0.3.11:8443
Mode Transparent
Your Destination Host is the real IP address and port of the server
4. Click Create
To configure the Windows server to allow Remote Desktop:
The lab environment was not pre-configured to allow Remote Desktop from other machines. Therefore,
this step is required to manually enable it.
1. Open the Windows server and login as administrator with password fortinet.
2. Before allowing Remote Desktop, Windows server requires that you first enable the Windows
Firewall process.
a. Open up Administrative Tools
b. Open Services
c. In the Services Window, scroll to near the bottom to locate the service Windows
Firewall
d. Double-click to open its Properties
e. Change Startup Type to Manual, and click Apply
f. Click the Start button to start the service. Then click OK
3. Open Server Manager, and go to the Local Server
4. Under Properties, locate Remote Desktop, and click on the value “Disabled”.
5. In the System Properties window, under the Remote Tab > Remote Desktop, select “Allow
remote connections to this computer”. This allows users in the Administrator group by default
6. Click OK to finish
48
1. Ensure that your eth2 is connected, and eth1 is disabled.
3. From Windows Search, search for Remote Desktop Connection, and open the app
4. Enter the IP of the Windows server 10.88.0.1 in the Computer field.
5. Click connect to start the connection
6. The user tsmith is in the Administrator group. Use his credentials to login
7. You are now successfully logged via RDP
Analyzing the traffic
Once again, you can analyze the traffic by sniffing the traffic on the FortiGate. Modify the sniffer
commands from the first example to reflect this new example.
Reviewing the logs
As usual, the Forward Traffic log will record the sessions once the RDP session is terminated. To view
from the GUI, go to Log & Report > Forward Traffic. Identify the log below:
49
Similarly, from CLI:
# exec log filter category 0
# exec log display
105: date=2021-05-26 time=17:21:45 eventtime=1622074905286537767 tz="-0700"
logid="0000000010" type="traffic" subtype="forward" level="notice" vd="root"
srcip=10.0.3.2 srcport=65052 srcintf="port3" srcintfrole="wan"
dstcountry="Reserved" srccountry="Reserved" dstip=10.88.0.1 dstport=3389
dstintf="root" dstintfrole="undefined" sessionid=9587 service="RDP"
wanoptapptype="web-proxy" proto=6 action="accept" policyid=3
policytype="proxy-policy" poluuid="fe0e1ae8-bdf9-51eb-b86f-c5e2adb934b3"
duration=19 wanin=47658 rcvdbyte=47658 wanout=33884 lanin=38950
sentbyte=38950 lanout=53284 appcat="unscanned"
4.3 Lab Exercise: Configure authentication and security posture check for TCP Forwarding
Access Proxy
In this exercise, you will add to the previous configurations by configuring ZTNA tags and authentication
in the ZTNA rule. While ZTNA authentication is redundant in these scenarios, since both SSH and RDP
requires in app authentication, this step demonstrates the end user experience when authentication is
applied.
 Implement Authentication & Security Posture check for the SSH and RDP connections added in
the previous exercise
In our topology:
 We will also re-use the LDAP groups previously configured in Section 3 of this lab guide
 We will continue to use the authentication rule and scheme used in Section 3 of this lab guide
Implement Authentication & Security Posture check for the SSH and RDP connections added in
the previous exercise
In the following configurations, we will disable the ZTNA-TCP ZTNA rule, and create 2 rules to Deny
Malicious and Allow traffic that passed the Security Posture check.
50
To configure a ZTNA rule to Deny Malicious access:
2. Disable the ZTNA-TCP rule but right-clicking the rule, and Set Status Disable
4. Enter the Name ZTNA-TCP-Deny-Malicious.
5. For Source, click +, and navigate to the User tab in the slide-in. Then choose LDAP-Remote-
Allowed-Group.
6. For ZTNA Tag, select Malicious-File-Detected.
8. Set action to DENY.
9. Enable Logging Violation Traffic.
To configure a ZTNA rule to Allow access:

2. Enter the Name ZTNA-TCP-Allow-All
3. For Source, click +, and navigate to the User tab in the slide-in. Then choose LDAP-Remote-
Allowed-Group.
4. For ZTNA Tag, select FortiAD.Info.
Testing remote access to the TCP forwarding access proxy

In this exercise, we implemented authentication and security posture check. On the Windows machine,
verify that you are connected to EMS, and the Zero Trust Tags is currently showing FortiAD.Info
Testing the Allowed connection
1. On the Windows 10 machine, open the Windows Command prompt from the Taskbar shortcut.
2. At the prompt, type: ssh admin@10.88.0.2
3. The connection will trigger a FortiClient login prompt to popup. Enter your credentials to sign-in
51
4. Once you pass this authentication, you will be prompted for the SSH session’s login. Enter the
credentials admin/fortinet in the Command prompt window.
5. You are now connected to the FortiAnalyzer via SSH.
6. Next, connect to the Windows server over RDP by opening the Remote Desktop app
7. Enter the server ip 10.88.0.1, and click Connect
8. Again, you will be presented with the FortiClient Sign-in prompt. Enter your credentials to sign-
in.
9. Once you pass this authentication, the Remote Desktop app will prompt you for your Windows
server authentication credentials. Enter them to connect to the Windows server
10. You are now connected to the Windows server via RDP
Once the tests are complete, you can disconnect from both sessions.
Reviewing the logs
To view the logs from the GUI, go to Log & Report > Forward Traffic. Identify the logs below:
52
(Optional) Testing the Disallowed connection
1. On the Windows 10 machine, create a file under c:\virus.txt
2. Open your FortiClient, and go to the profile page. Within a minute, the Zero Trust Tags should
display the new tag called Malicious-File-Detected
3. Open the Windows Command prompt and try connecting to FAZ on 10.88.0.2
4. The connection will be blocked.
5. Open Remote Desktop and try connecting to 10.88.0.1
6. This connection will also be blocked.
7. Check the FortiGate’s Forward Traffic logs. You should see a log similar to the one below:
53
Once you have completed this test, remove the C:\virus.txt file to return the security posture back to
normal.
5. ZTNA IP/MAC filtering mode

When configuring a firewall policy, notice that toggling ZTNA provides you options of Full ZTNA and
IP/MAC filtering modes. So far, the exercises have been centered around Full ZTNA for remote users.
However, when devices are physically on the corporate network Full ZTNA Access Proxy is unnecessary.
Instead, using IP/MAC filtering, we can enhance security over your typical firewall policies by adding the
Security Posture check element.
5.1 (Optional) Lab Exercise: Basic ZTNA IP/MAC filtering example on on-net users
In this exercise, you will configure new Clients_LAN -> DMZ policies that apply Security Posture check
using ZTNA tags.
 Configure new firewall policies to apply ZTNA tags

 Verify the changes to endpoint information when device is brought on-net
 Verify access is controlled with ZTNA tags
Topology:
54
To configure a firewall policy in ZTNA IP/MAC filtering mode to block access:
1. Go to Policy & Objects > Firewall Policy and Click Create New.
2. Configure the following fields:
Name LANtoDMZ-BlockMalicious
ZTNA IP/MAC filtering
ZTNA Tag Malicious-File-Detected
Source All
Destination EMS
Schedule Always
Service All
Action DENY
Log Violation Traffic Enable
In 7.0.0, ZTNA configurations does not get saved from GUI. It is possible to workaround this in
the Firewall Policy summary page, or from the CLI
To workaround in GUI:
1. From the Firewall Policy summary page, add 2 new columns by right clicking on the column
header. Add Enforce ZTNA and ZTNA Tag
2. Edit the Enforce ZTNA field for the policy LANtoDMZ-BlockMalicious and set to Enabled
3. Edit the ZTNA Tag field for the policy and select the tag Malicious-File-Detected
55
To workaround in CLI:
edit 7
set ztna-status enable
set ztna-ems-tag "FCTEMS8821002599_Malicious-File-Detected"
next
end
To configure a firewall policy in ZTNA IP/MAC filtering mode to allow access:
1. Go to Policy & Objects > Firewall Policy and Click Create New.
2. Configure the following fields:
Name LANtoDMZ-Allowed
ZTNA IP/MAC filtering
ZTNA Tag FortiAD.Info
Source All
Destination EMS
Schedule Always
Service All
Action Accept
NAT Disable
Log Allowed Traffic All Sessions
To workaround in GUI:
1. From the Firewall Policy summary page, edit the Enforce ZTNA field for the policy LANtoDMZ-
Allowed and set to Enabled
2. Edit the ZTNA Tag field for the policy and select the tag FortiAD.Info
To workaround in CLI:
edit 8
set ztna-status enable
set ztna-ems-tag " FCTEMS8821002599_FortiAD.Info"
next
end
Verify the changes to endpoint information when device is brought on-net

On the Windows 10 machine, disable eth2 and enable the eth1 adapter to simulate the device being
brought on-net. Ensure EMS is still connected from the FortiClient.
From the CLI, examine the output of these debug commands:
56
The Online and On-net status, combined with the presence of the Gateway Route indicate the device is
on the network and pointing to the FortiGate port1 as its gateway.

Record #1:
IP Address = 10.0.1.2
MAC Address = 02:09:0f:00:01:02
MAC list = 02:09:0f:00:04:03;02:09:0f:00:03:03;
VDOM = root (0)
EMS serial number: FCTEMS8821002599
Client cert SN: 35483DF3F37BDD4E3E15284409F840E99B717C07
Public IP address: 35.237.65.68
Quarantined: no
Online status: online
Registration status: registered
On-net status: on-net
Gateway Interface: port1
FortiClient version: 7.0.0
AVDB version: 1.0
FortiClient app signature version: 13.364
FortiClient vulnerability scan engine version: 2.30
FortiClient UID: 9A016B5A6E914B42AD4168C066EB04CA
Host Name: LISAHANSEN
OS Type: WIN64
OS Version: Microsoft Windows 10 Professional Edition, 64-bit (build
19042) (version 2009)
Host Description:
Last Login User: tsmith
Owner:
Host Model: Standard PC (i440FX + PIIX, 1996)
Host Manufacturer: QEMU
CPU Model: Intel(R) Xeon(R) CPU @ 2.20GHz
Memory Size: 0
AV Feature: 1
FW Feature: 1
WF Feature: 1
AS Feature: 0
VS Feature: 1
VN Feature: 1
Last vul message received time: Mon Apr 26 12:30:26 2021
Last vul scanned time: Fri Apr 23 00:23:36 2021
Last vul statistic: critical=0, high=0, medium=0, low=0, info=0
Avatar fingerprint: 05b9940c015425a375caafa28096d695be6e9ad2
Avatar source username:
Avatar source email:
Avatar source: OS
Phone number:
Number of Routes: (1)
Gateway Route #0:
- IP:10.0.1.2, MAC: 02:09:0f:00:01:02, Indirect: no
- Interface:port1, VFID:0, SN: FGVM02TM20007391
online records: 1; offline records: 0; quarantined records: 0
57
Again the presence of the gateway_route_list, a gateway pointing to FortiGate’s port1 and t route_type
“direct” indicate this device is recognized as on-net by the FortiGate.

ZTNA Cache:
-uid 9A016B5A6E914B42AD4168C066EB04CA: { "tags": [ "all_registered_clients",
"Low", "FortiAD.Info" ], "domain": "fortiad.info", "user_name": "tsmith",
"client_cert_sn": "35483DF3F37BDD4E3E15284409F840E99B717C07",
"gateway_route_list": [ { "gateway_info": { "fgt_sn": "FGVM02TM20007391",
"interface": "port1", "vdom": "root" }, "route_info": [ { "ip": "10.0.1.2",
"mac": "02-09-0f-00-01-02", "route_type": "direct" } ] } ], "ems_sn":
"FCTEMS8821002599" }

This is another way to verify this info from wad.

status code:ok
User: tsmith
Cert SN:35483DF3F37BDD4E3E15284409F840E99B717C07
Routes(1):
- route[0]: IP=10.0.1.2, VDom=root
Tags(3):
- tag[1]: name=Low

The following firewall dynamic list shows IP addresses for ZTNA tags detected for FortiClient EMS.
List all dynamic addresses:
FCTEMS8821002599_Firewall-Enabled: ID(59)
FCTEMS8821002599_all_registered_clients: ID(68)
ADDR(10.0.1.2)
ADDR(172.16.7.3)
FCTEMS8821002599_Critical: ID(88)
FCTEMS8821002599_Low: ID(351)
ADDR(10.0.1.2)
ADDR(172.16.7.3)
58
…
FCTEMS8821002599_FortiAD.Info: ID(112)
ADDR(10.0.1.2)
ADDR(172.16.7.3)
…
In the case that these tags do not appear, you may need to work around this by:
1. Re-registering your FortiClient

2. From FortiGate, run # diag endpoint wad-comm find-by ip-vdom 10.0.1.2 root
Verify access is controlled with ZTNA tags

Test 1: Allowed based on Security Posture check:
1. On the Windows 10 machine, open Windows Edge. Clear any previous cache.
2. Browse to https://10.88.0.1:9443
3. Based on your detected ZTNA tags, you will be allowed access to the webpage.
4. Review the Forward Traffic logs. Traffic is allowed on the LANtoDMZ-Allowed policy.
5. Delete browser cache and close the browser
Test 2: Denied based on Security Posture check:
3. Open the notepad as an administrator. Create some dummy text.

4. Save the file on C:\virus.txt.
5. On the FortiClient, click your avatar to view the currently detected tags. It may take a minute to
see the tag updated.
6. On the Windows 10 machine, open Windows Edge. Browse to https://10.88.0.1:9443
7. Based on your detected ZTNA tags, you will be denied access to the webpage.
8. Review the Forward Traffic logs. Traffic is denied with policy violation on the LANtoDMZ-
BlockMalicious policy.
9. Delete browser cache and close the browser
Review & Summary

In this exercise, we simulate bringing the device into the local network and accessing the web server
directly. Through applying ZTNA tags on regular firewall policies, we can add an extra layer of security,
ensuring devices are operating within parameters set in EMS before allowing access.
You may have run into trouble with using ZTNA tags to control access. Ultimately, the firewall policy
must be able to match the source to the IP address that is dynamically returned from EMS for the
specific ZTNA tags.
59
Appendix A: ZTNA Troubleshooting & Debugging
The following debug commands can be used to troubleshoot ZTNA issues:
Command Description
# diag endpoint fctems test- Verify FortiGate to FortiClient EMS connectivity.
connectivity <EMS>
# exec fctems verify <EMS> Verify FortiClient EMS’s certificate.
# diag test application fcnacd 2 Dump the EMS connectivity information.
# diag debug app fcnacd -1 Run real-time FortiClient NAC daemon debugs.
# diag debug enable
# diagnose endpoint record list <ip> Show the endpoint record list. Optionally, filter
by the endpoint IP address.
# diagnose endpoint wad-comm find-by Query endpoint info by client UID.
uid <uid>
# diagnose endpoint wad-comm find-by Query endpoints by the client IP-VDOM pair.
ip-vdom <ip> <vdom>
# diagnose wad dev query-by uid <uid> Query from WAD diagnose command by UID.
# diagnose wad dev query-by ipv4 <ip> Query from WAD diagnose command by IP
address.
# diag firewall dynamic list List EMS ZTNA tags and all dynamic IP and MAC
addresses.
# diagnose test application fcnacd 7 Check the FortiClient NAC daemon ZTNA and
# diagnose test application fcnacd 8 route cache.
# diagnose test application fcnacd 5 Trigger FortiClient EMS to return ZTNA/Host
tags
# diag wad debug enable category all Run real-time WAD debugs.
# diag wad debug enable level verbose
# diag debug enable
# diag debug reset Reset debugs when completed.
The WAD daemon handles proxy related processing. The FortiClient NAC daemon (fcnacd)
handles FortiGate to EMS connectivity.
60
Appendix B: Documentation References
Feature Documentation
 Zero Trust Network Access introduction

 Basic ZTNA configuration
 Establish device identity and trust context with FortiClient EMS
 SSL certificate based authentication
 ZTNA configuration examples
o ZTNA HTTPS access proxy example
o ZTNA HTTPS access proxy with basic authentication example
o ZTNA TCP forwarding access proxy example
o ZTNA proxy access with SAML authentication example
o ZTNA IP MAC filtering example
 Migrating from SSL VPN to ZTNA HTTPS access proxy
 ZTNA troubleshooting and debugging
Solution Hub
 https://docs.fortinet.com/ztna
61
Change Log
Version Change Date Author

v1.0 Initial Release Apr 29th, 2021 Keith Li
V1.1 Updated Windows 10 adapter names Apr 30th, 2021 Keith Li
Added Doc references
V1.2  Re-shuffled section 1.3 ZTNA Basic Configurations May 3rd, 2021 Keith Li
to after Exercise: Exploring the pre-defined
environment
 Updated 2.3 to reference bug, and add CLI debug
 Updated 4.1 to add GUI workaround
V1.3  Update 2.3 to clarify On-net vs Remote endpoint May 6th, 2021 Group
tags
 Additional feedback from testers
V1.4  Updated 2.1 and 3.1 to correctly explain when May 17th, 2021 Group
FortiClient obtains the cert from EMS
V1.5  Added Section 4 TCP Forwarding Access Proxy May 26th, 2021 Group
62

Zero Trust Network Access: Hands On Lab

Uploaded by

Copyright:

Available Formats

You might also like

Zero Trust Network Access: Hands On Lab

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zero Trust Network Access: Hands On Lab

Uploaded by

Copyright:

Available Formats

ZERO TRUST NETWORK ACCESS

FortiGate 7.0 | FortiClient EMS 7.0 | FortiClient 7.0

1.1 ZTNA Key Concept

Full ZTNA vs IP/MAC filtering

ZTNA Telemetry, Tags and Policy enforcement

HTTPS access proxy:

1.2 ZTNA vs traditional SSL VPN or IPsec VPN Teleworking solutions

 Some AD users are members of the Remote-Allowed group in the AD fortiad.info

More advanced Teleworking scenarios

1.3 Lab Topology & Preparations

2. Right click on interface, and set status to enable or disable

Users & User Groups:

Active Directory fortiad.info:

User Group (Member Of) User Password

FortiGate local users:

User Group User Password

Getting Started in the FNDN Lab Environment

1. Using a web browser, access the CSE Lab at: https://fndn.fortinet.net/cse

f. Once connected, open a browser and browse to the web server at

3. On the Windows 10 machine, establish SSL VPN web mode connection

Review & Summary

Once this exercise is completed, disconnect your VPNs.

2. FortiGate <-> EMS <-> FCT connection

 Device information (network details, operating system, model, and others)

Device Role: FortiClient EMS

Device Role: FortiGate

Certificate management on FortiClient EMS

Goals for this exercise:

To allow remote FortiTelemetry access from the ‘Internet’ or ‘Off-Net’:

1. Go to Policy & Objects > Virtual IPs.

Testing FortiClient registration:

Configure the FortiGate EMS Fabric connector to connect to FortiClient EMS:

1. On the FortiGate, go to Security Fabric > Fabric Connectors.

Verifying the FortiGate<->EMS connection

2.3 Lab Exercise: Configure EMS ZTNA tagging rules

Configuring ZTNA Rules

1. Login to the FortiClient EMS using provided FortiDemo credentials (admin/$ecurityFabric)

To configure a Zero Trust Tagging Rule for detecting logged in AD = FortiAD.info:

1. Login to the FortiClient EMS using provided FortiDemo credentials (admin/$ecurityFabric)

Additionally, it is useful to display the ZTNA tags on the FortiClient itself.

To configure the ZTNA tag to display on the FortiClient:

# diag endpoint wad-comm find-by ip-vdom 10.0.1.2 root

# diag endpoint wad-comm find-by ip-vdom 10.0.1.2 root

# diag test application fcnacd 7

To enable Send tag info from all FortiClients on FortiClient EMS:

1. On the FortiClient EMS, navigate to Administration > Fabric Devices

3. HTTPS Access Proxy

FortiGate also has a configuration to accept or block an empty client certificate.

 client-cert is set to enable, and empty-cert-action is set to block.

Goals for this exercise:

 Configure a functioning HTTPS Access Proxy for a remote user

To configure HTTPS access proxy VIP from the FortiGate GUI:

To define the real server mapping:

1. Under Services/server mapping, click Create New

To configure ZTNA rules to control access:

To configure a firewall policy for full ZTNA:

1. Go to Policy & Objects > Firewall Policy. Click Create New.