Question

Anyone else seeing a lot of DROP packets due to WRSA firewall on WIndows?

  • 20 November 2019
  • 0 replies
  • 98 views

Badge

I have begun to notice something disconcerting with the WRSA firewall. It has a tendency to drop what are perfectly valid outbound packets. If you are reading this and are game to spend a few minutes to see if you have the same problem, feel free to follow along

(But first a quick aside -  the WRSA firewall and the Windows Firewall are meant to be run together by design. If you for some reason turned off the Windows Firewall …. well, just don’t do that!)

Go to a administrative command prompt
Run "netsh wfp show filters"
Open resulting filters.xml file
Search for the 10 instances of <name>Webroot SecureAnywhere Filter</name>
You should find the items shown below. In each case, note the FilterID value a dozen or so lines below the layerKey value.

<layerKey>FWPM_LAYER_INBOUND_TRANSPORT_V4</layerKey>
<layerKey>FWPM_LAYER_INBOUND_TRANSPORT_V6</layerKey>
<layerKey>FWPM_LAYER_OUTBOUND_TRANSPORT_V4</layerKey>
<layerKey>FWPM_LAYER_OUTBOUND_TRANSPORT_V6</layerKey>
<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey> *
<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6</layerKey>
<layerKey>FWPM_LAYER_ALE_AUTH_CONNECT_V4</layerKey> *
<layerKey>FWPM_LAYER_ALE_AUTH_CONNECT_V6</layerKey> *
<layerKey>FWPM_LAYER_ALE_FLOW_ESTABLISHED_V4</layerKey>
<layerKey>FWPM_LAYER_ALE_FLOW_ESTABLISHED_V6</layerKey>

Of particular interest are the FilterID values for the 3 shown above with an asterisk.
Turn on logging of dropped packets in the Windows Defender Firewall by running the firewall UI (wf.msc).
Note the Active profile and go into properties. At the top of the screen pick your Profile (the one
defined as Active) and Customize the Logging value of "Log droopped packets" to yes.

Use your computer as you normally would for 30 minutes (check email, browse your favorite websites, etc).
Now go into the Event Viewer/Windows Logs. Right click the Security log and select Filter Current Log.
Overwrite <All Event IDs> with the value 5152. Now scroll through the events noting the "Filter Run-Time ID".
Note well: you are going to find MANY dropped inbound packets. This is normal and there is no easy way to
filter these out (unless you want a primer in writing Event Log custom filters but that is beyond the scope
of this rant.) If your system is like mine you will see quite a few dropped outbound packets caused
by WRSA filters. On my system, I had over 100 in a 30 minute session.

A second and more quick way to visually see all the dropped packets is to open an administrative command
prompt and
1) go to the c:\windows\system32\logfiles\firewall folder
2) Enter the following: type pfirewall.log |find "2019-11-19" |find "DROP" |find "SEND"
(obviously put in the appropriate date)

The results are easy to see. Note well that this listing MAY include non-WRSA DROPs if any such occurred.
(None did on my system but in fairness I caution that these may contain DROPs by the built in Windows
Firewall if you tripped a rule in it to block something by design.) Unfortunately this quick way is also
limited in not showing you the cause of the drop (it does not include the Filter ID that caused it to be
dropped).

I started looking at this a bit deeper and what I see as a pattern is that shortly after a DROP there
follows a successful connect to the system you are trying to get to. But why are they being
dropped in the first place is my question. The destinations are all valid addresses (email
server IPs, websites I am trying to browse to, onedrive sync, etc.) so why does WRSA think these should
be dropped?

Finally, selecting OFF in WRSA for the Firewall function has no apparent impact that I could discern.
As far as I can tell, the firewall is still fully functional and the filters it installed still DROP a
lot of outbound packets when it is OFF. What exactly does setting the Firewall to Off do? That remains
a mystery. But if I uninstall WRSA the problem goes away, no more DROPs. But I like my WRSA! I just wish
its firewall would behave.


0 replies

Be the first to reply!

Reply