We are running Comdo v2 on a test Win 2000 machine the is used for H323 video conferencing,. I am having an issue where the firewall will not allow a call to be placed via the gatekeeper. A direct IP call can be placed with no issue, however. The weird thing is, is that if I set the security config to allow all, and then the call can be placed via the gatekeeper (as expected), however if I set up a rule to allow any IP traffic (not just TCP/UDP) from any address to and address, the call cannot be place. If I log this rule, nothing shows up. Nothing is obvious in the activity connections either.
To avoid these problems I use custom policy mode. Something may show up, which needs to be allowed, that you didn’t know of when you wrote the custom rule.
Sorry, I wasn’t clear. I want to use custom mode and so specify various rules. However, when in Custom mode I cannot connect a call via the gatekeeper - even if I specify a rule to allow ALL IP protocols (not just TCP/UDP) form ALL Source AND Destination IP’s.
Such a rule should (as far as I can tell) allow all traffic into and out of the machine and act in exactly the same fashion as setting the main security setting to Allow All mode. However, the call only gets through when the firewall is set to the Allow All mode.
So, it seems as though the firewall is blocking something in custom mode. However, I cannot detect what is being blocked. The standard last rule that should block all IP traffic (that has not been expressly allowed in previous rules) and log any events doesn’t show up anything unusual.
Ok, i’ve seen a similar occurence with another FW and stepping back was the only option in that case. The assumption was, that even allowing all IPs and protocols, the FW still blocked certain ports for safety reasons if allow all wasn’t on.
So what about trying the ports your app might use. Open these explicitly?
On its own, yes. So there must be another rule in the chain that the connection must follow, that’s blocking it. Look in the global rules placed above the “allow all” one (if any), AND in the app rules.
Something strange is going on here. It not that the packets are blocked (I think), it’s that the information in the call admission requests packet is different. With Comodo set to “Allow ALL”, the PC will send an H225 request to the gatekeeper. Some data within the packet is regarding the destination of the call and one item set is called “dialedDigits” with its payload being the number dialled, e.g. “111”. The gatekeeper then responds with a Accept admission and returns the ip address of the dialled number. A call can then be placed.
However, when Comodo set in custom mode, the request is still made but the this time the item set is “h323-ID” with the same payload, e.g. “111”. However, this time the gatekeeper doesn’t understand the request and rejects it. The calling PC then goes on to query DNS, that responds with some IP so a second request is made using the returned IP from DNS, which has no relevance to anything. The gatekeeper understands what an IP address is though and so says OK, and the call is then attempted to be set up with this random IP! Of course, it does not happen.
With me so far? I’m not sure if I am! I captured this information via sniffing the traffic both from the PC and the return using an inline tap. I will also run a Wireshark trace on the PC that has Comodo installed.
This is very repeatable, but I don’t know what or why it is happening.
Turned off “Monitor DNS Queries” in Advanced → Application Behaviour Analysis.
I’m guessing that the application uses some Windows service to resolve an address, but I don’t understand how this affect the data in the packet. I guess a knock on effect.