Windows Firewall Control (WFC) by BiniSoft.org

Hi, ive just installed this program, and whilst it looks pretty good (uninstalled comodo on the strength of it) i cannot figure out why Thunderbird wont send/recieve emails. I've checked that it has created a rule in the rules panel for Thunderbird.exe, but still nothing. Can anyone help please?

 

Ok think i've solved it, looked at connections log, and apart from the 127.0.0.1 which as i recall is local loopback, there were 2 other connections, on port 80, and 443, which i've allowed directly, and now it seems to work.

 

Another question (sorry ) In Battlefield 1 my reported ping is 0, while it should be in the region of 20-30ms. Any ideas?

 

No, i spoke too soon, thunderbird still wouldnt connect (i had filter set to LOW when it was connecting ok, when i urned it back to medium, it stopped working). Found real problem though, i hadnt allowed avastsvc which presumably scans incoming mail. Sorted.

 

Please post a screenshot in English. In Connections Log, there are no more "Local" and "Remote", but "Source" and "Destination". Try to identify in Event Viewer the same blocked connection that you see in Connections Log. You will see that they are displayed correctly, like they appear in Event Viewer.

 

I have just tested the latest Thunderbird version on a Windows 10 machine and I had to create only one outbound rule to allow all connections for:

C:\program files (x86)\mozilla thunderbird\thunderbird.exe

I linked one Gmail account and I was able to send and receive emails. Only one rule was required.

1. The outbound rule that you have created for thunderbird.exe allows all connections of it or is it customized for specific ports, etc ?
2. To debug connectivity problems, when a software is being blocked, use the Connections Log to see the recently blocked connections and make an idea of which rule is still required. Do you see any other process that is being blocked in Connections Log while thunderbird.exe is blocked ?

In the future, please use the Edit functionality and update your original post instead of posting 4 times.

 

Ok, my apologies, i was distracted as i've also been working on a seperate problem (quicklaunch toolbar dissapearing after reboot) which has nothing to do with this i know

In response:-
1) Yes, i originally created a rule for thunderbird.exe but it wasnt working, becasue i had not realised at that time that it goes through avast mail scanner.
2) Yes, thats what i did, i used the log to see which connections where blocked, and allowed both the port 80 and port 443 connections, thinking that would solve the problem. obviously it didnt, which is why after a bit more research i realsied it must be avastsvc blocking it, which i've enabled, and now everything is fine.

I do however appreciate you taking the time to read my erratic posts!

 

@JimSlim

If you want to use a restricted Allow Rule with ports for Thunderbird program, you have to open other ports OUTGOING too (not just 80, 443 which are NOT for the email traffic (receive or send email from/to email server) itself - but can be used to load content of (html) emails via http(s), for other "Browser" functionality, for program update (checks), for AddOn/PlugIn installations/updates (probably) or something like that):

So - for EXAMPLE (can be different and it's related to email provider too):

POP3 (without SSL) = Port 110
POP3s (with SSL) = Port 995

IMAP (without SSL) = Port 143
IMAPs (with SSL) = Port 993

SMTP (without SSL) = Port 587
SMTPs (with SSL) = Port 465

Open only YOUR really needed ports, not all!

Greetings

Alpengreis
Maintainer of WFC DE-Translation file

 

No. Not correctly.

How I noticed it?

1. Found in the log entry about blocked connecting to the host using RDP.
2. Double click on the record.
3. Created an allow rule with the proposed parameters.
4. The rule is not working.
5. Saw that rule incorrectly substituted the local address and remote address. That is, on the contrary substituted.
6. Swap them with each other.
7. Began to work correctly.

My english bad.


In the log ports are specified correctly.
And addresses on the contrary.
That is, the port-address pairs are not correct in the case of local and remote. Or source and destination.




Creating rule





Added 23.03.2017 19:04(Msk): There's not exactly drawn that it is necessary to swap. Actual picture:

 

The source and destination addresses are not the wrong way around.

The problem appears to be, you are creating your RDP rule from the "inbound" log entry, when you should instead be creating it from the "outbound" log entry.

Below is a basic representation of the log entries you will see when making and receiving RDP connections:

RDP from Local PC to Remote Host (Log direction: Outbound)
source address (local ip); source port (any port) --> remote address (remote host ip); destination port (3389)

RDP from Remote Host to Local PC (Log direction: Inbound)
source address (remote host ip); source port (3389) --> remote address (local ip); destination port (any port)

You will notice that the source and destination addresses swap, depending on the direction of the log entry. This is why it appears to you that the addresses are the wrong way around.

Note: Only create a rule from the inbound connection if you want to allow the remote server to make an RDP connection to your PC.

Hope this helps.

 

askmark, please be careful

It is true in my case. Remote server to make an RDP connection to my PC!
And I create a rule to him to resolve.
We must understand that both my PC, one at home, one at work. The rule is set up to work to connect from home.


"RDP from Remote Host to Local PC (Log direction: Inbound)
source address (remote host ip); source port (3389) --> remote address (local ip); destination port (any port)"

This not correct.
Must be :
source address (remote host ip); source port (any port) --> remote address (local ip); destination port (3389)

remote host: ip 10.40.90.231 port 49497
local host (my ip and port, ) : ip 10.40.90.232 port 3389

Remote host connecting to my host.

Therefore, it is necessary to look in the log incoming connections. And create a rule for it.

Then in the log should be two pairs of address and port. One source, the other destination. That is 10.40.90.231:49497 and 10.40.90.232:3389

And correct the rule, then, is:





And when i create rules from the log creates incorrect rule. Because a pair of address and port are recorded in the fields log is incorrect.

It's just probably a mistake of the programmer, messed up fields in the log. Not exactly a fields, and the data that they recorded. Accidentally overlooked.

That is, correctly so.



In a previous post, I really drew on the screenshot in the log that you need to swap address, but we need ports.
But essentially it has not changed, the bug is still there.



"1. Found in the log entry about blocked connecting to the MY host using RDP."
Sorry, if a sentence in English drawn incorrectly.

 

@Hifexar

And what says the Windows Event Viewer (related Event Log), the ORIGINAL and NOT the log from WFC?

 

Don't know, not watching. I only describe the data to be displayed incorrectly. And then based on it created the wrong rule. I'd not noticed that something is wrong, if i did not create a rule. This I want to show the developer's WFC. WFC is a good program.

Log normal, just switched places some data in the fields.

You see?

 

@Hifexar

Then you should indeed watch this first. So, please check that original log and post the result here. THEN we would be sure that this is incorrect only in WFC log ...

because WFC takes that log from original Windows Event Log!

So, if I use my time to help you and you say: "not done" then this is your decision, but then I will not give further help or assistance for you ... sorry!

Alpengreis
Maintainer of WFC DE-Translation file

 

Apologies you are correct. I didn't realise you were creating an incoming RDP connection to your local machine.

There is a mistake but it's not with the WFC log. It's with the transposition of the source and destination ip addresses into the local and remote ip values in the rule builder. They are swapped around so the source ip is placed in the local ip field and the destination ip is placed in remote ip field. When in fact it should be the opposite way around.

 

Alpengreis, You have to use my time!!!
I don't need help, I reported the bug. This is a bug report!!
Because I like WFC. And I want WFC was better.

Take a look yourself. Make sure that what I'm saying is. Why do I have to do it for you? Due to the fact that you do not understand what I write?


Here is the original log:

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path


That is:
2017-03-24 00:38:19 DROP UDP 115.22.110.245 128.74.106.103 53075 1900 122 - - - - - - - RECEIVE

src-ip 115.22.110.245
dst-ip 128.74.106.103
src-port 53075 Correct
dst-port 1900 Correct



Now that log incoming connections WFC:



That is:
src-ip 115.22.110.245
src-port 1900 -> not correct Vise versa
dst-ip 128.74.106.103
dst-port 53075 -> not correct Vise versa

src-port and dst-port in WFC inbound log not correct. Vise versa!


Still have a stupid job?

 

Yes, in the rule builder local ip and remote ip Vise versa.

But in WFC inbound log ports Vise Versa too. Be careful.

See previous post for Alpengreis.

 

atunis5804, You yourself understand what you wrote ??

 

Another issue is the translation file for Russian WFC.

In wfcRU.lng incorrectly named fields in inbound log WFC.

The fact fields name - source address, source port, destination address, destination port

Translation fields name to russian - Локальный адрес, Локальный порт, Удаленный адрес, Удаленный порт.
This is not a correct translation.
Correct translation - Адрес источника, порт источника, адрес назначения, порт назначения.
But in Russian so don't speak.
Therefore, closer in meaning and more correctly sounds- Удаленный адрес, удаленный порт, локальный адрес, локальный порт.

That is, it would be good in Russian translation fields named:





For outbound connections is also an incorrect translation, but the meaning is the same as with the correct. Just a coincidence.

And even this problem is not entirely in translation. Looked inside the file with the translation, there is simply impossible to make everything was correct because of the architecture. The main thing is that to call on the Russian fields have different in the cases of incoming and outgoing connections. Or it is necessary to translate the field literally. Then in both cases can be called the same.


Fixed the translation file. So the most correct Russian.
In wfcRU.lng :
850 = Адрес источника
851 = Порт источника
852 = Адрес назначения
853 = Порт назначения

 

Sorry you are correct the source and destination ports in the inbound log are the wrong way around. Good spot.

 

Thanks for the info Alpengreis. So far whatever rules i created seem to be working, so i'll leave it for now, also solved my BF1 ping problem, was a windows service i'd blocked.

I've not messed with firewall rules for a long long time, since Kerio on WinXP

 

Request to the developer of the WFC.


It is possible to disable font smoothing in WFC?
Or at all. Or as an option.

 

@Hifexar

I had fully understand what you wrote. Nevertheless a such compare was - for ME - necessary!

I help here since YEARS! And I like WFC too and I reported already MANY bugs, wrote MANY feature requests/suggestions, buyed extra license just as support for that project, helped with other things, helped with some beta testing, make the german translation, try to make WFC better known on different platforms ...

See all the postings in this (and older) thread to find out, what I have done here already since YEARS ...

WFC is also through me the WFC of today and not ONLY through developer!

So I found your "not made" not really friendly, you know ...

However, I THOUGHT it would be good to make that check with original log first to HELP in that case! So, IF those values are already in the Original Log it's not a mistake from WFC, THAT was my point.

And then you say, I use YOUR time with STUPID thing .... this is ... well, I do say better nothing more ...

However, do NEVER speak with me in SUCH a style again!

 

1. Regarding the swapped values, indeed, for inbound connections, the ports should be reversed in the data grid. For outbound connections the logic is fine, but for inbound, only the IP addresses are set correctly, but the ports not. The next version of WFC will have this fixed. Below is an example with the fixed version of WFC. The previous implementation was incomplete because when I did the test with the PING command, the ports 0 and 8 are recorded differently on the source and the destination machine. Anyway, thank you for reporting this.



Another thing that I've seen here, is that when choosing to Customize and create while selecting an inbound connection, the local port and local IP should be swapped with the remote port and remote IP, since we want to create a working inbound rule. I will fix this too in the next WFC version.

2. Regarding the translation file, in the future please send me a private message since not all members are interested in translation files. Let's keep the topic only with important things. A few strings in a text file is not so important.

3. Regarding the font smoothing, I can disable the anti aliasing, but why ? Do you have rendering problems because of it, or it is just a matter of personal taste ? Nobody complained about this since 2010.