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.
nithincs
Staff
Staff
Article Id 363294
Description

 

This article explains the concept of resolving destination IP to Domain address in forward traffic logs.

 

Scope

 

FortiGate.

 

Solution

 

FortiGate generates the forward traffic and UTM logs for the passthrough traffic. In GUI, logs reflect the destination IP along with the domain name.

Below is the illustration of the network topology in which FortiGate is deployed:


Client 172.30.18.94 <----------> port4 [FortiGate] port1 10.5.144.159 <--------> Internet
DNS server :8.8.8.8                    DNS server : 96.45.45.45

 

FortiGate log setting is enabled with 'resolve-ip':

 

config log settings
    set resolve-ip enable
end

 

  • When a user accesses any website, the client system will do a DNS lookup for the website address.
  • This DNS traffic will come to FortiGate, which acts as a gateway.
  • FortiGate will forward the request to the server, and the response from the server will get forwarded back to the client. 
  • Here FortiGate will implicitly learn the domain and its IP address.

 

For illustration, let's consider a user accessing openssl.com.

Since the system does not have a local DNS cache for openssl.com, it will generate a DNS query. The DNS query is successful, and the client gets the domain name ip for openssl.com.

 

openssl.JPG

 

  • With this DNS communication, FortiGate implicitly learns the domain and its IP address information for openssl.com.


date=2024-12-08 time=09:38:38 eventtime=1733679518610878273 tz="-0800" logid="0000000013" type="traffic" subtype="forward" level="notice" vd="root" srcip=172.30.18.94 srcname="172.30.18.94" srcport=58016 srcintf="port4" srcintfrole="undefined" dstip=8.8.8.8 dstname="dns.google" dstport=53 dstintf="port1" dstintfrole="undefined" srccountry="Reserved" dstcountry="United States" sessionid=2429281 proto=17 action="accept" policyid=2 policytype="policy" poluuid="f1a56c7a-b57b-51ef-77b2-44d9c62a17a5" policyname="ff" service="DNS" trandisp="snat" transip=10.5.144.159 transport=58016 duration=180 sentbyte=68 rcvdbyte=255 sentpkt=1 rcvdpkt=1 vwlid=0 appcat="unscanned"

 

'dnsproxy' daemon debug logs show the below information:

 

2024-12-08 09:35:38 [worker 0] dns_visibility_log_hostname()-241: vd=0 pktlen=227
2024-12-08 09:35:38 [worker 0] wildcard_fqdn_response_cb()-951: vd=0 pktlen=227
2024-12-08 09:35:38 [worker 0] hostname_entry_insert()-143: af=2 domain=openssl.com
2024-12-08 09:35:38 [worker 0] handle_hostname_add_msg()-549
2024-12-08 09:35:38 [worker 0] batch_on_read()-3553
2024-12-08 09:35:38 [worker 0] unix_receive_request_stub()-3456

 

This information is added to the DNS cache of the FortiGate, which can be checked using the command 'diagnose test application dnsproxy 13'.

 

194.97.150.234 (domain=openssl.com, ttl=85277)

 

When the logs page is accessed, FortiGate miglogd will scan the local DNS cache for the destination IP, and then the Resolved Domain reflects the domain name of the IP.

 

resolved name.JPG