Setting up the Enterprise Server's Universal Forwarder
Introduction
On the sixth day, the corporate server's Splunk Universal Forwarder was configured to fortify the on-premise data pipeline. To make sure that essential system events were safely gathered and transmitted to the Splunk indexer, I configured log forwarding. By completing the on-premise monitoring loop, this phase allowed for centralized visibility and established the foundation for use cases, including sophisticated detection.
Objective
The objective is to set up the Enterprise Server's Universal Forwarder to efficiently collect, process, and forward data to the designated indexer or indexer cluster, ensuring secure and reliable data transmission.
The Shift: From Cloud to On-Prem
Building a Self-Contained Lab Environment
Previous Days: I sent data from a forwarder to the cloud (Splunk Cloud instance).
Today's Mission: I am sending data from a forwarder to my own server (on-prem Splunk Enterprise on Windows Server).
Why? To build a fully functional, self-contained lab that doesn't rely on an external cloud trial. This mirrors many real-world corporate environments.
Installation of the Universal Forwarder
Use of Windows Server IP address instead of the cloud instance URL to configure the deployment server
Crucial Installation Step:
When the installer prompts for the "Receiving Indexer" or "Deployment Server", I now enter the IP Address of my Splunk Enterprise server, 192.168.1.50, on my Windows Server.
Port: 9997 (the receiving port you configured on Day 5)
Using the same IP Address for the Configuration of the receiving server
Because I am using the same enterprise to receive the logs
CLI Configuration
The Manual Handshake
To configure or change the settings after installation:
Open an Administrator PowerShell.
Navigate to the UF bin directory:
cd "C:\Program Files\SplunkUniversalForwarder\bin"
Set the forward server to your on-prem Splunk Enterprise instance:
.\splunk.exe add forward-server :9997
Why Most On-Prem Labs Fail
The Problem: Even with everything configured correctly, the Windows Firewall on your Splunk Enterprise server will block incoming connections on port 9997 by default. This is the most common point of failure.
The Solution: You must create an Inbound Rule in the Windows Firewall to allow traffic.
Why This is Important: This simulates a real-world network security group and firewall configuration.
Configuring the Windows Firewall Rule
On your Splunk Enterprise server, you can open Windows Defender Firewall with Advanced Security.
Click on Inbound Rules > New Rule...
I need to configure a new rule to send data to the receiving server port.
Rule Type: Select Port and click Next.
I set up the same receiving port I chose during agent installation as a TCP port.
Protocol and Ports: Select TCP, specify 9997 (or your chosen port), click Next
Select Allow the connection, and click Next.
Profile: Apply to Domain, Private, and Public (for a lab), click Next.
Give it a clear name (e.g., "Splunk - Receiving Port 9997").
Click Finish.
Restart and Verify: Activating the Changes
Restart the Forwarder Service to apply all configurations and attempt a new connection:
.\splunk exe restart
Could you check the Forwarder's Status: Look for any errors and confirm it's running?
.\splunk.exe status
Could you check the Forwarder's Logs: The best place to see the connection attempt?
Get-Content "C:\Program Files\SplunkUniversalForwarder\var\log\splunk\splunkd.log" -Tail 20
Look for "Connected to peer" or similar success messages.
Verification & Reflection
The On-Prem Pipeline is Complete
The Ultimate Test: I successfully logged in to the on-prem Splunk Enterprise Web interface (localhost:8000).
I Run This Search: index=* | stats count by host
Success! I now see the hostname of the machine where I just installed the new forwarder appearing in the search results.
Goal Achieved: Data is now flowing from the endpoint, through the network, into my own Splunk server, without any cloud dependency.
Day 6 was about networking and infrastructure. The skill of configuring firewalls and understanding network connectivity is just as important as installing the software itself.
Top comments (0)