|
When changing the ZTNA destination of a ZTNA access proxy in a firewall policy, the change does not take effect, which may result in traffic being passed/blocked or the policy matching all destinations.
config firewall policy
edit 1
set name "test_ztna"
set srcintf "port1"
set dstintf "any"
set action accept
set srcaddr "all"
set dstaddr "SMB"
set ztna-ems-tag "test_tag"
set schedule "always"
set utm-status enable
set av-profile "g-default"
set nat enable
next
FGT (XX)# show ztna destination
config ztna destination
edit "ztna_smb1"
set uuid xxxxxxxxxxx
set address "fgt"
set mappedport 445
next
edit "ztna_dst2"
set uuid yyyyyyyyyy
set address "abc.com"
next
edit "ztna_ssh3"
set uuid zzzzzzzz
set address "dest1"
set mappedport 22
Ideally, both SMB and SSH traffic match and are allowed by the policy. However, when added to the firewall policy as shown:
edit 1
set name "test_ztna"
set srcintf "port1"
set dstintf "any"
set action accept
set srcaddr "all"
set dstaddr "SMB"
set ztna-ems-tag "test_tag"
set ztna-destination "ztna_smb1"
set schedule "always"
set utm-status enable
set av-profile "g-default"
set nat enable
In the above case, only SMB traffic is supposed to pass, while SSH traffic should be blocked. However, SSH traffic continues to pass.
This is the current behavior. The issue can be resolved by restarting the WAD process; once WAD is restarted, SSH traffic is correctly blocked.
The WAD process can be restarted using the following command. For more details, refer to the documentation.
fnsysctl killall <PROCESS_NAME>
See Technical Tip: Find and restart/kill a process on a FortiGate by the process ID (PID) via pidof.
The issue is scheduled to be addressed in the upcoming OS release version 8.0.
|
