PCTools firewall blocks Bitcomet listening

[jgf]

System is Vista Home 32, DSL through Siemens Speedstar. Bitcomet 1.17.12.28 works fine with Vista's default firewall. Installed PCTools firewall 6.0.0.88 and cannot get it to allow Bitcomet to listen. Message is "Blocked: 99.40.90.86".

Have scoured the forums here and at PCTools (little info there), also an evening on the net looking for info. Everything I find is either for older versions of the firewall and/or Bitcomet (menus and options are usually different enough to negate the relevance of the instructions) or too generic or too technical.

I've tweaked settings in PCTools firewall to no avail (obviously haven't found the correct one) and, right now, the only solution I have is, when I want to use Bitcomet, to shut down PCTools firewall and enable the default Vista firewall. Returned all PCTools settings to default, as far as I can tell Bitcomet has full access. Tried setting different ports, 49152-65534 range, in Bitcomet, to no avail.

[greywizard]

I'm writing from memory here since I don't use PC Tools firewall.

I have no idea what you did so far.

I've tweaked settings in PCTools firewall to no avail

And this doesn't help us very much. Maybe you could get on and write some specific steps you took.

Besides,

DSL through Siemens Speedstar

says nothing.

Are we supposed to guess the model of your device? Can't you flip it and read the exact model? And you meant SpeedStream didn't you?

As far as I remember you should put your firewall in Expert mode and then create an Advanced rule which allows inbound TCP or UDP on the port number you use for BitComet, under the applications tab.

You also should check and make sure that IP outbound connections are allowed for BitComet on any port.

[jgf]

Sorry, modem is Speedstream 4100 (ascertained by crawling on my back under and around the Christmas tree, fishing the modem from the morass of wiring behind my desk with a backscratcher, and holding a flashlight in my mouth while trying to read the label from arm's length); as everything else was functional through it I didn't think it was the problem (perhaps that's what I get for thinking).

PCTools firewall was highly recommended from several sources, so I tried it. As I could find no decent documentation for it, I am fumbling in the dark (I don't consider "you need to open a port" as very informative when you're completely unfamiliar with the software). Bitcomet was shown as having full outbound access and "trusted" inbound. I tried creating exceptions using the 99.40.90.86 number ...didn't work. I tried establishing a WAN connection in Vista (when Bitcomet was working with the default firewall, that was listed with the green light) ...didn't work. Tried changing port designations in Bitcomet and in the firewall. Basically poked around in all the PCTools firewall windows and menus looking for something that might be relevant, comparing settings with the default firewall and with Bitcomet. Finally returned all settings to default (there's still need for an old fashioned pen and paper).

But - I got it working! While nosing around in all the data here I read of the emule plugin, it sounded like something useful so d/l'd and installed it. Ran the port test, which failed; but the comments on that page after the test failed, coupled with some information gleaned from their FAQs, pointed me in the right direction (though there was a lot of backtracking and retesting til I deciphered this arcane legerdemain). Back in PCTools firewall, in the applications list select emule, click the small arrow to the left, when the selection expands, click "advanced settings" then select the advanced rules tab, click the green plus sign; select direction > outbound, type of connection > tcp, ignore the other options and click finish; click the green arrow again, direction > inbound, type of connection > tcp, finish. Did the emule test again and it worked immediately. Repeated the procedure with Bitcomet selected in the applications window. Don't know if this was pertinent, but also unchecked the Upnp mapping option in Bitcomet options (an emule FAQ implied it was only necessary when using a router).

So, things seem to be functioning properly now. If there's anyone else out there as ignorant as I, perhaps this will help them.

[kluelos]

I do think you made that a lot harder than it had to be, mostly because you seem to have started without a clear idea of your objective.

One thing that you do need to change or do, is to add another inbound rule for UDP, or change your current rule to "both" or "all", depending on how that firewall expresses it.

You should not be messing with IP addresses at all on a software firewall for P2P. The only address you're concerned with, on the one hand, is yours. On the other hand you're allowing all addresses.

What you want is to have one single port -- which is the BitComet listen port that you chose -- which allows incoming traffic FROM everybody, all IP addresses, in both TCP and UDP protocols. Some firewalls, possibly including PC tools, want to tell you that this traffic is "for" some application. It's not the firewall's business to route traffic, that's your winsock's job. The firewall just needs to let it in, period. If it's just got to be set "for" something, then set it for BitComet, but in fact, winsock will take it and route it no matter what the firewall says about things.

The windows built-in firewall is perfectly fine and all that most people need. Unless you have an overwhelmingly good reason, I'd just go with that.

[greywizard]

I'm glad you've figured it out. I'll just make some observations related to what you said above.

One of the reasons that I've asked you about the model of your device was this: your modem is also a NAT-capable router device, therefore I guess you're on a local network (LAN). That's unless your modem is in bridge mode.

You can check that by typing ipconfig at the command prompt; if you get an IP like 192.168.x.x or 10.x.x.x or 172.16.x.x-172.31.x.x then it means you're on a LAN). Therefore, you should set your network type (in your firewall as Home).

Bitcomet was shown as having full outbound access and "trusted" inbound.

"Trusted", in your firewall means: only the list of trusted IPs. By default PC Tools adds to that list only the local IPs (such as the DNS and gateway IPs of the router, loopback address etc). Therefore you won't get access "outside" of your local network. That's why you couldn't get an open port with that setting. In order to access the Internet and be able to receive connections you need to "Allow" all IPs, as you found out by yourself.

As kluelos already told your both BitComet and its eMule plugin need both TCP and UDP in order to perform all of their functions. That's why you should modify your already made rules for both this applications to allow outbound connections for both these protocols on any port and allow inbound connections for both these protocols on the listening ports of BitComet and eMule.

If I remember correct, on the Advanced page of your firewall that option is under "Type of connection" next to a radio button called "TCP or UDP". That's what you should select. That way you modify and transform each of the two rules in a rule allowing both protocols at the same time.

As for UPnP, it should be disabled if you have manually forwarded your ports. Since you say it's working, that means they are forwarded already or that your router is in bridge mode (in which case my advice to set your detected network as Home changes to Public).

Yes, indeed, PC Tools is listed as the second-best after my all time favorite Comodo, on the matousec list of tested firewalls. And hats off to them for still keeping it free.

But as most software firewalls it's a bit complex, since it needs to allow an advanced user too, to be able to configure it in detail, according to his/her needs.

The documentation seems a bit spartan for most firewalls because they assume that you have some basic networking knowledge before you start using and configuring one. They don't give a crash course on networking but at best, they explain you how to perform different tasks. But you're supposed to know which one configuration task you want to perform.

[jgf]

Thanks for the advice. Obviously I am totally ignorant of networking; have been cursing computers for over thirty years (I remember TTY terminals and cradle modems), but never had to deal with this end of things. Over the past few days I've read extensively on the topic, which has served primarily to further confuse me.

Per your suggestion, in the PCTools firewall I just changed one setting in the advanced rules from 'tcp' to 'tcp or udp', and now two more options appeared: "set as local proxy" and "allow only Trusted IP List", with the latter checked. In the past month, since getting a DSL connection, I've frequently been confronted with an option to set something as a proxy; again, I've read up on this, only to have no concept of when or if I should use such an option (when in doubt I usually leave default settings). From your messages, I should also uncheck "allow only trusted...".

To further display my ignorance, I have no idea what "forward your ports" means (even though I've apparently done it) nor what "bridge mode" is. I didn't even know I had a router! much less a "NAT compatible" one. I thought it was just a plain modem, it has one ethernet connector and one phone connector (and a PS connector, of course). According to CP>Network Connections, I'm on a public LAN (it also shows a disconnected Broadband through a "WAN miniport"). Typing ipconfig at the prompt (administrator) gets me "...is not recognized as an internal or external command..."; however, network connections details does show a 192.168.xx number.

I had "a clear idea of <my> objective" - to get bitcomet, and now emule, working efficiently behind the new firewall without compromising system security and without affecting my 'normal' internet access - I just had/have little idea how to accomplish that objective.

Will tweak the firewall settings again and see how it works ...and may darken your digital doorstep again if further confusion ensues.

[kluelos]

The speedstream modems often cause that confusion. Often.

They are not sold to the public. They are sold to major telecomms, almost always with custom firmware. They are indeed routers, but they are almost always used as simple modems. For your purposes, and most of the time, you should treat the thing as if it were just a modem. Since the firmware is custom for the telco, most any manual you might find that isn't from the telco for that product, will be useless or misleading or both.

--------------------------------

Most SOHO routers contain a firewall in their firmware. You can disable this firewall, leaving the network address translation functions intact. This is "bridge" mode, where traffic flows between networks without checks or hindrance. like crossing a bridge from one network to the other.

If you have a software firewall on your computer, you simply open a port and let the traffic in. So far, so good.

But if you have a router, just letting traffic in isn't enough: you have to get it to a computer. Just opening the port doesn't get the job done, the traffic has to GO somewhere. Traffic coming in on port X has to go to one of the addresses that are connected to the router, where the computer is that's expecting that traffic. That traffic has to be forwarded to the right IP address. That's why this situation is "port forwarding", not simply opening a port.

It is standard for pretty much everything to be compatible with various sorts of proxies, so also standard to ask if you are using one to make configuration easier. Most people are not, and those that are generally have a complicated network setup involving a business. If nobody's ever told you that you are behind a proxy, then you should assume you aren't.

"Trusted IP list" is basically what it says -- only allow these specific IP addresses, which I trust, to do this certain thing, and keep all of the other IP's, who are definitionally not trusted, from doing it. This situation will generally not apply to you: it's the internet, trust no one. Or rather, there probably isn't a group you do trust more than anyone else.

If you're still having difficulty with IPCONFIG, do this.

[jgf]

Interesting, and informative. Thanks. (And I'll be doing some more reading now.)

When I got my DSL account, ATT wanted to sell me a modem for $85, I figured online prices would be half that; but a friend gave me the Siemens and ATT tech help talked me through configuring it. My confusion over the router came from being told that if I wanted to connect all three of my computers to the internet I would need a router to connect them to the modem. (Or is that a different type of router? Obviously I can't plug two PCs into the modem, nor can I daisy chain them since each only has one ethernet socket.)

Have enabled 'tcp or udp' for both inbound and outbound traffic for Bitcomet and emule, and unchecked the 'trusted IP only' option. Also have 'UPnp' unchecked. Will see if performance improves now.

[greywizard]

You were told that you need a router, because your router doesn't have more than one Ethernet port as you said.

As kluelos told you, your device has from factory, the ability to function as a NAT router (to perform NAT), but it may have been preset by your ISP in bridge mode. Since we don't know which is the case, that's why I've asked you for the results of an ipconfig command. To determine if you get assigned a local or public IP.

If your modem can be put it router mode (i.e. your ISP hasn't uploaded on it a crippled/locked firmware which lets it run only as a modem) then you could put it in router mode (NAT enabled) and hook to its Ethernet port a simple switch which will allow all your computers to connect to Internet through this modem.

Or you could buy another SOHO NAT router and leave your modem in bridge mode. This way, if you buy a wireless router you can access the net from anywhere in your house without worrying about the wiring.

About UPnP, what I said was that you should disable it only if you have manually forwarded your ports or if your modem is in bridge mode (and then you don't have any use for UPnP). Otherwise you might get a yellow light in BitComet.

[kluelos]

Though as far as using the Speedstream as a router, AT&T really, really, really doesn't want you to do this, and if you thought you were getting nowhere with tech support BEFORE, ... You probably CAN do that, but you're fighting the current all the way, and nothing you want is upstream.

AT&T uses the routerlike aspects for some purposes of their own, mostly as a sort of a DSL demarc. YOU should buy your own router for several reasons, not least because you can get one that includes WiFi for the same price. This is handy to have: it's way easier than running cable all over the house if you want to add a computer; you can take your laptop out on the veranda while sipping sweet tea in the cool of the evening, or whatever you do in your part of the world; if a friend comes to call and brings their laptop or iPad or whatever, they can connect to your network.

Routers like this can be had quite cheaply -- about US$20 street sale price, and this is one area where you do not appear to get what you pay for. The more expensive ones and the brand names, don't work any better or last longer than the no-name or off-brand cheapies. buy the one Fry's has on sale.

[jgf]

The info on the router was received, from the local shop which maintains our office network, before I'd even acquired the modem (I'm sure they wanted to sell me both).

Ran ipconfig, its data matches what I get from network manager>details. Curiously (to me) these numbers have changed since I made changes to the firewall settings yesterday; previously they began with 192.xxx, now they begin with 69.xxx (will post full numbers if it is safe to do so).

Also, on the bitcomet options>connections>port mapping, should 'enable NAT/firewall configuration in ICS/ICF (XP/Vista only)' be checked? (it was by default, so I haven't changed it)

Am getting no yellow lights in bitcomet now, so assume basic configuration is correct.

[kluelos]

If your IP is in the 192.168.xxx.xxx block, this indicates that you are on a private LAN, behind a router. All of the addresses in that block are reserved for private networks, and aren't valid out on the internet. The block at 10.xxx.xxx.xxx is also reserved, and likewise means a private lan + router. There are a couple of others.

Your 68.xxx.xxx.xxx address indicates that you are leasing the address directly from your ISP, and that you don't have a router in between. That also means you don't have an external firewall to forward a port through. You have gotten out from behind the router, and it's now behaving as it should. Now if you want to bring in a router yourself, that would change again -- but this time under your control.

BitComet will use ICF to automatically configure the Windows built-in firewall for you. That's goodness, since it will also automatically close your listen port when BC isn't active, and open the port when it's needed. This only works on the Windows built-in firewall, and not on any others.

[jgf]

...

BitComet will use ICF to automatically configure the Windows built-in firewall for you. That's goodness, since it will also automatically close your listen port when BC isn't active, and open the port when it's needed. This only works on the Windows built-in firewall, and not on any others.

So I should uncheck this option if using the PCTools firewall? Which means the listen port remains open? Does this matter? (I've had an ongoing problem with having to restart windows after using bitcomet or I can't access the net.)

[greywizard]

If you use PC Tool you should uncheck it and disable the Windows firewall altogether.

[kluelos]

The port does remain open. Whether that matters depends on whether you have BC running all the time (I do), and how paranoid you are (which doesn't mean they aren't after you.) If you have followed universal advice to choose a port in the 51K-65K range, having it open won't cause a problem.

[greywizard]

Actually, I don't know about the PC Tools firewall but my Comodo firewall is smarter than what you describe kluelos. Whenever I close BitComet it will start rejecting all incoming traffic on BitComet's listening port, as you can see in the screenshot below.

So, I guess it's safe to say, it closes the port after BitComet's exit.

[jgf]

Well, we (you) seem to have gotten Bitcomet and PCTools firewall cooperating on my system; but one problem remains. After shutting down Bitcomet I have no internet access (Firefox gives me "cannot find server..." for any address I try); restarting Vista is the only cure I've found. Windows diagnostics says I have "limited connectivity"; running repair gets me either "no problems found" or "...reset the adapter...", doing the latter usually gets me a "successful" message ...but I still can't connect.

[greywizard]

This is an entirely different, new issue.

But first, from your post I can't clearly deduct if you've performed some little more extensive tests.

For instance, have you tried accessing the Internet with another browser (IE, Opera etc.) when Firefox fails to connect? This way you would have determined if the issue is related to Firefox or if it resides somewhere else.

Furthermore, are there any other Internet programs working after you exit BitComet (messenger, Skype, you name it)?

Can you ping a public website or IP (such as google.com, your ISP's server or whatever)?

What kind of IP does your computer have at that particular moment?

It would help if you checked your IP while running BiComet and after exiting (when your net connection no longer works).

You get the idea? You have to work by elimination.

There is no quick answer in networking. Yes, sometimes the answer may be obvious but most of the times you have to test in order to pinpoint the problem's source.

And that, if you're lucky. :D

Second, if this issue appears only after exiting BitComet the first things to check would be:

What's the state (enabled/disabled) of the 3 options under the Port Mapping section of the Options-->Connection page of BitComet?

In case you have disabled the Windows firewall (as you should) make sure that all 3 are disabled, since you don't need them.

[kluelos]

This is Comodo getting in where it has no business, trying (as I've remarked before) to route traffic. Most firewalls don't do this, and IMHO should not. This effect is benign, if sorta pointless, so no harm, no foul.

[jgf]

I don't use messenger or any other such service (if I'm not actively online I don't want anything consuming resources that could be better used elsewhere). I shut down Bitcomet, open Firefox and it won't even load my homepage ("cannot connect to server..."), won't load hotmail ("cannot connect to server..."). Close Firefox, go to CP>network>diagnose and get the "limited connectivity" message. Run repair, try all options. At one point I'm told that windows tried to ping microsoft.com and got no response.

"the 3 options under the Port Mapping section of the Options-->Connection page of BitComet" All unchecked (after being educated by info in this thread)

Will note the IPs next time this happens, which will be tomorrow morning as I usually let bitcomet run all night.

[greywizard]

Oh, c'mon kluelos you're being discriminating now. B)

Why should a hardware firewall, residing on a router, be entitled to close the ports when no application is any longer using them (by means of UPnP, I mean) and a humble software firewall should be denied that privilege?

Of course, I'm not going to get into that argument about which filtering system is better (port based, application based, etc.) but I'm just stating the facts. If it can do it, I'm glad about it. Otherwise, should I be a paranoid security freak, I'd have to close the port manually, after each use of the client.

[kluelos]

It's mostly the way it goes about it. I understand that it's good to keep the interface consistent (though IMO they've failed miserably at that elsewhere), but it implies that Comodo can route traffic that the winsock is going to route where it d*** well pleases, no matter what Comodo says about it.

[greywizard]

I've run today a little test, just to clear my mind on that. I've downloaded the binaries of the eMule client, set its listening ports on the same number which my BitComet uses (which was closed of course) and started a few downloads.

What I've discovered is that unless you specifically allow traffic to come on that port, towards this specific application, all incoming connections are blocked (irrespective of the fact that there is a rule in the firewall which allows traffic on the same port for BitComet - which was not running at the time).

I understand what you say about Comodo trying to "route" traffic at transport layer. But I rather tend to think that the actual routing is still done by Winsock.

What I believe Comodo's driver does, is interposing itself between Winsock and the rest of the system, intercepting the connections which were already routed and verifying them against its list of allowed applications and ports. When they don't match, it simply blocks the connection.

Or maybe it stands even before Winsock and it intercepts and verifies the connections, I don't know. The point is, that I don't think it actually "does" the routing job or that it even tries, but rather it prevents the routing from being done if the connection doesn't comply with its list of parameters for allowed rules.

Therefore, traffic is filtered also on an application level, which is good.

Because, otherwise, just opening a port in the firewall (for any application which feels like registering in Winsock for it first) would be a pretty big security hole.

My guess is that even Windows firewall does that at present time.

Or else what would be the point of using application names in that list? It could just simply use port numbers.

However, I don't feel like testing that too. :D