Universal forwarder overwrites log source IP, inserting its own UF ip when forwarding logs to search head

[leebsr]

Hi guys,

I have a gd issue here. My universal forwarder sends logs to a splunk search head, and the search head sees the logs with the IP of the universal forwarder as if it were the log source, when it is actually not, it is just forwarding logs from the sources.

How can I get rid of this so I can see at the searches the real log source IPs ??

Is there a reason why this IP overwrite could be useful ?  I dont see it and for now what I need is to have real IPs on the search heads.

Craving for a solution

[richgalloway]

Please tell us more about your Splunk environment? How are the data sources getting to the UF? Are you using the UF as a syslog server? If so, that's not a good practice.
Why is the UF sending data to the SH instead of the indexer(s)?

[leebsr]

Hi richgalloway 1st of all many thanks for your quick answer.

Correct in this environment I belive that they have configured the UF as well as a syslog server. I need to confirm this though.

Could you please give further details on the correct architeture for the UF and the log source ---> splunk flow ?

I believe that what you mean in your second part of the answer is that the uf should be pointing and sending logs to the inderxers and later on when querying the sh, it will send the query to the indexers which will perform the dirty job, right ? and then indexers will send their output to the sh correct ? is that the right arch ?

[richgalloway]

UF as a syslog server has a number of issues, but your configuration of a UF installed on a dedicated syslog server is considered Best Practice.  Thanks for clarifying that.

Can you share the inputs.conf settings on the UF for one of the problem data sources?

Yes, forwarders (and search heads) should be forwarding data to indexers.

[leebsr · Accepted solution]

Thanx !

I checked the inputs.conf and it is already solved there since we put there that the log source should be the 7th parameter of the folder holding its logs which is the IP of the actual log source.

Solved then !