WOL packet can't get through firewall [V6][M598]

[doveman]

A. THE BUG/ISSUE (Varies from issue to issue)
[ol]- Summary - Give a clear summary in the topic subject, NOT here.

• Can U reproduce the problem & if so how reliably?: Yes. Completely
• If U can, exact steps to reproduce. If not, exactly what U did & what happened: Enable Firewall
• If not obvious, what U expected to happen: WOL packet to be allowed through
• If a software compatibility problem have U tried the conflict FAQ?: N/A
• Any software except CIS/OS involved? If so - name, & exact version: N/A
• Any other information, eg your guess at the cause, how U tried to fix it etc: I Created a Global rule to allow traffic to port 7 and an Application rule to allow traffic to WOLSniffer.exe. I even tried setting the Global rule to allow TCP & UDP In to/from any port/address and then tried changing it to IP. With the Application rule I also tried on both Allow All TCP & UDP in and then tried on IP. I set both rules to log events but neither generate any events. The only log events the Global Rule catches are for ports 138 and 1900, which are unrelated to the WOL packet.

The WOL command is in this format:
wolcmd xx yy 255.255.255.255 8

where xx is the MAC address and yy is the Dynamic DNS name (xx.no-ip.org)[/ol]

wolcmd.exe and wolsniffer.exe attached in zip.

• Always attach - Diagnostics file, Watch Activity process list, dump if freeze/crash. (If complex - CIS logs & config, screenshots, video, zipped program - not m’ware)

B. YOUR SETUP (Likely the same for each issue, so you can copy forward)
[ol]- Exact CIS version & configuration: CIS 6.2.285401.2860, Firewall Security

• Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV: Only Firewall
• Have U made any other changes to the default config? (egs here.):
• Have U updated (without uninstall) from a CIS 5?: No
  [li]if so, have U tried a a clean reinstall - if not please do?: N/A
  [/li]- Have U imported a config from a previous version of CIS: No
  [li]if so, have U tried a standard config - if not please do: N/A
  [/li]- OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used: Win7 Ultimate x64, Admin account
• Other security/s’box software a) currently installed b) installed since OS: None[/ol]

[attachment deleted by admin]

[Chiron494]

Please also attach the CIS diagnostics report and the KillSwitch process list to your first post.

Thanks.

[doveman]

@Chiron post:2

Please also attach the CIS diagnostics report and the KillSwitch process list to your first post.

Thanks.

Sorry, I can’t see how to produce the CIS diagnostics report and the Killswitch seems to be a separate program I have to install, which I don’t really want to do. Isn’t there another way for me to produce a process list just using in-built Windows commands?

[Chiron494]

The diagnostic report can be created by opening up the main CIS GUI. Then click on the question mark in the upper-right corner, select Support, and then select Diagnostics.

KillSwitch can easily be downloaded by going to the Advanced Tasks and selecting “Watch Activity”. After installed this program will not use any resources unless manually started. However, if you do not wish to use that you can use any other program which shows all running processes, and take a screenshot of those processes.

Thanks.

[Citizen_K]

Can you specify the Global Rule you made for the WOL traffic in the following format:
Action:
Protocol:
Direction:

Source Address:
Destination Address:
Source Port:
Destination Port:

Did you try to use the Allowed Application policy for both the programs? Is in your Firewall Rules a rule present with the name “All Applications”? If so move the rule for the two programs to a place above the “All Applications” rule and try again.

[doveman]

@EricJH post:5

Can you specify the Global Rule you made for the WOL traffic in the following format:
Action:
Protocol:
Direction:

Source Address:
Destination Address:
Source Port:
Destination Port:

Did you try to use the Allowed Application policy for both the programs? Is in your Firewall Rules a rule present with the name “All Applications”? If so move the rule for the two programs to a place above the “All Applications” rule and try again.

For the Global rule I used:

Action: Allow
Protocol: TCP & UDP (also tried IP)
Direction: In

Source Address: Any
Destination Address: Any
Source Port: Any
Destination Port: Any (also tried 7)

I’ve set a port forward rule in my router to forward port 8 to port 7, which is obviously working as the packet gets through when the firewall is disabled. What seems strange is that the Global rule doesn’t log the WOL packet, so it’s almost like something before that stage is blocking it.

The Application rule was for wolsniffer.exe as wolcmd.exe runs on another PC. It was a custom rule I believe, set to Allow Incoming traffic (tried TCP & UDP and then IP), so I could try using an Allowed Application policy. I do have an “Allow All on LAN” rule for All Applications, so I’ll check if the rule for wolsniffer.exe was above that and try that if not, thanks.

[doveman]

@EricJH post:5

Did you try to use the Allowed Application policy for both the programs? Is in your Firewall Rules a rule present with the name “All Applications”? If so move the rule for the two programs to a place above the “All Applications” rule and try again.

OK, seems I was getting confused with the rules on my other PC. I don’t have any “All Applications” rule on this one but I made sure the wolsniffer.exe rule was at the top anyway. Tested again but the Global rule is still not logging anything.

Diagnostics attached. I’ll make the process list screenshot in a minute as I need to close Iron first because it creates a process per tab!

[attachment deleted by admin]

[Citizen_K]

Can you show a screenshot of your Global Rules? When you are using Stealth settings (with the Block All rule at the bottom) you will have to change the Block All rule to block and log to get CIS to log.

When you were using Stealth settings and changed the Block All rule to block and log could post a screenshot of the logs. Please use the Allowed Application policy for the two processes for testing.

[doveman]

@EricJH post:8

Can you show a screenshot of your Global Rules? When you are using Stealth settings (with the Block All rule at the bottom) you will have to change the Block All rule to block and log to get CIS to log.

When you were using Stealth settings and changed the Block All rule to block and log could post a screenshot of the logs. Please use the Allowed Application policy for the two processes for testing.

I don’t know what you mean by Stealth settings. There wasn’t any Block All rule in Global (I guess if there was then nothing would get through to the Application rules) but I added one temporarily with log enabled, first set to TCP & UDP and then set to IP and neither created any log events, so there’s nothing to show you there.

I’ve attached a screenshot of my Global Rules as requested.

[attachment deleted by admin]

[Citizen_K]

Thank you for the screenshot of the Global Rules. You were not using the mentioned stealth Global Rules but adding the block and log rule at the bottom did the trick for testing.

The WOL packages do not get logged as being blocked. Can you confirm that the problem persists when you use the Allowed Application policy for the two executables (with the rules at the top of the Application Rules)?

Please make sure there are no leftovers of security programs you had installed in the past. A possible left over can cause all sort of “strange effects”. Please run clean up tools for all security programs you had in the past. A list can be found here at the Eset website: ESET Knowledgebase .

Do you use utilities that interfere with networking (using a driver for networking)? Think Netlimiter, PC Cap (that comes with Wireshark f.e.) etc? Does temporarily uninstalling them make a difference?

[doveman]

Yes, I can confirm that the wolsniffer.exe rule was set to Allowed Application and was at the top of the list (as I said, the program that sends the packet, wolcmd.exe, runs on the other PC, so it makes no sense to make a rule for it on the one I’m trying to send the WOL packet to).

I’ve actually tried the other way round now, sending the packet from PC2 to PC1 and with a Global Allow In port 7 rule and a Application Allow In on port 7 rule for wolsniffer.exe, the packet does get through. However, both rules are set to log and neither does log anything.

In fact, the packet gets through to wolsniffer without the Global rule and just with the Application rule. Strangely though, then a log event appears saying that it Blocked it for application Windows Operating System, so it gets through to wolsniffer.exe but gets blocked to WOS, which I don’t understand.

I guess the router sends the packet repeatedly because wolsniffer logs it at a number of times (19:13:35, 19:14:12, 19:14:57, 19:15:33, 19:16:16, 19:16:48, 19:17:21, 19:17:57, 19:18:36, 19:19:09, 19:19:52, 19:20:34) but Comodo only shows one block event in the log at 19:13:32).

So the question is why does Comodo let the packet through on PC1 but not on PC2. I did have Avast installed until a week or two ago so I’ll try the cleanup for that. I also had NetworX http://www.softperfect.com/products/networx/ installed about 3-4 weeks ago which I think uses WinPCap to ignore local traffic but that’s been uninstalled along with NetworX.

As I’ve shown, the WOL packet isn’t being blocked by anything when Comodo is disabled though, only when I enable it does Comodo preventing it getting to wolsniffer.

[Citizen_K]

@doveman post:11

Yes, I can confirm that the wolsniffer.exe rule was set to Allowed Application and was at the top of the list (as I said, the program that sends the packet, wolcmd.exe, runs on the other PC, so it makes no sense to make a rule for it on the one I’m trying to send the WOL packet to).

I’ve actually tried the other way round now, sending the packet from PC2 to PC1 and with a Global Allow In port 7 rule and a Application Allow In on port 7 rule for wolsniffer.exe, the packet does get through. However, both rules are set to log and neither does log anything.

When traffic goes through, read it gets picked up by a listening application, it won’t be logged.

In fact, the packet gets through to wolsniffer without the Global rule and just with the Application rule. Strangely though, then a log event appears saying that it Blocked it for application Windows Operating System, so it gets through to wolsniffer.exe but gets blocked to WOS, which I don't understand.

I guess the router sends the packet repeatedly because wolsniffer logs it at a number of times (19:13:35, 19:14:12, 19:14:57, 19:15:33, 19:16:16, 19:16:48, 19:17:21, 19:17:57, 19:18:36, 19:19:09, 19:19:52, 19:20:34) but Comodo only shows one block event in the log at 19:13:32).

If it only logs one of multiple events then I can only assume wolsniffer was not listening at that one time or CIS had a hiccup. I can’t think of a strategy now to determine what’s going on…

So the question is why does Comodo let the packet through on PC1 but not on PC2. I did have Avast installed until a week or two ago so I'll try the cleanup for that. I also had NetworX http://www.softperfect.com/products/networx/ installed about 3-4 weeks ago which I think uses WinPCap to ignore local traffic but that's been uninstalled along with NetworX.

As I’ve shown, the WOL packet isn’t being blocked by anything when Comodo is disabled though, only when I enable it does Comodo preventing it getting to wolsniffer.

Is the installation of PC2 a clean or un upgrade installation? In case of the latter are you willing to try a clean installation of CIS? When doing so make sure to save your current configuration to a folder that is not part of the CIS installation folder.

When testing the clean installed CIS start with a factory clean configuration either Internet Security or Proactive Security and see what happens. Later in the process you could try the old configuration.

When a clean installation is too much could you try the situation with an imported and activated factory clean configuration. The factory default configurations can be found in the CIS installation folder. When importing you will be asked to give the configuration a name. Give it an appropriate name that is different from your active configuration. F.e. CIS Proactive Security Clean.

[doveman]

@EricJH post:12

When traffic goes through, read it gets picked up by a listening application, it won’t be logged.
If it only logs one of multiple events then I can only assume wolsniffer was not listening at that one time or CIS had a hiccup. I can’t think of a strategy now to determine what’s going on…

Hmm, don’t you think it’s pretty bad that it ignores the log flag if the traffic goes through? Some rules it’s useful to log regardless of whether the traffic passes or is blocked, to help catch probing/hacking attempts or even just to see how often they’re being used legitimately.

Is the installation of PC2 a clean or un upgrade installation? In case of the latter are you willing to try a clean installation of CIS? When doing so make sure to save your current configuration to a folder that is not part of the CIS installation folder.

When testing the clean installed CIS start with a factory clean configuration either Internet Security or Proactive Security and see what happens. Later in the process you could try the old configuration.

When a clean installation is too much could you try the situation with an imported and activated factory clean configuration. The factory default configurations can be found in the CIS installation folder. When importing you will be asked to give the configuration a name. Give it an appropriate name that is different from your active configuration. F.e. CIS Proactive Security Clean.

On both PCs I’ve only recently installed Comodo clean. I’ll try the factory default config on PC2 though.

[doveman]

OK, after importing the default config on PC2 and creating a Global rule to Block port 7, it logs it as blocked under Application “Windows Operating System”.

If I change the rule to Allow though, it doesn’t log anything so the “Log as firewall event if this rule is fired” setting clearly isn’t observed.

I don’t have any Application rules for “Windows Operating System” or anything else that would accept incoming traffic on port 7, so when you say “When traffic goes through, read it gets picked up by a listening application, it won’t be logged” that doesn’t appear to be what’s happening here, unless there’s some hidden rule that accept any traffic to Windows Operating System.

If I then add an “Allowed Application” rule for wolsniffer.exe at the top of the list, it still doesn’t get through to it. If I change this rule to Block and Log IP, it doesn’t log anything.

[Citizen_K]

@doveman post:14

OK, after importing the default config on PC2 and creating a Global rule to Block port 7, it logs it as blocked under Application “Windows Operating System”.

If I change the rule to Allow though, it doesn’t log anything so the “Log as firewall event if this rule is fired” setting clearly isn’t observed.

I don’t have any Application rules for “Windows Operating System” or anything else that would accept incoming traffic on port 7, so when you say “When traffic goes through, read it gets picked up by a listening application, it won’t be logged” that doesn’t appear to be what’s happening here, unless there’s some hidden rule that accept any traffic to Windows Operating System.

When something gets blocked it will be logged as blocked by Windows Operating System (WOS is a pseudo process comparable to System Idle Process in Windows Task Manager). This will happen both when a block rule is at work or when no process is listening to incoming traffic.

If I then add an "Allowed Application" rule for wolsniffer.exe at the top of the list, it still doesn't get through to it. If I change this rule to Block and Log IP, it doesn't log anything.

Thank you very much for testing. I jumped in to try to get to the bottom to see if there is nothing we were overlooking to call it a bug.

Chiron, for as far as I can tell this is a bug.

[Chiron494]

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Many thanks again.

[doveman]

@EricJH post:15

When something gets blocked it will be logged as blocked by Windows Operating System (WOS is a pseudo process comparable to System Idle Process in Windows Task Manager). This will happen both when a block rule is at work or when no process is listening to incoming traffic.

Thank you very much for testing. I jumped in to try to get to the bottom to see if there is nothing we were overlooking to call it a bug.

Thanks for the explanation about WOS, I was rather confused by that. Thanks also for your assistance with testing.

I should probably file a separate report regarding the “Log as firewall event if this rule is fired” not actually doing what it says and only working if it’s a Block rule.

[doveman]

@Chiron post:16

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Many thanks again.

Thanks Chiron.

[Chiron494]

Can you please check and see if this is fixed with the newest version (6.3.294583.2937)? Please let us know whether it is fixed or you are still experiencing the problem.

Thank you.

PM sent.

[Chiron494]

I got the following information from a PM from doveman:

With the Firewall disabled and sending the WOL packet from my phone to port 8, which my router forwards to port 7 on the PC gives the following in WOLSniffer:

---------------------------Wake-On-LAN Magic Packet---------------------------

Time received:
09/30/13 20:52:58
UDP Header:
|-Source IP : My WAN IP
|-Destination IP : 192.168.1.64
|-Source Port : 1029
|-Destination Port : 7
|-UDP Length : 110
|-UDP Checksum : 36834
MAC Address:
My MAC
Raw Data (102 bytes):
Redacted

Time received:
09/30/13 19:36:40
UDP Header:
|-Source IP : 157.56.106.184
|-Destination IP : 192.168.1.64
|-Source Port : 3544
|-Destination Port : 52547
|-UDP Length : 117
|-UDP Checksum : 23982
MAC Address:
FF FF 00 00 00 00
Raw Data (109 bytes):
00 01 00 00 FF 7E F0 7A D3 AE 6F 76 00 00 00 32
BC AE 60 C4 E6 60 00 00 00 00 30 3A FF FE 80 00
00 00 00 00 00 80 00 F2 27 62 C7 95 47 FE 80 00
00 00 00 00 00 00 00 FF FF FF FF FF FE 86 00 64
9D 00 00 00 00 00 00 3A 98 00 00 07 D0 03 04 40
40 FF FF FF FF FF FF FF FF 00 00 00 00 20 01 00
00 9D 38 6A B8 FF 00 00 00 00 20 01 00

This last incoming packet appears to be coming from a Microsoft IP http://whois.net/ip-address-lookup/157.56.106.184 and repeats every 35-40s. I have no idea why MS are sending WOL packets to my PC but as they’re not on Port 7 I guess they won’t cause my PC to wake up! I could of course block this address in the Global Rules but the packet may also come from other addresses they own. I can’t allow the WOL packet only from certain IPs either, as I won’t know the IP of the machine I might need to send it from in advance.

Anyway, with the firewall enabled, the MS packets still get through but not my ones. I’ve got a Global Rule set to Allow Incoming traffic to port 7 and an Application rule at the top of the list for WOLSniffer set to Allowed Application.