[syslog-ng] Issues with SYSLOG-NG 2.0.10 and relaying via a SSH tunnel

[Dean Thompson]

Hi Everybody,

I was wondering whether somebody might be able to help me with a problem 
which appears to have been discussed before but is still continuing to 
be a problem for an environment that I am working within.  The issue 
relates to one host forwarding SYSLOG messages to another host via a SSH 
tunnel.

Scenario:
=========

<Device> --SYSLOG MESSAGE--> Machine A <--SSH Tunnel--> Machine B

Items to note include Machine B setting up a reverse SSH tunnel with 
Machine A.  Machine A has a local port of 5514 that it uses to forward 
syslog messages to which sents them to machine B.  This connectivity is 
working without any problems.

The issue that I am currently experiencing is on Machine B when looking 
at the logs delivered via Machine A.  It would appear that Machine B 
thinks that all the logs are coming from the IP address of 127.0.0.1.  I 
have checked the configuration of syslog-ng on machine A and machine B 
and they look as if they are configured correctly.

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)); };

[...]


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);
};

[...]


Output that is being observed:
==============================

Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 3317162: 3339552: Jan  7
12:37:09.608: %LINK-3-UPDOWN: Interface FastEthernet0/7, changed state
to up
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 3317163: 3339553: Jan  7
12:37:10.457: %LINK-3-UPDOWN: Interface FastEthernet0/7, changed state
to down
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 23:37:07 accept 172.XX.YY.242
 > >eth-s2p2c3 src: 192.168.17.48; dst: 192.168.19.167; proto: tcp; rule:
22; product: VPN-1 & FireWall-1; service: 9999; s_port: 3310;
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 23:37:07 accept 172.XX.YY.242
 > >eth-s2p4c1 src: XXX.YYY.235.195; dst: 192.168.108.1; proto: udp; rule:
5; product: VPN-1 & FireWall-1; service: 53; s_port: 5707;
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 23:37:07 accept 172.XX.YY.242
 > >eth-s2p4c1 src: XXX.YYY.235.197; dst: 192.168.108.1; proto: udp; rule:
5; product: VPN-1 & FireWall-1; service: 53; s_port: 11639;
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 23:37:08 accept 172.XX.YY.242
 > >eth-s2p4c1 src: XXX.YYY.235.196; dst: 192.168.108.1; proto: udp; rule:
5; product: VPN-1 & FireWall-1; service: 53; s_port: 1325;
Jan  7 12:32:34 127.0.0.1 172.XX.YY.1 8023816: Jan  7 23:37:09.028:
%SYS-CFC8-2-MMAP: mmap failed for size 24576 bytes Caller PC 0x72B12BCC
errno 12 : ios-base : (PID=20499, TID=23) :
-Traceback=(c6lc2-sp-4-dso-b.so+0x1F9AD0) ([19:0]+0x204790)
([19:0]+0x20CEDC) ([16:-2]np.+0x84BD4) ([21:0]+0x855B8)
([9:-3]1-dso-b+0x1FE904) ([9:-3]0-dso-bn+0xD354C) ([20:0]+0xD2658)
([20:0]+0xD29D0) ([9:-3]2-dso-b+0x4E4684) ([19:0]+0x4E465C)

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.

Is there anything obvious with the configurations which would be 
contributing to this problem, or is my basic understanding of how 
SYSLOG-NG works when  wanting to keep hostnames and IP addresses flawed ?

Regards,

Dean