1st post, 1st question

Hello everyone, and thanks Frederic for a great firewall.

I have tried so many different ones over the years and were happy with some, but not happy enough.
I have actually trialled LnS about 4 times over the past year when I first discovered it while I was trying to find a FW that was easy enough for me to use and wasn`t too annoying, so last night I took the plunge and bought LnS.
I am very happy with it and it is so light on system resources unlike some of the HUGE FWs you can get which do so many other things.
But I only wanted a Firewall, just a firewall ! LnS does exactly that.

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

So...my first question.

I am behind a router with basic fw capabilities.
Using LnS with standard ruleset, added the one rule to allow standard safe communication between router.

What I am seeing in the logs is quite unusual and I don`t understand it.

In my router I have forwarded one specific non-standard port to allow uTorrent to work. (49xxx) This has never been a problem in the past but since yesterday I have been seeing this port (and only this port) being probed by 2 specific addresses. (I have never noticed this happening before anyway)

This happens when I do NOT have uTorrent running, and a test at ShieldsUp shows the port to be stealthed.

So could someone help me and tell me that this is safe or not, and whether I should just ignore these alerts from the "Any Other Packet" rule ?

I am just about to read through the forum thoroughly and try to get uTorrent to work properly & safely, but I will probably be back asking for more help

Thankyou.

 

Hi Fad and welcome to Wilders!

Assuming you have forwarded that particular port and associated the rule created for Look'n'Stop with the application uTorrent, the port is only opened when you are using uTorrent.

I have the exactly the same situation you describe with Azureus, and when Azureus is not functioning I get the same type of logs you are referring to.

When your torrent client is active the port that is associated with it is opened, and the traffic goes through this port, according to the rule you defined in Look'n'Stop. But when you are not using uTorrent, and as this port opening is associated with the APPLICATION uTorrent, it is CLOSED when you are not using uTorrent. Hence these logs.

As far as I know, it is a normal situation that peers keep trying to connect to your machine on that same port, in particular when your IP is the same (I am assuming you have a dynamic IP), and for some time after closing uTorrent.

You do not have to worry about that kind of logs. I also get plenty of them.

Regards

Rui

 

Hi Rui....

this was actually happening before I had even set up any rules for uTorrent !

The router had already been set up to forward this port and it`s been the same way for the past 2 years or more, using the same port.

As I had not noticed any similar activity in the past while testing other firewalls etc, it made me think something was strange.

That`s what made me wonder if it might have been some kind of port scan attack....or something, I don`t know anything about this kind of thing really.

I have since made a rule for uTorrent and it appears to be working OK (will have to check if I`ve done it correctly though).

I have a static IP if that makes any difference, and this is how I have set up my uTorrent rule:

Direction: In & Out
Ethernet Type: All
Protocol: TCP (I do NOT use DHT)
Source: Ethernet Address: Equals My @
IP Address: Equals My @
TCP Port: Equals: 49212

Destination: All, All, All

Does that look as though it should be safe & correct ?

Thanks, so I don`t have to worry about those logs now.

 

Like Rui said, this is normal behavior of p2p'n. And you defintately safe, .. when there's no uTorrent running and the rule is deactivated and another lower block rule is seen blocking these BitTorrent packets.

My suggestion, if it's annoying the heck out of you by seeing these blocked packet loggings, create an duplicate uTorrent rule, one with no application set to it, and that is below the normal original uTorrent rule that is set to block without logging instead.


Regards,
Phant0m``

 

Thanks phant0m for the info & tip....

I`m not getting any logs coming through at the moment, which is a bit odd so I`ll wait and see what happens.

I will leave them all active for a while anyway until I get used to the program and know what`s going on "under the hood"

 

Hi Fad,

Thanks for your appreciation, and welcome on this forum

Frederic