Technical Tip: How to avoid local out traffic issues

[IO]

Description	This article describes how to avoid connectivity issues for FortiGate services that use local out traffic when the outgoing interface is explicitly specified.
Scope	FortiGate's local services (syslog, DNS, tls-probe, FortiGuard, etc).
Solution	Most of FortiGate's services allow adjusting behaviour for locally originated traffic, like it's described in the following configuration guide: Local out traffic  But in some deployments, basic and straightforward configuration can lead to non non-working scenario. Let's take, as an example Syslog service: FGT # get log syslogd setting status : enable server : 10.226.131.62 mode : udp port : 651 facility : local7 source-ip : 10.13.8.67 format : default priority : default interface-select-method: specify interface : port2 FGT # show system interface port1 static 0.0.0.0 0.0.0.0 10.5.136.67 255.255.192.0 up disable physical port2 static 0.0.0.0 0.0.0.0 10.13.8.67 255.255.192.0 up disable physical The configuration above fully corresponds to the administration guide, while the syslog server doesn't receive any traffic. Let's take a closer look at the next debug output: FGT # diagnose debug application syslogd -1 Debug messages will be on for 30 minutes. FGT # diagnose debug enable pid:2081-__handle_msg()-414: Subscriber:2 received package. pubid:0 pkgid:35839 pkg_index:191 pid:2081-__handle_pkg_logs()-356: Subscriber:2 processing package size:1754 logs:2 pickup:2 pid:2081-__subscr_close_cur_pkg()-140: close package size:1754 logs:2 miglog_socket_set_interface()-287: Binded interface index: 4. <2081> __flush_queue()-159: sendmmsg failed to send data FGT # diagnose netlink interface list port2 if=port2 family=00 type=1 index=4 mtu=1500 link=0 master=0 ref=38 state=start present fw_flags=0 flags=up broadcast run multicast Qdisc=pfifo_fast hw_addr=00:6b:72:79:2a:02 broadcast_addr=ff:ff:ff:ff:ff:ff stat: rxp=10447610 txp=161141 rxb=3378864593 txb=19489658 rxe=0 txe=0 rxd=0 txd=0 mc=0 collision=0 @ time=1763021456 The output shows that despite proper interface binding (port2 has interface index 4), syslogd fails to send data. Syslogd statistics show an increasing 'cached' counter for localout traffic, while 'sent' does not change: FGT # diagnose test application syslogd 4 syslog=128, nulldev=0, webtrends=0, localout_ioc=337447, alarms=0 global log dev statistics: syslog 0: sent=0, failed=0, cached=128, dropped=0 localout-ioc statistics in root: sent=0, failed=3, cached=0, dropped=337444 FGT # diagnose test application syslogd 4 syslog=129, nulldev=0, webtrends=0, localout_ioc=337448, alarms=0 global log dev statistics: syslog 0: sent=0, failed=0, cached=129, dropped=0 localout-ioc statistics in root: sent=0, failed=3, cached=0, dropped=337445 To check outgoing traffic or the possible drop reason, enable syslog packet trace: FGT # diagnose debug flow filter daddr 10.226.131.62 FGT # diagnose debug flow filter dport 651 FGT # diagnose debug flow show function-name enable FGT # diagnose debug flow show iprope enable FGT # diagnose debug flow trace start 5 FGT # diagnose debug flow trace start enable FGT # diagnose debug enable miglog_socket_set_interface()-287: Binded interface index: 4. <2081> __flush_queue()-159: sendmmsg failed to send data pid:2081-__handle_msg()-414: Subscriber:2 received package. pubid:0 pkgid:35893 pkg_index:191 pid:2081-__handle_pkg_logs()-356: Subscriber:2 processing package size:913 logs:1 pickup:1 pid:2081-__subscr_close_cur_pkg()-140: close package size:913 logs:1 diagnose test application syslogd 4 syslog=157, nulldev=0, webtrends=0, localout_ioc=337474, alarms=0 global log dev statistics: syslog 0: sent=0, failed=0, cached=157, dropped=0 localout-ioc statistics in root: sent=0, failed=3, cached=0, dropped=337471 pid:2081-__handle_msg()-414: Subscriber:2 received package. pubid:0 pkgid:35894 pkg_index:191 pid:2081-__handle_pkg_logs()-356: Subscriber:2 processing package size:913 logs:1 pickup:1 pid:2081-__subscr_close_cur_pkg()-140: close package size:913 logs:1 miglog_socket_set_interface()-287: Binded interface index: 4. <2081> __flush_queue()-159: sendmmsg failed to send data diagnose test application syslogd 4 syslog=158, nulldev=0, webtrends=0, localout_ioc=337475, alarms=0 global log dev statistics: syslog 0: sent=0, failed=0, cached=158, dropped=0 localout-ioc statistics in root: sent=0, failed=3, cached=0, dropped=337472 pid:2081-__handle_msg()-414: Subscriber:2 received package. pubid:1 pkgid:35170 pkg_index:191 pid:2081-__handle_pkg_logs()-356: Subscriber:2 processing package size:913 logs:1 pickup:1 pid:2081-__subscr_close_cur_pkg()-140: close package size:913 logs:1 miglog_socket_set_interface()-287: Binded interface index: 4. <2081> __flush_queue()-159: sendmmsg failed to send data Or execute packet capture: FGT # diagnose sniffer packet any "host 10.226.131.62" 4 0 l Using Original Sniffing Mode interfaces=[any] filters=[host 10.226.131.62] 0 packets received by filter 0 packets dropped by kernel The output above demonstrates that despite properly running the syslogd daemon and increasing counters, there are no traceable packets generated. The source of the issue is the routing table, which does not include any prefixes pointing towards the server (10.226.131.62): FGT # get router info routing-table all Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area V - BGP VPNv4 * - candidate default Routing table for VRF=0 S* 0.0.0.0/0 [10/0] via 10.5.191.254, port1, [1/0] C 10.5.128.0/18 is directly connected, port1 C 10.13.0.0/18 is directly connected, port2 C 10.74.74.0/24 is directly connected, VL74 S 10.76.76.0/24 [10/0] via IPSec1 tunnel 10.5.136.69, [1/0] C 10.93.7.200/32 is directly connected, lo_mgmt C 10.253.240.0/20 is directly connected, wqt.root Solution:  Inject the required prefix into the routing table, either manually or by a routing protocol. Here is the example with static route configuration: FGT # config router static FGT (static) # edit 5 new entry '5' added FGT (5) # FGT (5) # set dst 10.226.131.62 255.255.255.255 FGT (5) # set device port2 FGT (5) # show config router static edit 5 set dst 10.226.131.62 255.255.255.255 set device "port2" next end FGT (5) # end FGT # get router info routing-table all Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area V - BGP VPNv4 * - candidate default Routing table for VRF=0 S* 0.0.0.0/0 [10/0] via 10.5.191.254, port1, [1/0] C 10.5.128.0/18 is directly connected, port1 C 10.13.0.0/18 is directly connected, port2 C 10.74.74.0/24 is directly connected, VL74 S 10.76.76.0/24 [10/0] via IPSec1 tunnel 10.5.136.69, [1/0] C 10.93.7.200/32 is directly connected, lo_mgmt S 10.226.131.62/32 [10/0] is directly connected, port2, [1/0] C 10.253.240.0/20 is directly connected, wqt.root FGT # diagnose sniffer packet any "host 10.226.131.62" 4 0 l Using Original Sniffing Mode interfaces=[any] filters=[host 10.226.131.62] 2025-11-13 00:34:55.691438 port2 out arp who-has 10.226.131.62 tell 10.13.8.67 2025-11-13 00:34:56.740141 port2 out arp who-has 10.226.131.62 tell 10.13.8.67 2025-11-13 00:34:57.780109 port2 out arp who-has 10.226.131.62 tell 10.13.8.67 ^C 3 packets received by filter 0 packets dropped by kernel FGT # diagnose test application syslogd 4 syslog=260, nulldev=0, webtrends=0, localout_ioc=337569, alarms=0 global log dev statistics: syslog 0: sent=260, failed=0, cached=0, dropped=0 localout-ioc statistics in root: sent=0, failed=3, cached=0, dropped=337566 As it shows above, after the prefix was added to the routing table, outgoing traffic appeared in packet captures, and syslogd statistics display the 'cached' counter 0, while 'sent' is increasing.  Related articles: Technical Tip: How to specify outgoing interface for local DNS traffic  Troubleshooting Tip: Unable to connect to FortiGuard servers