Skip to main content
I_Omel
Staff
Staff
November 13, 2025

Technical Tip: How to avoid local out traffic issues

  • November 13, 2025
  • 0 replies
  • 939 views
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