Zero Trust Network Access – Accessing Web Applications From Secured Endpoint

In the previous blog post, I covered setting up the basis of security with Zero Trust Network Access (ZTNA) through establishing telemetry. In this post, I cover how to configure the FortiGate as a reverse proxy to allow secured access to web applications.

The whole motivation of this project was to find a way to provide secure access to my lab equipment when demoing these products to prospective customers. In my use case, this is usually driven by accessing the web user interfaces of these products to show my customers how easy it is to configure these devices and the amount of information that is available to help them solve their network problems.

Although the Fortinet solutions are considered “hardened” against known vulnerabilities (assuming you keep them up to date), there is still the possibility for an unknown (or newly discovered) vulnerability to impact the correct operation of these products. In order to minimize this risk while still providing access to these devices, I chose not to expose them directly on the Internet (either by assigning public IP addresses to these devices or providing a virtual IP through my firewall).

Instead I facilitate the access to these different components via a Virtual Private Network (VPN) established between my public cloud FortiGate and on-premise lab FortiGate. A diagram of this is shown below to illustrate this connectivity.

Figure 1. – Logical topology of connectivity to access Fortinet product UI in lab environment

Given that I want to have an “always on” experience with higher awareness of the state of the machine connecting to these resources, I have gone through the steps below to configure the FortiGate to provide access to these different web interfaces.

Enable ZTNA Feature in FortiOS UI

Before any of the Zero Trust Network Access components become available to be configured in the FortiOS Web UI, the “Zero Trust Network Access” feature needs to be enabled in the “System | Feature Visibility” section. A screenshot of where to enable this feature is listed below.

Figure 2. – Screenshot of enabling the ZTNA Feature in FortiOS UI
config system settings
    set gui-ztna enable
end

Figure 3. – CLI for enabling the ZTNA Feature in the FortiOS UI

Once this has been enabled, the components needed to complete the configuration become available in the FortiGate UI.

Configure ZTNA Servers

The first building block of providing access to the many different Fortinet applications is a ZTNA server. This object allows the definition of the public IP address these services will be accessible from, the certificate presented to the user when accessing these services as well as the service/server mapping. Here is a screenshot showing the complete configuration of my various Fortinet applications:

Figure 4. – Screenshot of defined ZTNA Server

As shown in the screenshot above, it is important to define the “External IP” (and not use 0.0.0.0). In addition to that, it is a best practice to use a wildcard certificate as the “default certificate” in the event that all of your services belong to the same root domain name. Lastly, you can configure SAML to prompt authentication prior to access but for simplicity sake, I chose not to go this route.

Once the general ZTNA Server settings have been defined, the Service/Server mapping should be defined to instruct the FortiGate how to route the traffic based on the domain it receives as part of the request.

Service/Server Mapping

In each of the Service/Server Mappings, there are detailed configurations that instruct the FortiGate which backend server to grant access to based on the HTTP URI request from the client. Here are screenshots of a few of different service/server mappings:

Figure 5. – Screenshot of Service/Server Mapping for ems.torianco.com
Figure 6. – Screenshot of Service/Server Mapping for fortimanager.torianco.com
Figure 7. – Screenshot of Service/Server Mapping for fortiauthenticator.torianco.com
config firewall vip
    edit "FortiApps"
        set type access-proxy
        set extip A.B.C.D
        set extintf "port1"
        set server-type https
        set extport 443
        set ssl-certificate "TORIANCO_WILDCARD"
    next
end
config firewall access-proxy-virtual-host
    edit "auto-FortiApps-1"
        set ssl-certificate "TORIANCO_WILDCARD"
        set host "ems.torianco.com"
    next
    edit "auto-FortiApps-2"
        set ssl-certificate "TORIANCO_WILDCARD"
        set host "fortimanager.torianco.com"
    next
    edit "auto-FortiApps-3"
        set ssl-certificate "TORIANCO_WILDCARD"
        set host "fortiauthenticator.torianco.com"
    next
end
config firewall access-proxy
    edit "FortiApps"
        set vip "FortiApps"
        set client-cert enable
        config api-gateway
            edit 1
                set virtual-host "auto-FortiApps-1"
                config realservers
                    edit 1
                        set ip X.Y.Z.10
                    next
                end
            next
            edit 2
                set url-map "/*"
                set virtual-host "auto-FortiApps-2"
                set url-map-type wildcard
                config realservers
                    edit 1
                        set ip X.Y.Z.20
                    next
                end
            next
            edit 3
                set url-map "/**"
                set virtual-host "auto-FortiApps-3"
                set url-map-type wildcard
                config realservers
                    edit 1
                        set ip X.Y.Z.30
                    next
                end
            next
        end
    next
end

Figure 8. – CLI commands of definition of ZTNA Server and Service/Server mapping

Please note: On FortiOS 7.0.3, I encountered an issue where multiple service/server mappings could be defined although I used different virtual host for each mapping. I found a workaround to allow multiple domains to be specified within the same ZTNA server definition. I accomplished this through the use of “Wildcard” matching and adding more “*” definitions behind the “path” variable.

Please note: On FortiOS 7.0.3, I encountered an issue where multiple service/server mappings being defined in the FortiOS WebUI would cause the virtual host mappings to get misconfigured in the CLI. I found a workaround to this by performing the configuration of the ZTNA Server and Server/Service mappings via the CLI.

Once the ZTNA servers have been defined, an entry under the “ZTNA | ZTNA Servers” section should be shown similar to the following screenshot:

Figure 9. – Screenshot of defined ZTNA server in the FortiOS UI

To provide the necessary access to these newly defined ZTNA Servers, I create a ZTNA rule.

Configure ZTNA Rules

The second building block to facilitating access via ZTNA is the ZTNA rule. This allows the administrator to join the policy that defines the who, when and what should be able to access the resources behind the FortiGate. This should be very familiar to users of the FortiGate platform as it looks very similar to the definition of a standard firewall policy in FortiGate.

To provide access to my Fortinet applications, I create a rule that is reflected in the following screenshot:

Figure 10. – Screenshot of ZTNA Rule allowing access to “FortiApps” ZTNA Server
config firewall proxy-policy
    edit 1
        set name "Inbound Access to FortiApps"
        set proxy access-proxy
        set access-proxy "FortiApps"
        set srcintf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set ztna-ems-tag "FCTEMS0000000000_registered"
        set action accept
        set schedule "always"
        set logtraffic all
        set comments "Inbound Access to FortiApps"
    next
end

Figure 11 . – CLI commands of the ZTNA Rule providing access to “FortiApps” ZTNA Server

For basic connectivity establishment, I have just required that a FortiClient is registered to my FortiClientEMS installation. It is worth noting that no additional “Firewall Policy” needs to be defined to allow access to ZTNA protected resources. Here is an example showing connectivity to “https://ems.torianco.com”

Figure 12. – Screenshot showing initial prompt of certificate for validation by FortiGate in the ZTNA process
Figure 13. – Screenshot showing successful loading of ems.torianco.com after ZTNA validation

In subsequent posts, I will explore creating more granular tags to enforce secure compliance when accessing these services, using TCP Forwarding to access non-HTTP resources via ZTNA and go under the hood about what is happening during the ZTNA validation process. I hope that this post was informative and as always, please let me know your thoughts in the comments below.

0 0 votes
Article Rating

Leave a Reply

0 Comments
Inline Feedbacks
View all comments