HA failover support for ZTNA proxy sessions

User information and TLS sessions are synchronized between HA members for ZTNA proxy sessions. When a failover occurs, the new primary unit will continue allowing sessions from the logged in users without asking for the client certificate and re-authentication again.

Example

In this example, a FortiGate HA pair is acting as a ZTNA access proxy. Clients that are trying to access the web server on qa.test.com are proxied by the ZTNA access proxy. Remote clients must be registered to the EMS server, and pass a client certificate check and user authentication in order to connect. Upon HA member failure, a failover occurs and the new primary unit will continue to allow connections without requesting client certificate check and user authentication for existing users and devices.

This example assumes ZTNA and EMS server settings are already configured.

To configure the HA settings:

config system ha
    set group-name "501E"
    set mode a-p
    set password **********
    set hbdev "ha" 0
    set session-pickup enable
    set override disable
    set monitor "port1" "port2"
end

To verify that the proxy sessions are synchronized between HA members:

1. On the client, access the web server. The ZTNA access proxy challenges the user for a client certificate and user authentication.

   

2. On the primary FortiGate, verify that the user information and TLS sessions are synchronized between HA members.
   1. Verify the list of proxy users:

      501E-primary # diagnose wad user list
      ID: 1, VDOM: root, IPv4: 10.1.100.22
        user name   : localuser1
        worker      : 0
        duration    : 8
        auth_type   : IP
        auth_method : Basic
        pol_id      : 1
        g_id        : 0
        user_based  : 1
        expire      : 597
        LAN:
          bytes_in=2093 bytes_out=5753
        WAN:
          bytes_in=2024 bytes_out=1235

   2. Apply a filter to WAD debug to diagnose the wad informer process:

      501E-primary # diagnose test application wad 2400
      Set diagnosis process: type=informer index=0 pid=305

   3. Show the user cache from the WAD informer. Verify that the localuser1 entry exists:

      501E-primary # diagnose test application wad 110
      users:
      [1]     localuser1@10.1.100.22:0 upn_domain= from:worker worker:6 vf:0 ref:1 stale=0 ntlm:0, has_fsae:0, guest:0
                      user_node:(0x7fe18dcf0048) user:1[max=65536](0x7fe18dd08048) ip:1(0x7fe18dd00048) scheme:0 outofsync:0(0) id:1
      ...

   4. Verify using WAD real-time debugs on the secondary FortiGate. The user information is synchronized to the secondary FortiGate:

      501E-secondary # diagnose wad debug enable category all
      501E-secondary # diagnose wad debug enable level verbose
      501E-secondary # diagnose debug enable
      [I][p:296]               wad_proc_informer_ha_dgram_on_read:2811  Got HA msg: type=0, sizeof(msg)=8, dlen=80, sz=88
      [I][p:296]               wad_proc_informer_on_ha_user_add  :1493  reader: ip=10.1.100.22:45852 vf=0 seq=0 grp_type=0 scheme=0 is_ntlm=0 has_fsae=0 concur_user=65536 domain=''
      [I][p:296]               wad_informer_update_user_ext      :782   ip=10.1.100.22:45852 name=localuser1 from=worker
      [I][p:296]               wad_informer_find_user_ip_entries :621   find=false(1) vf=0 ip=10.1.100.22:45852 pr=(nil)
      mapping user_node:0x7fc1c84dd048, user_ip:0x7fc1c84ed048(0), user:0x7fc1c84f5048(0).

3. Verify the user cache from the WAD informer:

   501E-secondary # diagnose test application wad 110
   users:
   [1]     localuser1@10.1.100.22:0 upn_domain= from:worker worker:-126 vf:0 ref:1 stale=0 ntlm:0, has_fsae:0, guest:0
                   user_node:(0x7fa3eb07d048) user:1[max=65536](0x7fa3eb095048) ip:1(0x7fa3eb08d048) scheme:0 outofsync:0(0) id:7
   ...

If the client tries to access the web server again after failover occurs, the client certificate check and authentication prompt does not appear. ZTNA allows the traffic to pass.

The ZTNA logs for both FortiGates contain the same user information.

Primary FortiGate log:

1: date=2022-03-23 time=11:49:57 eventtime=1648061397548444970 tz="-0700" logid="0005000024" type="traffic" subtype="ztna" level="notice" vd="root" srcip=10.1.100.22 srcname="client" srcport=45826 srcintf="port2" srcintfrole="lan" dstcountry="Reserved" srccountry="Reserved" dstip=172.16.200.209 dstport=443 dstintf="port1" dstintfrole="lan" sessionid=4786 service="HTTPS" proto=6 action="accept" policyid=1 policytype="proxy-policy" poluuid="ea7a8a04-a56e-51ec-9d7b-90d24b3a28e9" policyname="ztna" duration=5 user="localuser1" gatewayid=1 vip="ztna" accessproxy="ztna" clientdeviceid="EF73C831C3FE4FF195A5B2030B******" clientdevicetags="FCTEMS8821000000_all_registered_clients/MAC_FCTEMS8821000000_all_registered_clients/FCTEMS8821000000_ZT_FILE_CERTFILE" wanin=2024 rcvdbyte=2024 wanout=1325 lanin=1511 sentbyte=1511 lanout=1075 fctuid="EF73C831C3FE4FF195A5B2030B******" unauthuser="fosqa" unauthusersource="forticlient" appcat="unscanned"

Secondary FortiGate log:

1: date=2022-03-23 time=11:55:01 eventtime=1648061701628425041 tz="-0700" logid="0005000024" type="traffic" subtype="ztna" level="notice" vd="root" srcip=10.1.100.22 srcname="client" srcport=45830 srcintf="port2" srcintfrole="lan" dstcountry="Reserved" srccountry="Reserved" dstip=172.16.200.209 dstport=443 dstintf="port1" dstintfrole="lan" sessionid=676 service="HTTPS" proto=6 action="accept" policyid=1 policytype="proxy-policy" poluuid="ea7a8a04-a56e-51ec-9d7b-90d24b3a28e9" policyname="ztna" duration=5 user="localuser1" gatewayid=1 vip="ztna" accessproxy="ztna" clientdeviceid="EF73C831C3FE4FF195A5B2030B******" clientdevicetags="FCTEMS8821000000_all_registered_clients/MAC_FCTEMS8821000000_all_registered_clients/FCTEMS8821000000_ZT_FILE_CERTFILE" wanin=2024 rcvdbyte=2024 wanout=1325 lanin=1511 sentbyte=1511 lanout=1075 fctuid="EF73C831C3FE4FF195A5B2030B******" unauthuser="fosqa" unauthusersource="forticlient" appcat="unscanned"