Hi, [ cut ]
Syslog-NG 2.0.10 on Machine A is configured as follows: =======================================================
options { log_fifo_size(1000); long_hostnames(off); use_dns(no); use_fqdn(no); keep_hostname(yes); check_hostname(yes); log_msg_size(16384); };
source s_network { udp(ip(0.0.0.0) port(514)); tcp(ip(0.0.0.0) port(514) max_connections(1000)); };
destination d_syslogmgr { tcp("127.0.0.1" port(5514)); };
[...]
Unfortunately you omitted the actual log section.
Syslog-NG 2.0.10 on Machine B is configured as follows: =======================================================
options { log_fifo_size(1000); long_hostnames(off); use_dns(no); use_fqdn(no); keep_hostname(yes); check_hostname(yes); log_msg_size(16384); };
[...]
Again vital information is missing like the source definition and the log section(s) where the source gets used. [ cut ]
Ideally, I would prefer that the 127.0.0.1 was actually the 172.XX.YY.1 IP address, but it appears that there is a re-write of IP addresses going on. I have placed a packet sniffer on the line and I can see that the packet which is actually sent to MACHINE B is correct (including the correct IP addresses). To me it would appear that the issue is in the processing of the message at MACHINE B, but the issue may lie elsewhere.
Sniffing an ssh tunnel on the wire? You must have a cool sniffer. An strace of syslog-ng on machine B would help a lot to see what's going on actually. When keep_hostname is used then hostname "rewriting" should happen only when the log message doesn't contain a hostname or an IP address. My wild guess would be that you're using the HOST_FROM macro which gets replaced by 127.0.0.1. The HOST macro should contain the originating hostname/IP address. Regards, Sandor -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.