Technical Tip: Setting up syslog in a Multi-VDOM setup

[nithincs]

Description	This article describes how to optimize FortiGate to syslog server commnication in a multi-VDOM setup.
Scope	FortiGate.
Solution	The Syslog server is configured to send the FortiGate logs to a syslog server IP. In a multi-VDOM setup, syslog communication works as explained below. Scenario 1: If a syslog server is configured in Global and syslog-override is disabled in the VDOM: config global config log syslogd setting set status enable set server "192.168.5.7" set port 1514 end config log setting set syslog-override disable end FortiGate will use the management VDOM to generate the syslog traffic to the server '192.168.5.7' and send it via a routable interface in the management VDOM. dia sniffer packet any "port 1514" 4 0 l Using Original Sniffing Mode interfaces=[any] filters=[port 1514] 2024-08-22 14:28:07.583305 port1 out 10.5.146.91.9450 -> 192.168.5.7.1514: udp 566 2024-08-22 14:28:08.582746 port1 out 10.5.146.91.9450 -> 192.168.5.7.1514: udp 565 ^C 3 packets received by filter 0 packets dropped by kernel get router info routing-table details 192.168.5.7 Routing table for VRF=0 Routing entry for 0.0.0.0/0 Known via "static", distance 10, metric 0, best * vrf 0 10.5.191.254, via port1 If the syslog server is over another VDOM, it is required to create a policy to allow the traffic on the other VDOM.  Example : Syslog server 10.20.1.20 exists over Prod VDOM. Root (mgmt VDOM) has an Inter-VDOM link with subnet 10.20.1.0/24 via Root-to-Prod 1. The Prod VDOM has an Inter-VDOM link with subnet 10.20.2.0/24 via Root-to-Prod 2. The Prod VDOM route to 10.20.1.20 is via port2. Root will send out syslog traffic to Root-to-Prod 1. A firewall policy on Prod VDOM is needed to allow traffic from Root-to-Prod 2, to port2.  If there is no policy, this situation could cause high CPU usage on syslogd due to the loop created by syslog traffic getting denied by implicit deny policy, creating implicit deny logs, and syslogd will try to send the implicit deny logs to the syslog server again. Scenario 2: If the syslog server is set in global and a Syslog server is also set up in a management VDOM by enabling syslog-override, then syslog communication will happen with the syslog server configured in the VDOM. Global: config log syslogd setting set status enable set server "192.168.5.7" set port 1514 end Root VDOM: config log setting set syslog-override enable end config log syslogd override-setting set status enable set server "192.168.5.8" set port 1514 end dia sniffer packet any "port 1514" 4 0 l Using Original Sniffing Mode interfaces=[any] filters=[port 1514] 2024-08-22 14:34:43.592851 port1 out 10.5.146.91.12918 -> 192.168.5.8.1514: udp 566 2024-08-22 14:34:44.592478 port1 out 10.5.146.91.12918 -> 192.168.5.8.1514: udp 566 Now, the root VDOM will generate syslog traffic towards an overridden server IP 192.168.5.8 and there will no more syslog traffic generated for 192.168.5.7. Scenario 3: When configuring a Syslog server globally by enabling syslog-override in the management VDOM and without configuring a Syslog server under syslogd override-setting in the VDOM, there is no traffic generated by the FortiGate. show log syslogd setting config log syslogd setting set status enable set server "192.168.5.7" set port 1514 end show log setting config log setting set syslog-override enable end show log syslogd override-setting config log syslogd override-setting end dia sniffer packet any "port 1514" 4 0 l Using Original Sniffing Mode interfaces=[any] filters=[port 1514] ^C 1 packets received by filter 0 packets dropped by kernel