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.
P-vs
Staff
Staff
Article Id 385007
Description This article describes how to handle a scenario where Google is or other websites are unexpectedly blocked from the internal DNS.
Scope FortiGate.
Solution

With certain internal DNS setups, google.com or any other website may unexpectedly be blocked for matching the FQDN address object.

 

FortiGate is configured with a DNS server as a primary x.x.x.x and secondary y.y.y.y, which are local DNS servers.

 

Intermittently, Google services are blocked by a deny policy 'ABC', where an FQDN setup is resolving to 216.239.38.120 in the destination address.


This results in blocking google.com when it resolves to the IP 216.239.38.120:

 

> google.com
Server: server.com
Address: x.x.x.x

Non-authoritative answer:
Name: forcesafesearch.google.com
Addresses: 2001:4860:4802:32::78
216.239.38.120  <----- nslookup for google.com.
Aliases: google.com


Capturing the debug shows that the abc policy is being hit.


2025-02-03 15:13:04 id=65308 trace_id=628 func=print_pkt_detail line=5894 msg="vd-root:0 received a packet(proto=6, 10.1.160.67:59297->216.239.38.120:443) tun_id=0.0.0.0 from DMZ-Core-SW.
flag [S], seq 1950990176, ack 0, win 64240"
2025-02-03 15:13:04 id=65308 trace_id=628 func=init_ip_session_common line=6080 msg="allocate a new session-2a612125, tun_id=0.0.0.0"
2025-02-03 15:13:04 id=65308 trace_id=628 func=rpdb_srv_match_input line=1040 msg="Match policy routing id=2136277013: to 216.239.38.120 via ifindex-65"
2025-02-03 15:13:04 id=65308 trace_id=628 func=__vf_ip_route_input_rcu line=1990 msg="find a route: flag=00000000 gw-1.1.1.1 via Zscaler-GRE-Mob"
2025-02-03 15:13:04 id=65308 trace_id=628 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=1, len=7"
2025-02-03 15:13:04 id=65308 trace_id=628 func=fw_forward_handler line=837 msg="Denied by forward policy check (policy abc)"

 

Additionally, in the forward traffic logs:

 

date=2025-03-06 time=12:14:19 eventtime=1741252458982164771 tz="+0300" logid="0000000013" type="traffic" subtype="forward" level="notice" vd="root" srcip=10.1.161.76 srcport=57997 srcintf="DMZ-Core-SW" srcintfrole="lan" dstip=216.239.38.120 dstport=443 dstintf="Zscaler-GRE-Mob" dstintfrole="lan" srccountry="Reserved" dstcountry="United States" sessionid=1595316118 proto=17 action="deny" policyid=ABC policytype="policy" poluuid="bcf97ef2-2f81-51ee-e344-1be77fbcdab2" policyname="User-to-Zscaler-Denied-IP's" service="UDP_443" trandisp="noop" duration=0 sentbyte=0 rcvdbyte=0 sentpkt=0 rcvdpkt=0 shapingpolicyid=19 shapingpolicyname="Zscaler-10mbps" shaperperipname="All-Users-Internet-Zscaler-10MB" shaperperipdropbyte=0 vwlid=21 vwlquality="Seq_num(5 Zscaler-GRE-Mob), alive, sla(0x1), gid(2), num of pass(1), selected" vwlname="Zscaler-SDWAN-Rule" appcat="unscanned" crscore=30 craction=131072 crlevel="high" srchwvendor="Cisco" devtype="Router" mastersrcmac="f8:a7:3a:6f:1e:ef" srcmac="f8:a7:3a:6f:1e:ef" srcserver=0.

 

In the DNS proxy output, both domains are resolving to the same IP and matching the deny policy:

 

2025-03-06 12:09:39 vfid=0 name=www.google.com ver=IPv4 wait_list=0 timer=8 min_refresh=60 min_ttl=60 cache_ttl=0 slot=-1 num=2 wildcard=02025-03-06 12:09:39
2025-03-06 12:09:39 2025-03-06 12:09:39 142.250.187.196 (ttl=234:188:188)2025-03-06 12:09:39 216.239.38.120 (ttl=60:30:30)2025-03-06 12:09:39

2025-03-06 12:09:38 vfid=0 name=zcky.na.lb.holadns.com ver=IPv4 wait_list=0 timer=34 min_refresh=60 min_ttl=5 cache_ttl=0 slot=-1 num=2 wildcard=02025-03-06 12:09:38
2025-03-06 12:09:38 2025-03-06 12:09:38 216.239.38.120 (ttl=19437:18646:18646)2025-03-06 12:09:38 208.91.112.55 (ttl=5:0:0)2025-03-06 12:09:38


Collect the following debug logs:

 

get sys status
show full sys dns
dia test app dnsproxy 6
dia test application dnsproxy 3
dia firewall iprope list
dia firewall iprope list | grep -n 216.239.38

 

As FQDN is getting resolved to 216.239.38.120, the iprobe table created for the policy ABC contains this address in the destination, and the action is set to block.


policy index=abc uuid_idx=18747 action=drop
flag (8010801): log d_rm master pol_stats
flag2 (4006000): log_fail resolve_sso notif
schedule(always)
cos_fwd=255 cos_rev=255
group=00100004 av=00000000 au=00000000 split=00000000
host=0 chk_client_info=0x0 app_list=0 ips_view=0
misc=0
zone(1): 56 -> zone(2): 65 66
source(1): 0.0.0.0-255.255.255.255, uuid_idx=15732,
dest(69):
.
.
uuid_idx=18611
zcky.na.lb.holadns.com ID(883)
ADDR(208.91.112.55)
ADDR(216.239.38.120)


FQDN: zcky.na.lb.holadns.com is wrongly getting resolved to 216.239.38.120 by internal DNS.


Check what is configured as the Forward DNS server in the local DNS server.

As a workaround, create a whitelist policy for IP 216.239.38.120 and place it on top of the 'abc' policy for the important server.

Contributors