Stumbled upon the incomprehensible behavior of netfilter. Suppose there are 4 servers on centos6 configured absolutely similarly. The first two send logs to the third, the third postrouting set postrouting (see the rules below) to the fourth, the fourth simply collects them (netfilter is not configured on it).

The strangeness is that I see syslog traffic from the first (10.0.0.1) server throughout the chain, but at the same time the second (10.0.0.2) traffic is fully on the third (192.168.0.5) server with postrouting , but it does not redirect it to the fourth (192.168.0.6) and in iptables -nvL -t nat counters are not incremented on it. To be precise, it only redirects any specific syslog — auth.info , and, for example, user.info not want to redirect user.info . But this is nonsense, netfilter is not engaged in the analysis of the level of logging.

iptables-save third

  # Generated by iptables-save v1.4.7 on Fri Apr 27 14:31:48 2018 *mangle :PREROUTING ACCEPT [113944481:33094585962] :INPUT ACCEPT [36662612:8817293771] :FORWARD ACCEPT [77275595:24276061507] :OUTPUT ACCEPT [20980539:14824196963] :POSTROUTING ACCEPT [98253790:39099771398] COMMIT # Completed on Fri Apr 27 14:31:48 2018 # Generated by iptables-save v1.4.7 on Fri Apr 27 14:31:48 2018 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [77275534:24276051904] :OUTPUT ACCEPT [20980520:14824192939] -A INPUT -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 30 -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 192.168.0.0/19 -j ACCEPT -A INPUT -s 10.0.0.0/24 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on Fri Apr 27 14:31:48 2018 # Generated by iptables-save v1.4.7 on Fri Apr 27 14:31:48 2018 *nat :PREROUTING ACCEPT [1068499:66961971] :POSTROUTING ACCEPT [653110:39701523] :OUTPUT ACCEPT [2512:193995] -A PREROUTING -s 10.0.0.1/32 -d 192.168.0.5/32 -p udp -m udp --dport 514 -j DNAT --to-destination 192.168.0.6:514 -A PREROUTING -s 10.0.0.20/32 -d 192.168.0.5/32 -p udp -m udp --dport 514 -j DNAT --to-destination 192.168.0.6:514 -A PREROUTING -s 10.0.0.2/32 -d 192.168.0.5/32 -p udp -m udp --dport 514 -j DNAT --to-destination 192.168.0.6:514 COMMIT # Completed on Fri Apr 27 14:31:48 2018 # Generated by iptables-save v1.4.7 on Fri Apr 27 14:31:48 2018 *raw :PREROUTING ACCEPT [113944408:33094574090] :OUTPUT ACCEPT [20980533:14824201419] -A PREROUTING -p dccp -j NOTRACK -A OUTPUT -p dccp -j NOTRACK COMMIT # Completed on Fri Apr 27 14:31:48 2018

Examples of dumps from the third server [From the first to the third]

  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 14:43:13.467236 IP 10.0.0.1.15598 > 192.168.0.5.514: SYSLOG user.info, length: 112 14:43:13.467249 IP 10.0.0.1.15598 > 192.168.0.6.514: SYSLOG user.info, length: 112 14:43:13.467252 IP 10.0.0.1.15598 > 192.168.0.6.514: SYSLOG user.info, length: 112 14:43:13.523133 IP 10.0.0.1.15598 > 192.168.0.5.514: SYSLOG user.info, length: 89 14:43:13.523133 IP 10.0.0.1.15598 > 192.168.0.5.514: SYSLOG user.info, length: 89 14:43:13.523142 IP 10.0.0.1.15598 > 192.168.0.6.514: SYSLOG user.info, length: 89 14:43:13.523144 IP 10.0.0.1.15598 > 192.168.0.6.514: SYSLOG user.info, length: 89 14:43:13.523317 IP 10.0.0.1.15598 > 192.168.0.5.514: SYSLOG user.info, length: 79 14:43:13.523317 IP 10.0.0.1.15598 > 192.168.0.5.514: SYSLOG user.info, length: 79 14:43:13.523326 IP 10.0.0.1.15598 > 192.168.0.6.514: SYSLOG user.info, length: 79

[From second to third]

  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 14:43:25.861971 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 112 14:43:25.876292 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 134 14:43:25.876292 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 134 14:43:25.876512 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 90 14:43:25.876512 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 90 14:43:25.876680 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 78 14:43:25.876680 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 78 14:43:25.876857 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 85 14:43:25.876857 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 85 14:43:25.876993 IP 10.0.0.2.18469 > 192.168.0.5.514: SYSLOG user.info, length: 98

    1 answer 1

    This is not the answer to the question, but some considerations.

    The first .

    It is very difficult to understand and troubleshoot network issues without having a clear understanding of the network infrastructure. The network likes a clear scheme. Trying to understand from the free narrative and canvases of iptables rules, what is there, where and why is difficult. I doubt that someone will sit, draw on a piece of paper hosts, IPs, think out the network environment, etc.

    It would be much easier if there were less (or not at all) additional questions.

    For this, it is nice to describe the scheme in the form:

     host1 - ip.address.0.1 host2 - ip.address.0.2 и т.д. Сети такие-то, маски такие-то, шлюзы такие-то.

    This description will already give a very specific idea of ​​the infrastructure.

    But it is, by the way.

    The second .

    If your task is to collect syslogs on the final (fourth) host, and not the practice of iptables, then I would not touch the network part at all, and the "low-level" routing.

    All this can be solved with the standard rsyslog.

    The first two hosts send logs to the rsyslog of the third host, which in turn acts as a proxy, redirecting them to the rsyslog of the fourth host.

    On the third host in the rsyslog config it is necessary to register the corresponding rule, such as:

     if $fromhost-ip=='abcd' then forward_to_another_host
    • For some inexplicable reason, the third server changed my mind the next morning and started routing all the traffic from the second server ... some poltergeist. - who know
    • @whoknow then you can safely delete your question, because he now has no meaning. - de_frag