Firewall rules based on hostnames don't work as expected

A. The bug/issue

  1. What you did:
    Added a firewall rule, allowing
    “ping.exe”, out any, source any to target, source port any, target port any
    “ping.exe”, out any, source any to target, source port any, target port any

  2. What actually happened or you actually saw:

  • The hostnames resolve to various IPs. resolves to in first place
  • In case of
    If resolved to and, ping will be allowed to contact any host in the network range -
  • In case of
    CIS asks me on every IP change if I would like to allow ping to contact the host after the IP has changed
  1. What you expected to happen or see:
    If the hostname resolves to a certain IP at the moment, the rule should allow ping to communicate exactly with this host - not with more or less!

  2. How you tried to fix it & what happened:

and no, adding 100s of IP adresses to replace the hostname is no workaround!

  1. If its a software compatibility problem have you tried the compatibility fixes (link in format)?:
  1. Details & exact version of any software (execpt CIS) involved (with download link unless malware):
    ping.exe 6.1.7600.16385, contained in Windows 7
    ping.exe 5.1.2600.5512, contained in Windows XP

  2. Whether you can make the problem happen again, and if so exact steps to make it happen:

  • Add a firewall rule, allowing
    “ping.exe”, out any, source any to target, source port any, target port any
    “ping.exe”, out any, source any to target, source port any, target port any
  • Ping and several times. Try pinging IPs inside the network range of to IPs, resolved to
  1. Any other information (eg your guess regarding the cause, with reasons):
    CIS isn’t able to handle hostnames that resolve to a different hostname in first place (otherwise, ping would probably behave as ping
    I have no idea, what causes CIS to behave as strange in the “ case”

B. Files appended. (Please zip unless screenshots).

  1. Screenshots of the Defense plus Active Processes List (Required for all issues):
    certainly not, but ok…

  2. Screenshots illustrating the bug:

  • Screenshot of rules for ping.exe and ping2.exe (a copy of ping.exe)
  • Screenshot command window, resolved to; trying ping -n 1 results in an alert
  • Screenshot command window, resolves to now (this host doesn’t reply to echo requests), can ping2 -n 1 now without alert!
  1. Screenshots of related CIS event logs:
  • There are no entries for ping2.exe; one for ping.exe corresponding to the alert from screenshot in 2
  1. A CIS config report or file.
  1. Crash or freeze dump file:
  1. Screenshot of More~About page. Can be used instead of typed product and AV database version.

C. Your set-up

  1. CIS version, AV database version & configuration used:
    CIS 5.9.221665.2197, 1 (AV is disabled), COMODO - Internet Security, but all firewall rules were removed, firewall is set to custom policy mode

  2. a) Have you updated (without uninstall) from from a previous version of CIS:
    b) if so, have you tried a clean reinstall (without losing settings - if not please do)?:

  1. a) Have you imported a config from a previous version of CIS:
    b) if so, have U tried a standard config (without losing settings - if not please do)?:
  1. Have you made any other major changes to the default config? (eg ticked ‘block all unknown requests’, other egs here.):
  • Removed the default rules of the firewall config
  1. Defense+, Sandbox, Firewall & AV security levels: D+= , Sandbox= , Firewall = , AV =
    D+=Clean PC Mode, Sandbox off, FW=Custom, AV=off

  2. OS version, service pack, number of bits, UAC setting, & account type:
    XP SP3 32bit; also tested on 7 SP1 32bit, UAC on, admin account in both cases

  3. Other security and utility software currently installed:

  1. Other security software previously installed at any time since Windows was last installed:
  1. Virtual machine used (Please do NOT use Virtual box):

[attachment deleted by admin]

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Actually this is a known issue, but this this the best report on it so I will forward to format verified, with many thanks.

Many thanks again

Previous non-format report:;msg556040#msg556040