The most common causes of this are that you have firewall rules that are
blocking the traffic
In particular, Redhat requires you to add firewall rules to allow traffic on
port 514, it's no longer open by default.
I've also had a case in a highly segmented network where we didn't have default
routes on a box where the lack of a route to get to the machine sending me the
logs caused the traffic to show up in tcpdump, but get dropped before it got to
the syslog application.
David Lang
On Fri, 6 Dec 2013, Bill MacAllister wrote:
Date: Fri, 06 Dec 2013 18:28:01 -0800
From: Bill MacAllister <[email protected]>
Reply-To: rsyslog-users <[email protected]>
To: rsyslog-users <[email protected]>
Subject: [rsyslog] udp data not being handled
I am just starting to setup a central syslog service using rsyslog and
could use some help understanding a problem that I am seeing. A
storage device is configured to send syslog data to my test server.
(Don't know what the device is. That is someone else's problem.)
Nothing is showing up at the rsyslog server and I was about to tell the
manager of the device to fix their configuration/firewall/network until
I fired up tcpdump. Here is what I see:
17:37:22.940285 IP stg3170d2.Stanford.EDU.syslog >
logsink-dev.stanford.edu.syslog: SYSLOG local7.debug, length: 375
17:37:22.940314 IP logsink-dev.stanford.edu > stg3170d2.Stanford.EDU: ICMP
logsink-dev.stanford.edu udp port syslog unreachable, length 411
17:37:23.069460 IP stg3170d2.Stanford.EDU.syslog >
logsink-dev.stanford.edu.syslog: SYSLOG local7.debug, length: 375
17:37:23.069485 IP logsink-dev.stanford.edu > stg3170d2.Stanford.EDU: ICMP
logsink-dev.stanford.edu udp port syslog unreachable, length 411
But, nothing is being written by rsyslog that I can see. The
configuration is fairly simple. With some fragments for specific logs
and a catch all rule. Below are the important bits pulled together
for readability. (It is a bit of a hodgepog of formats because I am
new at this.)
$ModLoad imuxsock
$ModLoad imklog
$ModLoad imtcp
$InputTCPMaxListeners 64
$InputTCPMaxSessions 1024
$InputTCPServerRun 514
# udp inputs
$ModLoad imudp
$UDPServerAddress *
$UDPServerRun 514
# Use the traditional timestamp format. Too much of our software expects it.
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
# Default permissions for log files.
$FileOwner root
$FileGroup root
$FileCreateMode 0640
$DirCreateMode 0755
if $hostname startswith 'stg' then {
action(type="omfile" file="/var/log/remote/storage.log")
stop
}
$template Remote, "/var/log/remote/default.log"
:source , !isequal , "logsink-dev" -?Remote
:source , !isequal , "logsink-dev" stop
*.emerg :omusrmsg:*
*.debug :omfile:/var/log/messages
*.err :omfile:/dev/console
If I use netcat to send udp packets to port 514 the results show up in
default.log as I expect. When I run the rsyslogd in debugging mode in
one window and tcpdump in another I see tcpdump show of data from the
arrival of packets from stg3170d2 but nothing in the rsyslog debugging
output.
I am using rsyslog version 7.4.4. What am I missing?
And in looking at the configuration I see that the recommendation is
that tcp and udp listeners be run on different ports. In my testing
running them on the same port seems to work. Does it really make a
difference?
Thanks in advance,
Bill
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
