Baffled by these results!

Comodo Internet Security - CIS Firewall Help - CIS
#1

Hi guys/gals

I am having trouble interpreting some inbound TCP/UDP test results that I performed tonight via Vuze and eMule. I used to have no issues opening and forwarding ports and used to be able to pass all tests. I made some changes to my config that centred around Loopback and DNS IIRC. I am not certain, but it seems my issues may have start around then. [circa two weeks ago]

I am on a fixed wireless connection via a Draytek Vigor 2910VG cable router. I have the ports correctly setup on the router, verified using GRC Shields Up while Comodo was switched off.

I have static IP for all my machines behind the router and do not use DHCP or DNS services. OpenDNS is manually configured on all machines and Google DNS is setup as a fallback.

I have attached some screenshots: my global rules [GR], recent firewall events focused on the time I tried to test my inbound connectivity using Vuze [CFE] & a ping/traceroute that caused the Vuze firewall events in Comodo [pingTR]

I have a self-taught knowledge of firewalls and networking and would consider myself at a reasonable level, but this just has me baffled. My connection sometimes just seems to hang, almost as if it is ‘waiting for something’ I will get a timeout and then I hit reload and the page comes up just fine.

One specific question I have is as regards DNS…at present I allow each machine’s static IP outbound to my DNS zone on port 53, is my global rule allowing inbound from the DNS zone to port 53 necessary? I have researched conflicting views on this.

If you look closely in the botom right of the ‘pingTR’ screenshot, you will see that my NAT is rated green, I have a green connection on the transfer windows and you can also see I am getting a reasonable speed and I am hovering around my user configured upload limit. This is despite the disastrous ping/traceroute log.

My hunch is that I have Comodo incorrectly configured on the ICMP protocol [I do not allow anything right now] and I think I may have it incorrectly setup on DNS and possibly Loopback also.

Sorry for going on, but I thought I would be helpful by giving as much info as possible. If there is anything more you need do not hesitate to ask.

Really hoping the sages here can help me!!

[attachment deleted by admin]

#2

The first image is a standard loopback request. You should have a rule for Vuze that allows:

Action - Allow
Protocol - UDP
Direction - OUT
Source Address - ANY
Destination Address - 127.0.0.1
Source Port - ANY
Destination Address - ANY

It’s likely you will need an identical rule for TCP. (Or combine them…)

In the second image inbound TCP/UDP packets are failing. This is either because you ports are incorrectly forwarded, or your firewall rules are incorrect. The third image only shows a Global rule IN54001. what’s the detail behind this? Also, what are your Application rules for Vuze?

With regard to needing an inbound rule DNS, the answer is no.The reason is that firewall uses Stateful Packet Inspection, which basically means information about a DNS request leaving your PC is stored in a database, when the inbound answer comes in the information is compared with the information stored and if it’s found to be part of an existing connection, it’s allowed, it it doesn’t it’s discarded.

The same is true for most out bound connection requests, it’s only when we need to support applications/services that require server status (HTTP/FTP/P2P etc.) that we need specific inbound rules.

#3

Time out and p2p programs? The first thing I think is what are your settings for maximum amount of simultaneous connections of the mentioned programs?

#4

Hi Radaghast and Eric, thank you for your input.

I have been very busy of late and since my issues are more a nuisance than no connection at all I have had to long finger figuring this thing out.

Radaghast, I will implement your suggestions this weekend and will come back to you with a definitive answer on my Vuze app rules, however, off the top of my head they are likely to be:

Allow TCP & UDP outbound from ‘machine IP’ > ‘Any IP’ from ‘any port’ > ‘any port’
Allow TCP and UDP inbound from ‘any IP’ > ‘machine IP’ from ‘any port’ > ‘port 54001’.
block IP in/out from ‘any’ to ‘any’ via any protocol

The global incoming rule is most likely identical to the second Vuze rule above.

Thanks for your clarification on whether DNS inbound was necessary.

Eric, thanks for your suggestion to check my Vuze ‘max allowed’ rules. I am confident this is not the issue as I am having other connectivity issues, however I will check this out over the weekend.

During the little time I have looked into this I have begun to wonder if my app rules for Comodo are causing me trouble.

As I stated in first post my network is NATd, so each machine has a static IP.

My typical app rules are to ‘Allow’ TCP/UDP outbound from ‘machine IP’ > ‘any IP’ from ‘any port’ > ‘any port’.

One thing I was considering doing this weekend is changing my default app rules to ‘Allow’ TCP/UDP outbound from ‘any IP’ > ‘any IP’ from ‘any port’ > ‘any port’.

Am I potentially causing trouble for myself by specifying the machine IP where necessary in each app & global rule?

I will be back on over the weekend with an update on how I am getting on… :slight_smile:

#5

I’ve never personally used the IP address of the ‘source’ PC when creating rules, as I fail to see the need. However, if you feel you need more precise definitions, you could try using the MAC address.

With regard to the rules for Vuze, you could take a look at this tutorial I did for someone. It’s for Utorrent but the basics are the same.