Trying out Firewall - some issues

32 bit Windows XP, SP3.
Free Comodo Firewall & Defense+ installed (not the AV - using Avast 5).
Comodo version 4.1.150349.920

I’m on the lookout for a new firewall. I used to use Outpost but had BSOD problems
due to some weird interaction between Firefox and Outpost. Seeing the excellent results
at http://www.matousec.com/ I decided to give Comodo a try.

I’ve run across some deficiencies, either in my understanding or in the firewall itself.
Any comments confirming my observations or corrections to my understanding would be
greatly appreciated.

  1. On the Summary page, the ‘Traffic’ section does not keep real time track of
    the percentage of network usage by various applications. It is very slow
    to update, often misses applications altogether and disagrees with the stats
    displayed in ‘Active Connections’.

  2. Global rules don’t appear to work as expected. E.g. The documentation claims that
    every packet is scanned. For any inbound packets this means that matching global block
    rules should be applied first. Using the ping application I created an application
    rule that allowed outbound ICMP echo requests. With no global rules, the echo reply
    packets came back (I assumed the default would be deny). I then set up a global
    blocking rule for ICMP echo reply packets, but even this did not stop ping’s
    returning echo reply packets.

In fact rules blocking all inbound IP packets don’t have the expected effect.
With an inbound global rule that blocks any IP at any protocol on any addresses,
I can still ping and I can still browse using Firefox.

NB. Similar outbound global rules do work as expected.

Conclusion - either inbound global rules don’t work or (more likely) the firewall
is implementing state control to override the global rule for expected return
traffic. From the help documentation, I could not determine which of these is
actually the case. It would be nice to know exactly what the firewall is doing here.

  1. The terms ‘Source’ and ‘Destination’, as used for addresses and ports in rules,
    are confusing. For ‘Out’ rules, obviously Source is the local PC and Destination
    is the remote end. For ‘In’ rules I assume this is reversed. But what about
    ‘In/Out’ rules - Source can’t be both the local and remote ends at the same time?
    The documentation does not make it clear as to how to interpret this.

  2. The logging facilities are lacking. There are a couple of issues here …

    • Logging only applies to rules that explicitly request logging. I would have
      liked to have seen 3 global options here. 1 - log everything, 2 - log nothing,
      3 - log according to the rule settings. Only 2 and 3 seem to be supported.

      It is often very useful and informative to be able to see all the traffic
      going through the firewall - this helps in understanding the behavior of the
      firewall and the individual requirements of applications. Logging is not
      just for troubleshooting.

    • I couldn’t find any way of clearing the logs. It is often useful to ‘clear
      the decks’ before experimenting with applications, or firewall configurations.

You have the option to turn on Logging for every rule if you wish, but why?
Simply select the rule(s) and check the box to log them when fired.

And that’s my problem. You have to manage logging for each rule individually. It would be
convenient to have an optional global override to turn on logging for every connection
attempt - inbound and outbound (after all, there’s a global override to turn logging off).

As for why - well I guess I got used to this with Outpost and have found such verbose logging
to be very useful on occasions.

Add this to the wishlist.

Good observation and a known issue.

2) Global rules don't appear to work as expected. E.g. The documentation claims that *every* packet is scanned. For any inbound packets this means that matching global block rules should be applied first. Using the ping application I created an application rule that allowed outbound ICMP echo requests. With *no* global rules, the echo reply packets came back (I assumed the default would be deny). I then set up a global blocking rule for ICMP echo reply packets, but even this did not stop ping's returning echo reply packets.

In fact rules blocking all inbound IP packets don’t have the expected effect.
With an inbound global rule that blocks any IP at any protocol on any addresses,
I can still ping and I can still browse using Firefox.

NB. Similar outbound global rules do work as expected.

Conclusion - either inbound global rules don’t work or (more likely) the firewall
is implementing state control to override the global rule for expected return
traffic. From the help documentation, I could not determine which of these is
actually the case. It would be nice to know exactly what the firewall is doing here.

Please show screenshots of the above. The placement of the rules under Global Rules needs to be right and without seeing them I cannot tell what is going on.

3) The terms 'Source' and 'Destination', as used for addresses and ports in rules, are confusing. For 'Out' rules, obviously Source is the local PC and Destination is the remote end. For 'In' rules I assume this is reversed. But what about 'In/Out' rules - Source can't be both the local and remote ends at the same time? The documentation does not make it clear as to how to interpret this.
The Source/Destination tagging is indeed something to get used to. I prefer to make separate rules for incoming and outgoing traffic rather than using an IN/OUT rule. I guess making an IN/OUT rule only works in a very limited set of scenarios.
4) The logging facilities are lacking. There are a couple of issues here ...
  • Logging only applies to rules that explicitly request logging. I would have
    liked to have seen 3 global options here. 1 - log everything, 2 - log nothing,
    3 - log according to the rule settings. Only 2 and 3 seem to be supported.

    It is often very useful and informative to be able to see all the traffic
    going through the firewall - this helps in understanding the behavior of the
    firewall and the individual requirements of applications. Logging is not
    just for troubleshooting.

Simply edit every rule that is under Global Rules to be logged.

- I couldn't find any way of clearing the logs. It is often useful to 'clear the decks' before experimenting with applications, or firewall configurations.
Known issue.