Description
This article addresses an issue in FortiGate where 'DNS over TCP' local-out traffic is ignored when Internet Service Database (ISDB) is used in SD-WAN rules
Scope
FortiGate v7.2, v7.4.
Solution
FortiGate is configured to use the 'DoT' (DNS over TLS) protocol for DNS communication. An SD-WAN rule is set up with FortiGuard ISDB, assigning the internet-facing interfaces as members of the rule.
However, despite this configuration, FortiGate randomly selects an interface from the SD-WAN members instead of adhering to the rule.
This issue is specifically observed with DNS over TCP, while no such behavior is seen with UDP-based DNS traffic.
Let's take an example here.
Current DNS settings:
config system DNS
set primary 96.45.45.45
set secondary 96.45.46.46
set protocol dot
set server-hostname "globalsdns.fortinet.net"
set interface-select-method sdwan
end
SD-WAN Rule is as below:
- wan2 and port1 >> correct wan interface.
- dmz >> incorrect interface.
ISDB set to go via wan2 or port1 for DNS traffic:
FGT # diagnose firewall proute list
list route policy info(vf=root):
id=2131623948(0x7f0e000c) vwl_service=12(Fortiguard_Update) vwl_mbr_seq=2 1 dscp_tag=0xfc 0xfc flags=0x0 tos=0x00 tos_mask=0x00 protocol=0 sport=0-65535 iif=0(any) dport=1-65535 path(2) oif=6(wan2) oif=9(port1)
source(1): 0.0.0.0-255.255.255.255
destination wildcard(1): 0.0.0.0/0.0.0.0
internet service(3): Fortinet-FortiGuard(1245324,0,0,0,0) Fortinet-FortiGuard.Secure.DNS(1245454,0,0,0,0) Fortinet-DNS(1245187,0,0,0,0)
hit_count=159 last_used=2024-10-08 23:40:51
The ISDB-based SD-WAN rule is not being matched, and the traffic is instead following a different rule, routing through the incorrect interface, such as the DMZ.
FGT # diagnose sniffer packet any 'host 96.45.45.45' 4 0 l
interfaces=[any]
filters=[host 96.45.45.45]
2024-10-08 23:42:04.242061 dmz out 172.16.6.35.11881 -> 96.45.45.45.853: syn 2393627985
2024-10-08 23:42:08.422801 dmz out 172.16.6.35.11883 -> 96.45.45.45.853: syn 2068610289
After switching the DNS protocol to clear text and using UDP on port 53, the ISDB-based SD-WAN rule is triggered correctly, and the traffic is routed through the intended WAN interface
Changed to UDP clear text protocol:
config system DNS
set primary 96.45.45.45
set secondary 96.45.46.46
set interface-select-method sdwan
end
2024-10-08 23:46:41.622074 dmz out 172.16.6.35.11929 -> 96.45.45.45.853: syn 159189736
2024-10-08 23:46:45.632049 dmz out 172.16.6.35.11929 -> 96.45.45.45.853: syn 159189736
2024-10-08 23:46:46.767611 wan2 out 10.109.80.23.4362 -> 96.45.45.45.53: udp 44<----- Once changed to UDP.
2024-10-08 23:46:46.768177 wan2 out 10.109.80.23.4362 -> 96.45.45.45.53: udp 36
After upgrading the FortiGate to v7.4.2, the SD-WAN rule with ISDB for DNS over TCP functions correctly. It is important to note that this issue is resolved in v7.4.2 and later.
Tests were also conducted using Google DNS over TCP (8.8.8.8 on TCP port 853), and the same issue occurred, with the traffic not matching the SD-WAN ISDB rule. This behavior is not limited to FortiGuard DNS; rather, it affects all DNS over TCP traffic, which bypasses the SD-WAN rule when ISDB is used.
Workaround:
- Use UDP 53 for DNS traffic.
- Create a new SDWAN rule with dst address as DNS IP instead of ISDB.
The issue has been reported with a known issue ID 1071792 and it is planned to be resolved in v7.2.11, v7.4.2.
