FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
martinsd
Staff
Staff
Article Id 276058
Description This article describes the behavior and limitations of using Geography IP Address objects in ZTNA Rules/Proxy policies. There is also a similar mention for FQDN and Wildcard Address objects.
Scope FortiGate v7.0, v7.2, v7.4.
Solution

Key Note:

Geographic address objects are not supported by ZTNA policies (both Simple and Full), even though they can be set in the Source Address field in v7.4 and earlier. When configured in the Source field for a ZTNA policy, Geography Address objects cause the FortiGate to no longer match the ZTNA proxy policy correctly. This is also true for FQDN and Wildcard FQDN Address objects.

 

In future releases, these object types will be hidden when working on ZTNA policies. Below are some logs to demonstrate this behavior:

 

When using the 'all' object as the source, an 'accept' action takes place (policy index = 1):

 

config firewall address

edit "Portugal"

set type geography

set country "PT"

next

end

show firewall proxy-policy 1

config firewall proxy-policy

edit 1

set name "GeoTest"

set proxy access-proxy

set access-proxy "TCP-Forwarding"

set srcintf "wan1"

set srcaddr "all"

set dstaddr "LAB"

set action accept

set schedule "always"

set logtraffic all

set groups "SAML_LAB"

set utm-status enable

set ssl-ssh-profile "certificate-inspection"

next

end

 

diagnose firewall iprope list 100017

policy index=1 uuid_idx=15932 action=accept
flag (8810009): log redir master nlb pol_stats
flag3 (80000000):
schedule(always)
cos_fwd=0 cos_rev=0
group=00100017 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=0
misc=4
zone(4): 3 4 5 6 -> zone(1): 0
source(1): 0.0.0.0-255.255.255.255, uuid_idx=15739,
dest(1): 192.168.100.69-192.168.100.69, uuid_idx=0,
service(1):
        [6:0x0:1012/(0,65535)->(8887,8887)] flags:0 helper:auto

 

Upon using the 'Portugal' object as the source, a 'drop' is observed (policy index = 0 - implicit deny):

 

show firewall proxy-policy 1

config firewall proxy-policy

edit 1

set name "GeoTest"

set proxy access-proxy

set access-proxy "TCP-Forwarding"

set srcintf "wan1"

set srcaddr "Portugal"

set dstaddr "LAB"

set action accept

set schedule "always"

set logtraffic all

set groups "SAML_LAB"

set utm-status enable

set ssl-ssh-profile "certificate-inspection"

next

end

 

diag firewall iprope list 100017

policy index=0 uuid_idx=0 action=drop
flag (8010000): master pol_stats
flag3 (100): last-deny
schedule()
cos_fwd=0 cos_rev=0
group=00100017 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=0
misc=4
zone(1): 0 -> zone(1): 0
source(1): 0.0.0.0-255.255.255.255, uuid_idx=15739,
dest(1): 192.168.100.69-192.168.100.69, uuid_idx=0,
service(1):
        [6:0x0:0/(0,65535)->(0,65535)] flags:0 helper:auto

 

In the above iprope table entries,  the entry corresponding to the ZTNA policy is removed once a Geography IP Address object has been added.

 

Note:

set ztna-geo-tag has been removed and is not supported on newer versions for both IPv4 and IPv6 Geo type address objects. However, it shows the option in the access-proxy source address drop-down list in the ZTNA proxy policy if the version is before v7.6.3. The option is not available after v7.6.3.