Getting Data In

SSL connection between Indexer and Forwarder- validation

garima_chauhan
Path Finder

Hi,

I am not able to configure the ssl connections between the forwarder and indexer. The splunkd logs on both the indexer and forwarder are not the same as cited in the documentation.

Here is what I get on Indexer in splunkd.log:

Date Time +1100 INFO TcpInputConfig - IPv4 port 9997 is reserved for splunk 2 splunk

Date Time +1100 INFO TcpInputConfig - IPv4 port 9997 is not compressed

Date Time +1100 INFO TcpInputConfig - IPv4 port 9997 is reserved for splunk 2 splunk (SSL)

Date Time +1100 INFO TcpInputConfig - IPv4 port 9997 is compressed

Date Time +1100 INFO TcpInputProc - Registering metrics callback for: tcpin_connections

After this, I do not get any other message as mentioned in the documentation.

On Forwarder, I get the following in splunkd.log:

Date Time +1100 INFO TcpOutputProc - found Whitelist forwardedindex.0.whitelist , RE : forwardedindex.0.whitelist

Date Time +1100 INFO TcpOutputProc - found Blacklist forwardedindex.1.blacklist , RE : forwardedindex.1.blacklist

Date Time +1100 INFO TcpOutputProc - found Whitelist forwardedindex.2.whitelist , RE : forwardedindex.2.whitelist

Date Time +1100 INFO TcpOutputProc - tcpout group splunkssl using Auto load balanced forwarding

Date Time +1100 INFO TcpOutputProc - Group splunkssl initialized with maxQueueSize=512000 in bytes.

Date Time +1100 WARN TcpOutputProc - Connected to idx=:9997. Not using ACK.

Date Time +1100 WARN TcpOutputProc - Connected to idx=:9997. Not using ACK.

Date Time +1100 INFO TcpOutputProc - Connection to :9997 closed. Connection closed

For enabling SSL connection between a forwarder and an indexer, I performed the following configurations:

On Indexer(Windows)
I added the following stanzas in $SPLUNK_HOME\etc\system\local\inputs.conf

[splunktcp-ssl:9997]
compressed = true

[SSL]
rootCA = $SPLUNK_HOME\etc\auth\cacert.pem
serverCert = $SPLUNK_HOME\etc\auth\server.pem
password = password

On Forwarder(Windows)
I added the following stanzas in $SPLUNK_HOME\etc\system\local\outputs.conf

[tcpout]
defaultGroup = splunkssl

[tcpout:splunkssl]
compressed = true
server = :9997
sslCertPath = $SPLUNK_HOME\etc\auth\server.pem
sslPassword = password
sslRootCAPath = $SPLUNK_HOME\etc\auth\cacert.pem
sslVerifyServerCert = false

I checked if there were 2 inputs.conf stanzas using port 9997. There were no 2 stanzas using port 9997 but I still changed the port to 9996 for ssl connection.

Despite changing the port, I don't get the output in splunkd.log as mentioned in the splunk documentation.

However, when I checked the metrics.log file on Indexer, I get "ssl=true". Does this mean that ssl is enabled, even though the splunkd logs are not as desired?

Please help.

Tags (3)

MuS
Legend

Hi garima_chauhan,

run this command from the cmd prompt

 %SPLUNK_HOME%/bin/splunk cmd openssl s_client -connect myIDX:9997

this will open a SSL connection to the idx and verify the SSL connection.

find some background information about SSL tests and config changes here

hope this helps ...

cheers, MuS

uchaitanya
New Member

I am having similar problem as above. Can anyone please post the solution for this problem?
Thanks in advance

0 Karma

garima_chauhan
Path Finder

Yes it does give

TcpOutputProc: Connected to idx IP:9996

0 Karma

msarro
Builder

In the splunkd.log on the forwarder, are you seeing messages similar to "TcpOutput: Connected to 1.2.3.4." (Where 1.2.3.4 is the IP address of your indexer)?

0 Karma
Get Updates on the Splunk Community!

More Ways To Control Your Costs With Archived Metrics | Register for Tech Talk

Tuesday, May 14, 2024  |  11AM PT / 2PM ET Register to Attend Join us for this Tech Talk and learn how to ...

.conf24 | Personalize your .conf experience with Learning Paths!

Personalize your .conf24 Experience Learning paths allow you to level up your skill sets and dive deeper ...

Threat Hunting Unlocked: How to Uplevel Your Threat Hunting With the PEAK Framework ...

WATCH NOWAs AI starts tackling low level alerts, it's more critical than ever to uplevel your threat hunting ...