Just tried to start sending netflow data from my Untangle 16.4.1 to my Graylog server (v4.0.14, on Debian 11) using Netflow V9, but all the incoming messages started at timestamp Dec 31, 1969, and have been slowing incrementing.
Under System->Overview, scroll down to Time configuration - double check there. What Input are you using? There is a Netflow UDP input… If it’s not giving you the right information, you may need to switch to a RAW input.
I don’t think UDP raw is going to be a better solution. The timestamps are right, but all the messages are truely indeed RAW:
** h2:�mT��a0�0� M�’B�a�0�0��’B�e��0�0�=�>'B��0�0��’B�>��0�0�=�’B��0�0��’B���0�0�**
Checking out Untangle from SSH, everything seems fine with the clock:
Local time: Fri 2022-01-21 22:04:26 EST
Universal time: Sat 2022-01-22 03:04:26 UTC
RTC time: Sat 2022-01-22 03:04:19
Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
NTP service: inactive
RTC in local TZ: no
I will say, I don’t have my firewall connected to command center. But I don’t know why that would affect netflow?
Untangle seams to be sending epoch time That’s the reason I gave you those links to check out
other community members in Untangle forum that seam to have the same problem. Elasticsearch received those messages as epoch time.
If your 100% sure that there is not a problem on Untangle then the next post should show how to adjust it that type of Date/time if you cant adjusted in Untangle.
EDIT : Sorry My epoch time is off in the example above, you may want to look here if you need to adjust Date/Time
I’m a little lost by what you are saying.
I’m not sure what problem could be occuring with Untangle, but all I can assume is that this is a graylog issue, as other logs (From untangle) do not have this timestamp problem. Just netflow.
If the problem is how Untangle is sending netflow, then that is out of my control.
The messages being received by graylog have the timestamp in this format: “1970-01-22 23:57:13.306 -05:00”. They do not arrive in seconds since 1970. They might arrive in seconds and graylog is formatting it, but that is out of my control.
If the other untangle devices does not have Netflow enable, then I assume there send syslogs. Then the timestamp would be correct.
If the untangle device that has Netflow enable on it sending logs to Graylog using INPUT Netflowv9 it now sending those message in epoch time. In my environment I had to adjust the Date/Time after enabling Netflow. The links above stated that the only way to adjust this in in the console of the Untangle device.
Are you able to capture those message being received from the untangle device with Netflow enabled before they are ingested through Graylog? Then you will know for sure if it Input or the remote device has the incorrect date/time.
Couple of quick points, I don’t mind blaming Graylog but a lot of folks are using the NetFlow input swimmingly, so let’s see what else we can do.
Untangle has a bit of history with weird NetFlow time stamps
Double check you’re Netflow version on Untangle is v9
Try just using your Graylog server as the raw receiver. This will grab the raw data on port 2055 UDP and dump it to a file called netflow_capture. Modify as you need and point Untangle to send to the port you choose (2055 in this example). Show us that file and we can probably get you sorted.
nc -ul 2055 > netflow_capture
My theory - Untangle is using IPFIX headers, so the epoch theory was probably right. Graylog is seeing a number like 2345 (millisecond since capture) when it expects 1642411499 (ms since 01 Jan 1970, standard epoch time). You’re looking at the converted time stamp in the UI (your screenshots).
NetFlow also has a different time mechanism than syslog, so it’s perfectly logical that one type can work while the other doesn’t.
Without seeing the raw data from Untangled one way or another we can’t point the finger in any direction.