Inbound Policy Violations for something specificly allowed?

Help for v2
#1

I have a network rule (number 4) to allow UDP/TCP in on port 30724, because that is the port I have skype run on.

However, I am getting messages in the log about Inbound Policy Violations, UDP incoming, network rule 10 (thus AFTER the rule 4 that explicitly allows them).

The message is medium priority, and doesn’t say that it is blocked, but since rule 10 is the final block&log rule, I assume this is messing with skype’s ability to receive incoming communications.

Any idea why this might be happening?

#2

If you are only allowing traffic in on port 30724 then anything else trying to use any other port that you haven’t allowed will be blocked. If you think this traffic is safe then you need to add those ports to the inbound rule you created. I am not familiar with the setup of Skype so don’t just allow this traffic before being sure it is connected with the operation of Skype and it is safe. Maybe someone else that has used Skype can inform you better on what the requirements are as far as inbound rules that Skype needs to operate.

jasper

#3

I don’t understand, i have port 30724, network rule 4, allowing udp/tcp in from any/any/any. And you think i have to somehow add other ports tot hat rule, to allow incoming udp port 30724?

I am now totally confused.

rule 4: allow tcp/udp in, any, any, when source port is any and dest port is 30724
rule 10: block/log standard final rule

Log:

Date/Time :2007-09-15 19:42:59
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 66.7.116.91, Port = 30742)
Protocol: UDP Incoming
Source: 66.7.116.91:60115 
Destination: 192.168.0.100:30742 
Reason: Network Control Rule ID = 10

Date/Time :2007-09-15 19:42:54
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 66.7.116.91, Port = 30742)
Protocol: UDP Incoming
Source: 66.7.116.91:60115 
Destination: 192.168.0.100:30742 
Reason: Network Control Rule ID = 10

Date/Time :2007-09-15 19:12:49
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 69.242.23.38, Port = 30742)
Protocol: UDP Incoming
Source: 69.242.23.38:64056 
Destination: 192.168.0.100:30742 
Reason: Network Control Rule ID = 10

Date/Time :2007-09-15 19:12:44
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 69.242.23.38, Port = 30742)
Protocol: UDP Incoming
Source: 69.242.23.38:64056 
Destination: 192.168.0.100:30742 
Reason: Network Control Rule ID = 10

Date/Time :2007-09-15 18:42:58
Severity :Medium
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 216.115.114.164, Port = 30742)
Protocol: UDP Incoming
Source: 216.115.114.164:61124 
Destination: 192.168.0.100:30742 
Reason: Network Control Rule ID = 10

Why should I have to add additional ports just to allow those udp packets in? Why am I getting block&log alerts to something I am EXPLICITLY allowing?

#4

Sorry, I misread your post. For some reason I was thinking the traffic was trying to come in on other ports.

The rule you have should be ok.

When you made the rule have you rebooted to make sure the rules get refreshed?

Move the rule to the top of your list of rules to be sure it is above any block rules.

jasper

#5

The rule has been there through a few reboots, so it should have been ‘refreshed’.

But I ask again, why, if it is rule number 4, am I getting rule 10 block/log ‘Inbound Policy’ notifications? Its already close to the top of the list of rules (only a few others for other apps are above it). The network rules take prescendence, riight?

#6

Network rules have the final say on what gets out or not. If you have rule #4 allowing traffic on port 30724 then nothing on that port should be getting blocked by rule #10 below it.

The only reason I can think of is that the rule you wrote either has the source IP and destination IP backwards or the Source port and Destination port backwards and it does not meet the requirements so it gets bypassed and passed on to the BLOCK ALL IN rule.

Here is how the rule should be written.

[b]ALLOW-check the checkbox to log this rule
UDP
IN

Source IP: ANY
Destination IP: ANY
Source Port: ANY
Destination Port: 30724[/b]

Could you post a screenshot of your Network Monitor rules so we can have a look at them. Please change your actual ip address to protect the innocent.

thanks,

jasper

#7

I am pretty sure I’m defining them correctly. Here are ss’s (images available temporarily):

http://70.173.212.245:3131/networkrules.jpg

http://70.173.212.245:3131/monitorlog.jpg

[attachment deleted by admin]

#8

Try moving your Skype rule above rule #2 in the list and see if it works. If it starts working then you need to either delete rule #2 or move it down to just above rule #10.

What port(s) is rule #2 set up to block? If it is blocking all in then you don’t need rule #2 as rule #10 would cover you without compromising your security.

Generally your allow rules are above the block rules as the rules are checked from top to bottom.

jasper

#9

I have already tried that, no change. I’ve even temporarily moved 2 down past 10, so it never gets used anyway. Same results.

I use #2 because I have some very noisy netbios network users, I just want to stop seeing the logs of them blocked (by 10), so I made a non-log block rule specificly for them.

The placement of #2 shouldn’t matter, since it is so specific.

#10

If you read the monitor log, you will see it is being blocked at rule 10, not rule 2. My question is still the same, why is it being blocked and logged at rule 10, when it is being explicitly allowed for at rule 4? Should all rules following 4 not matter at all, if rule 4 matches the condition?

#11

By the way, I put #2 where it is, primarily because I can’t actually name each rule, so I use #2 as a ‘divider’ between my lan rules and my application-allow rules.

#12

The only thing I can suggest is to write your rules down and delete them all, except the BLOCK ALL IN rule, the ALLOW ALL OUT rule, and your Trusted Zone rules then put in the Skype rule at the top of the list and see if it works. If it does then start adding the other rules one at a time and see where it quits working again.

jasper

#13

I just installed version 2.4.18.184 on a fully patched Windows 2000 SP4 machine.

I am getting similar results. I set up a rule to allow TCP/UDP in from any to any where the destination port is 57566. When I enabled the network monitor rules, CFP blocked those incoming TCP and UDP connections with the default deny IP any/any rule.

My rule was number 0, the catch-all rule was number 7.

I deleted the first rule and added two more, one for UDP and one for TCP. The TCP rule works, the UDP rule does not. They are both defined the same way, allow any/any inbound where destination port is 57566. CFP allows the TCP but blocks the UDP.

I have tried deleting and re-adding the rules, rebooting, logging in as either admin or user, and the problem remains. CFP is just not executing the UDP rule.

I have a lot of experience with firewalls, and this looks like a bug to me. I tell it to allow inbound UDP from any to any on port 57566, and it fails to act on the rule, the packets fall through to the default, and it blocks it.

Is there a trick to getting CFP to read and execute UDP rules?

#14

I reconfigured my application to use separate numbers for the TCP and UDP ports, and it started working.

CFP seems to have trouble handling the case where you want to allow incoming traffic from any to any where the destination port is the same for a TCP and UDP socket.

On this machine, it would not pass the UDP traffic if there was a TCP rule covering the same port, and it would not pass either TCP or UDP in a combined rule.

It may be a problem specific to the OS.

#15

I can’t configure skype to accept incoming tcp and udp on separate ports, wish i could.

But I don’t think this is a bug of the OS (windows XP Pro, fully up to date), it seems to me a flaw in Comodo. It is specificly blocking something that is specificly allowed, and I don’t know why.

I appreciate jasper’s help, but he’s telling me to do weird things that would make Comodo useless to me for a firewall, unless all I wanted to do was use Skype and only skype, and not actually use it to block incoming network intrusions for other things.

I just want to know why my rule #4 is not being obeyed. Is there some weird condition that comodo gets into that is undocumented, where it temporarily ignores other rules except the last?

#16

Maybe one of the other MODs or a forum member have seen this problem and could add some input. I must admit that I haven’t seen or experienced this problem before.

verin:
The only way for me to find out what is wrong without seeing any rules is to have you take the rules down to the basics that I know will work, then get Skype working, and then putting back the rules one at a time until it breaks again to see what rule broke it or in your case the TCP and UDP breaking it. That is the only way I have to troubleshoot in the blind. The rules would be put back to your original configuration once we had the culprit that was causing the problem.

I was unaware, though, of this problem with UDP not firing on inbound rules when you use both TCP and UDP as other users have the same setups working with Skype. I have used uTorrent on the 2.4 version of the firewall without any problems but I always used only one protocol per rule and not both TCP and UDP. I also never use IN/OUT together in any rule, it is either IN or OUT but not both.

I would fill out a support ticket as I’m sure Comodo would like to see why these settings don’t work correctly. In the meantime you might try changing the TCP and UDP to only one protocol to see if that gets it working.

jasper

#17

okay I’ll strip it down for the night like you request.

and utorrent, btw, works just fine for me. its just port 30724 that is causing me issues. 59595 is utorrent.

#18

Thanks for sticking with me on this verin.

Put the Skype rule at the top of the list so you know for sure it is getting hit first and that nothing else is messing with it. Once you get it working then move it down below the 2 Trusted Zone rules to see if it still works. Then you can start adding the other rules back one at a time and then check Skype again to see that it is still working. I know troubleshooting sux when you want to get something working and you have already tried a million different things to get it working but starting with a known good setup is the only way to find the problem.

Thanks for your input Merkwurdigliebe. Now that I know what might be the problem I am going to test it myself with version 2.4 to see if I get the same results. I remember one user a while back had to change the Block All IN/OUT rule to IN only and things started working correctly. That was about 6 or 8 months ago and I have not seen that problem again since then. If I can recreate this then I will submit a support ticket.

jasper

#19

Okay, same result. I completely deleted all network, application rules, and re-established the bare minimum like you suggested, and put the 30724 rule at the top (rule 0). And I’m still getting blocks at the finally block and log rule (now 4).

Attached are the two relevant ss’s.

[attachment deleted by admin]

#20

What we have here is transliteration.
30724 is the port number you think Skype should use
30742 is the port number which rule 10 is blocking

Alan.B