Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 2 subscribers
  • Views 15854 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SYSLOG Packets Being Dropped

UweT
Hello Community Support,

We have a HP WLAN controller (192.168.200.30) that shall forward SYSLOG messages to a client computer (192.168.200.2) but always the Astaro Packet filter log says the packets are dropped as you can see below.

What I can say for sure after troubleshooting: The firewall rules are not even touched that say that SYSLOG traffic in between these two hosts is allowed (although they are in the same VLAN even). It's also not the Intrusion Protection.

I don't know where to look else!

i.e. see this log excerpt: 

13:05:42	Default DROP	UDP	192.168.200.30	:	32780→	192.168.200.1	:	514 len=152	ttl=64	tos=0x00	srcmac=0:3:52:8:16:45	dstmac=0:1a:8c:17:8:19

13:05:42	Default DROP	UDP	192.168.200.30	:	32780→	192.168.200.1	:	514 len=274	ttl=64	tos=0x00	srcmac=0:3:52:8:16:45	dstmac=0:1a:8c:17:8:19

13:05:42	Default DROP	UDP	192.168.200.30	:	32780→	192.168.200.1	:	514 len=219	ttl=64	tos=0x00	srcmac=0:3:52:8:16:45	dstmac=0:1a:8c:17:8:19

13:05:42	Default DROP	UDP	192.168.200.30	:	32780→	192.168.200.1	:	514 len=224	ttl=64	tos=0x00	srcmac=0:3:52:8:16:45	dstmac=0:1a:8c:17:8:19


it goes like this forever....

Regards,
Uwe


This thread was automatically locked due to age.
  • 0
    1. 

    PING 192.168.200.2 (192.168.200.2) 56(84) bytes of data.
    64 bytes from 192.168.200.2: icmp_seq=1 ttl=128 time=0.456 ms
    64 bytes from 192.168.200.2: icmp_seq=2 ttl=128 time=0.454 ms
    64 bytes from 192.168.200.2: icmp_seq=3 ttl=128 time=0.434 ms
    64 bytes from 192.168.200.2: icmp_seq=4 ttl=128 time=0.489 ms
    64 bytes from 192.168.200.2: icmp_seq=5 ttl=128 time=0.396 ms
    --- 192.168.200.2 ping statistics ---
    5 packets transmitted, 5 received, 0% packet loss, time 4000ms
    rtt min/avg/max/mdev = 0.396/0.445/0.489/0.040 ms

    2. exactly!! Well, it's all the same network mask. On the controller I cannot find anything unusual.
  • 0
    1. Thanks for the confirmation.

    2. It is strange that the WLAN controller is configured to send syslog to .200.2, but that the Astaro is receiving packets addressed to 192.168.200.1 - it's IP on the Internal interface.  And you confirmed that the controller sends to 192.168.200.2, that it has default gateway of 192.168.200.1 with netmask 255.255.255.0?

    Cheers - Bob
  • 0 in reply to BAlfson
    Hello BAlfson,

    indeed, I just double checked the network settings of the controller. It all has been set up properly.

    Besides the very root cause that I still cannot identify: Why does the Astaro drop all those syslog, UDP, Port 514 packets by using the rule 60001? Whatever additional rule I set up it doesn't help. How can I "force" the Astaro to apply the packet filter rules I have configured?
  • 0
    How can I "force" the Astaro to apply the packet filter rules I have configured?
    A hidden "system" rule is being applied first.  The first rule that matches "wins".
  • 0
    Scott, I think 60001 is the default drop rule for the INPUT chain, so I think Uwe has a different problem.

    The packet dropped is one that was going to .1 (the IP of the Internal interface), not to .2 (the syslog PC).  If the WLAN controller is configured correctly, then there's something else causing the packet to be re-addressed.

    Uwe, if you can't find the reason for that problem, a "band-aid" solution (not clean, but it should work) would be a DNAT '{192.168.200.30} -> {514/UDP} -> Internal (Address) : DNAT to {192.168.200.2}' (leave 'Destination service' blank, and be sure to use the address object for the internal interface instead of a Host definition).

    Cheers - Bob
  • 0
    Agreed.  Whatever is causing the traffic to go through the Astaro is the root cause of the problem, not just a symptom.  If we could figure that out, the problem would be solved.  

    @UweT:  Do you have a L3 switch between the WLAN controller and the Astaro that might be causing this?
  • 0 in reply to Scott_Klassen
    A HP Procurve core switch is in between. But where to look at would be the question...