Question: I have a number of syslog clients behind a NAT device. The receiver receives syslog messages that travelled over the NAT device. This leads the receiver to believe that all messages originated from the same IP address. With stock syslogd, I can not differentiate between the senders. Is there any way to record the correct sender of the message with rsyslog?
Answer: OK, I've now had some real lab time. The good news in short: if you use rsyslog both on the senders as well as on the receiver, you do NOT have any problems with NAT.
To double-check (and out of curiosity), I also tried with stock syslogd. I used the ones that came with RedHat and FreeBSD. Neither of them reports the sending machine correctly, they all report the NAT address. Obviously, this is what made this thread appear, but it is a good verification for the correctness of my lab.
Now, the tcp sender is implemented, allowing rsyslog to be used inside all parts of the relay chain. Please note that tcp/syslog allows to encrypt syslog traffic quite easily. Release 0.9.4 is a major step toward a stable 1.0 release of rsyslog. There are some other minor changes in rsyslog, mostly formatting changes in internally-generated messages.
Hi all,
I have just written a tutorial on encrypting syslog traffic. This is to be released as part of the 1.0 release of rsyslog. I would deeply appreciate if some of you could have a look at it and provide me some feedback.
My intention is to make encrypted syslog much more popular than it is nowadays. Besides a syslogd capable of doing it easy, good documentation is needed. The question is where I have arrrive - and what can be improved. I also intend to ship the configuration files as part of the rsyslogd package.
Please follow the link to the syslog encryption tutorial.
this is primarily a bug fixing release! It fixes a nasty bug where the TIMESTAMP was not properly decoded (just in some months). It also adds the capability to specify the destination port when forwarding messages to remote host. Lastly, a very experimental TCP sender is now included. However, the TCP sender can not yet be used in production, as it causes rsyslogd to hang during certain events, e.g. when connecting to the receiver. As the timestamp bug is a really bad one, all users are advised to upgrade to this version (but not yet use the TCP sender feature).
This is a big step forward for rsyslog. Now, it supports reliable message delivery via TCP. Our implementation is compatible with leading tools and devices like syslog-ng, Cisco PIX and MonitorWare under Windows. Note, however, the 0.9.2 release only supports receiving via TCP. Forwarding is not yet supported. So in a relay chain, rsyslog must be the last daemon to receive the message. Syslog/tcp support is activated via a simple command line switch without any need for complex configuration file changes!
some tweaks in version 0.9.1 have been made so that it now compiles without source changes under FreeBSD. Also, the large file code had a potential bug, which has been fixed. Also some other minor clean-ups.
rsyslog version 0.9.0 now supports log files larger than 2gb (where supported by OS & file system) and the ability to specify the maximum size that a log file is allowed to grow. If it grows larger, a rotation script (or something similiar) can automatically be called from within rsyslog.
Under NetBSD, compilation is also successful as was a quick test. Some minor improvements were made to the debug output (-d), which was previously too verbose. Some information of interest only to developers has been removed, which makes it easier for administrators to see useful information.
It contains a minor fix of the readme file as well as a clean-up of security model dependencies of the install procedure. If you already run rsyslogd, there is no point in updating to this release.
It provides documentation and a more standard installation. In 0.8.2, the man pages have finally been added. Also, rsyslogd now no longer replaces stock syslogd on install. Instead, it installs side-by-side with syslogd. This has the big advantage of removing uncertainty for the user - but it also means that the user needs to modify the system startup scripts.
