Fortigate sending to Syslog AND FortiAnalyzer

[MontanaMike]

I know this was possible in older versions of the firmware but I'm having issues getting my Fortigates to send data to both my syslog server and the FortiAnalyzer at the same time.  Is it possible that the FortiGate isn't sending to the syslog because the FortiAnalyzer is configures with the Security Fabric turned up?  I'm checking with the linux admin of the syslog host to make sure he has port 514 open on it but thought I'd check here to make sure it was still an option even though Fortinet removed the syslog option from the GUI.  I configured it from the CLI and can ping the host from the Fortigate.  Any help or tips to diagnose would be much appreciated.  My Fortigate is a 600D running 6.4.12 build 2060

config log syslogd setting
set status enable
set server "172.16.50.214"
set mode reliable
set port 514
set facility user
set source-ip "172.16.50.2"
set format default
set priority default
set max-log-rate 0
set enc-algorithm disable
set interface-select-method specify
set interface "Amicus Servers"
end

config log syslogd filter
set severity information
set forward-traffic enable
set local-traffic enable
set multicast-traffic enable
set sniffer-traffic enable
set anomaly enable
set voip enable
set filter ''
set filter-type include
end

[Anthony_E]

Hello Mike,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[srajeswaran]

Ideally it should work. Can you run below sniffer to see if there are packets towards the server?

diagnose sniffer packet any "host 172.16.50.214 and port 514" 4 100

[MontanaMike]

Here is the output of that:

1.671378 port17 out 172.16.50.2.20206 -> 172.16.50.214.514: udp 647
1.681397 port17 out 172.16.50.2.7519 -> 172.16.50.214.514: udp 1164
1.767954 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 1203
1.769934 port17 out 172.16.50.2.20206 -> 172.16.50.214.514: udp 621
1.781381 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 1124
1.781421 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 559
1.781443 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 1156
1.788252 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 1147

[jintrah_FTNT]

Hi,

Please check if the syslog server accepts reliable connection, or udp (most common) which is widely used(If udp is used, please set the mode to udp ). Other thing is about the route to 172.16.50.2, please check the route table points route to the server using interface "Amicus Servers", if no route exist through this specified interface, then chances of failures are high.

Best regards,

Jin

[MontanaMike]

The documentation says to set the fortigate to reliable so it supports that.

[jintrah_FTNT]

Ok. But now its seen sending UDP packets.

1.671378 port17 out 172.16.50.2.20206 -> 172.16.50.214.514: udp 647
1.681397 port17 out 172.16.50.2.7519 -> 172.16.50.214.514: udp 1164
1.767954 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 1203
1.769934 port17 out 172.16.50.2.20206 -> 172.16.50.214.514: udp 621
1.781381 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 1124
1.781421 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 559
1.781443 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 1156
1.788252 port17 out 172.16.50.2.11494 -> 172.16.50.214.514: udp 1147

Anyways, we should  check why traffic leaves port17 instead of 'Amicus Servers' interface. Is there a route to 172.16.50.214 via 'Amicus Servers' interface? if so, you can clear the existing session and force the traffic to restart sending through 'Amicus Servers' interface.

Best regards,

Jin

[MontanaMike]

Port 17 is the physical interface and "Amicus servers" is a vlan interface tagged across port17.  172.16.50.2 is the vlan interface and 172.16.50.214 is the syslog server.  Same mask and same "wire".  It's not a route issue or a firewalled interface.  Both hosts (the Fortigate and the syslog server) can ping each other.

[jintrah_FTNT]

It appears there existed a route to 172.16.50.214 through port17 earlier at some stage(or may be there was only a default route through port17 before the vlan was created). The traffic has to leave "Amicus servers" interface though. Since route is not an issue now as mentioned, you should clear the existing session so that traffic could then be send through"Amicus servers"  interface.

diag sys session filter src 172.16.50.2

diag sys session filter dst 172.16.50.214

diag sys session clear

You can check the sniffers again after clearing the existing session and see if traffic egress out through the vlan interface.

best regards,

Jin

[mgoswami]

I would like to ask if you can restart the process that handles logging.
It can be done:

fnsysctl killall miglogd

Please let me know if that helped.