Search and filtering in port protocol

IPFire 2.29 (x86_64) - Core-Update 203

Hello,
we have a problem to find the reason of an error. There is a service on a Windows machine on port 11000. This service sends “heartbeats” to clients out site the green LAN and receive answers - all 5 seconds.
But after some time … no heartbeat answers come back. In iPFire port logbook many lines with port 11000 (most NAT and FORWARDFW) - 2 … 4 every second. - 100 000 a day !
I*m shore it’s possible to filtering protocol only lines without NAT & FORWARDFW on console, but help me how?

What is the default firewall behavior configured under the Firewall Options?
Have you configured any firewall rules to use this service?

You can reduce the amount of logging by changing the Logging options:
IPFire Firewall Options documentation

Alternatively, you can create a firewall rule with “log rule” disabled.

Thank you,…

What is the default firewall behavior configured under the Firewall Options?
Have you configured any firewall rules to use this service?

Yes we have a rule [all lans: port 11000]→ IP:11000 …

You can reduce the amount of logging by changing the Logging options:
IPFire Firewall Options documentation

We enabled log, because of find errors. But there are too much lines in log → we will read the f doc.

Instead of “all lans,” you should use the Windows server’s IP address.
If you open a port to “all”, other machines might detect it and attempt to connect to it.

… a little piece of the port protocol - hope someone understand what it means:

This means that you have a Destination NAT iptable rule redirecting incoming packets on ppp0 (RED) from 80.153.228.106 port 11000 to 10.2.2.100 port 11000, with logging enabled.

In lines 2 and 3, the redirection is working:

81.89.161.173 → 80.153.228.106:11000 → 10.2.2.100:11000

Regarding the DROP_CTINVALID messages, I think these are packets belonging to previous connections that were interrupted, became invalid, or expired from the conntrack table.

Thank you, pscar13,
…this I think too. But the question is, why previous connections were interrupted and who do that ? iPFire not or ? We have find a trail to Windows-Firewall, but we are testing always.

Check the system log messages.
You can analyze traffic using the tcpdump add-on.
Or simply disable the option “Log dropped packets classified as INVALID by connection tracking”.

Thank you, pscar13,
… think, there is a misunderstanding or my question was not “good”…
We see in port protocol often DROP_CTINVALID on port 11000. The service listen on port 11000 breaks the connection after 15…120 minutes. This problem comes ~ 4 weeks ago… since 2 years no (bigger) problems with it. we search a strategy to find the “connection breaker”
The Windows Firewall is NOT the breaker. Last night there was no connection break …

What services are actually running on the Windows machines that are responsible for these heartbeats?

I’m also having trouble understanding the network setup. Why are the Windows clients sending heartbeats to clients outside your network every few minutes? Are those external clients also your own clients, just located somewhere on the Internet?

Could you please explain how these connections are supposed to work? I’m not quite understanding the topology or which side is acting as the client/server here.

Thank you for helping, and excuse me to steal your time,
yesterday we found the reason of CTINVALID:
The “boss” had created a virtual LAN on the same IP segment … 10.2.2.0/24 … and forgot it …
~20 days trouble for trying IP telephony …