Fortigate suddenly stops commincating with Forticollector/Fortianalyzer

Hello,

Yes happened to both units in different locations, one of them it has happened to before, the 600c (reboot device and works perfectly again).

When running the sniffer on FTG and FAZ, I can see the FTG generating the UDP 514 log traffic, but never gets to FAZ.

Which make sense, as I know I have confirmed, I cannot ping FAZ/Collector. Unable to trace to it or ping it. Yet I can ping an address on same subnet / network as the FAZ, literally the IPs that I can reach can be side by side, to that of the FAZ which I cannot reach.

Also from next hop/routed path, which is a core switch I am able to ping FAZ/collector perfectly fine. There are no ACL's / policies in place that would prevent traffic being sent and there has been no changes to device.

As I say it just suddenly will not ping the FAZ, and again only ever appears to lose connectivity with the FAZ, nothing else, hence why I decided to post in the logging forum.

I know a reboot will fix it, but just seems strange that it would suddenly do this out of the blue.

Kind regards

Scott

This is how strange the issue is, in this location we have two collectors , and one analyzer (as we split this by region to share load of log collection, and then send logs onto analyzer in each location).

10.111.164.24 is the analyzer

10.111.164.25 is the collector this unit should log too

10.111.164.26 is another collector in same region

This is the Fortianalyzer settings pointing it to the .25 collector:-

# config log fortianalyzer setting

 (setting) # show config log fortianalyzer setting set status enable set server 10.111.164.25 set upload-option realtime end

Ping to collector it should log to does not work.

# execute ping 10.111.164.25 PING 10.111.164.25 (10.111.164.25): 56 data bytes

--- 10.111.164.25 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss

Pings to other collector/analyser literally single digits away in same VLAN/Subnet

 # execute ping 10.111.164.24 PING 10.111.164.24 (10.111.164.24): 56 data bytes 64 bytes from 10.111.164.24: icmp_seq=0 ttl=60 time=100.9 ms 64 bytes from 10.111.164.24: icmp_seq=1 ttl=60 time=39.5 ms 64 bytes from 10.111.164.24: icmp_seq=2 ttl=60 time=78.4 ms 64 bytes from 10.111.164.24: icmp_seq=3 ttl=60 time=40.7 ms 64 bytes from 10.111.164.24: icmp_seq=4 ttl=60 time=77.8 ms

--- 10.111.164.24 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 39.5/67.4/100.9 ms

# execute ping 10.111.164.26 PING 10.111.164.26 (10.111.164.26): 56 data bytes 64 bytes from 10.111.164.26: icmp_seq=0 ttl=60 time=53.3 ms 64 bytes from 10.111.164.26: icmp_seq=1 ttl=60 time=43.7 ms 64 bytes from 10.111.164.26: icmp_seq=2 ttl=60 time=41.9 ms 64 bytes from 10.111.164.26: icmp_seq=3 ttl=60 time=38.7 ms 64 bytes from 10.111.164.26: icmp_seq=4 ttl=60 time=39.9 ms

--- 10.111.164.26 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 38.7/43.5/53.3 ms

Again no policies or devices in the way that would be blocking any of this traffic. Routing is done either at the /16 or /24 bit boundary's of the subnets and confirmed they are there, and was working previously, just stops working suddenly, and only reboot seems to fix issue.

Kind regards

Scott