Zabbix passive communication extra rst packets?

[erasedhammer]

Been having problems with zabbix passive traffic flooding my UFW log with the last rst packet coming from the zabbix agent. I think that after the server sends its rst, it closes the socket and the agent on the client sends one to two more rst packets that are flagged by UFW as not part of the original tcp connection and are blocked.
I have no problems with the data coming back at all, but the fact that the clients are sending these rst packets after the server closes the connection is annoying, and makes it harder to review my UFW log for actual blocked connections.

So why does the zabbix agent have this behavior?

UFW Log:
Nov 11 11:20:38 nms kernel: [54047.242636] [UFW BLOCK] IN=enp2s0 SRC=172.20.20.4 DST=10.10.3.2 LEN=40 TOS=0x00 PREC=0x00 TTL=62 ID=0 DF PROTO=TCP SPT=10050 DPT=57084 WINDOW=0 RES=0x00 RST URGP=0

[dimir]

You are using encrypted traffic, right?

[erasedhammer]

You are using encrypted traffic, right?

Yes, Zabbix traffic is encrypted by default?

[dimir]

By default - no, you have to set the encryption up on both the server and the client side.

[erasedhammer]

By default - no, you have to set the encryption up on both the server and the client side.

As yes, now I remeber setting it up.

Any idea why the agent is sending these extra rsts?

[dimir]

We believe it's because of using TLS library, perhaps in not completely correct way. Will try to get more information on this. If you are able to recompile Zabbix and try the recompiled binary in this scenario I could provide you with the patch. In this case I need to know Zabbix version you are using.

[erasedhammer]

We believe it's because of using TLS library, perhaps in not completely correct way. Will try to get more information on this. If you are able to recompile Zabbix and try the recompiled binary in this scenario I could provide you with the patch. In this case I need to know Zabbix version you are using.

I am using zabbix server 5.0 LTS. Or do you need the agent version?

[dimir]

If it's not possible for both we can try with the agent. Which exact version and which tls library are you using (OpenSSL, GnuTLS)?

[erasedhammer]

If it's not possible for both we can try with the agent. Which exact version and which tls library are you using (OpenSSL, GnuTLS)?

I forgot what exact version the agent was, but this problem I have observed over several devices from 4.0 to 5.0. I am using OpenSSL

[1977er]

I can reproduce the behaviour on a Zabbix 5.0.20 server with a 5.0.20 agent(1). The problem persists even after disabling encryption.

[root@agent]:~ # tcpdump -ni eth0 -v 'tcp[tcpflags] & (tcp-rst) != 0 and port 10050'

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:03:33.747673 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 40)
server-addr.54636 > agent-addr.10050: Flags [R], cksum 0x587f (correct), seq 1099060185, win 0, length 0
13:03:33.747704 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 40)
server-addr.54636 > agent-addr.10050: Flags [R], cksum 0x587f (correct), seq 1099060185, win 0, length 0
13:03:33.756526 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 40)
server-addr.54640 > agent-addr.10050: Flags [R], cksum 0xb9c1 (correct), seq 3996665308, win 0, length 0
13:03:33.756601 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 40)
server-addr.54640 > agent-addr.10050: Flags [R], cksum 0xb9c1 (correct), seq 3996665308, win 0, length 0