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