This is just a simple debugging tip for Kerio Control admins. It takes advantage of Control's ability to do accounting on packets that match a specific rule and the perhaps not immediately obvious fact that a "useless" rule with accounting turned on isn't actually useless.

For example, let's say we have a machine that we suspect may be initiating Internet traffic. We don't know what kind of traffic that might be, but we'd like to quickly find out. We could set up a packet analyzer and capture everything that had that machine as its source, but that's a fair amount of effort. It also involves knowing a bit about tools like tcpdump or Wireshark. Why not use Kerio Control as our "packet sniffer"?

That's much easier. For example, here's a traffic rule that allows a specific IP address to do pretty much anything it likes. We call this rule "Peachtree" because it happens to be running that software, and we could locate it wherever we like in the rules as long as it is above Kerio's default "Local Traffic" rule. If we put it at the very top of the rules, no other rule can override it, or if we do have rules that generally block certain types of traffic, we could put it below those - it really depends on what we want to see.

This rule basically is useless if we have no other blocking in place because the default local traffic rule would allow these packets anyway.

So why bother? Because if we turn on accounting logging, we'll log only the packets we are interested in: the packets from that specific machine. If we were interested in particular ports instead, our rule might look like this:

Basically, we can capture whatever we want. As to the actual logging, we have three choices. We can log connections, and those will show in the Connections log:

We can also just "log packets". Packets will then show up in the Filter Log:

Finally, if we just want to know how much traffic this rule covers, we can click on "Internet Traffic Chart" and it will show up in Status->Traffic Charts:

Nor does the rule have to be useless. If, for example, we wanted to block a list of "bad guys", we could log or chart whenever that blocking happens.

Of course this sort of logging isn't sufficient for all network problems, but it is sometimes all that we need and it is very quick and simple to do.

I was reminded of this when I read Looking for evil in your firewall logs, which suggests a Perl script to scan logs for certain connections. As I'm sure you can see from this article, Kerio Control has better ways to do that!