E
EMS12
I have a laptop running Windows 7 that is connected to two networks. One is a wireless network with no internet connection, the other is a wired connection to a domain network with internet.
Other devices on the wireless network connect to services running on the laptop, and it relays messages to the domain network for them. This was working fine until yesterday.
Now the laptop is refusing all incoming connections on the wireless network. I have firewall rules specifically allowing the things I want to come through (nginx as an application rule, port 1883 as an open port). I've also tried disabling the firewall altogether. Still blocks connections.
An example audit log (Event Id 5152):
The Windows Filtering Platform has blocked a packet.
Application Information:
Process ID: 3440
Application Name: \device\harddiskvolume1\users\eshanks\documents\nginx-1.12.1\nginx.exe
Network Information:
Direction: Inbound
Source Address: 192.168.1.104
Source Port: 35533
Destination Address: 192.168.1.10
Destination Port: 8080
Protocol: 6
Filter Information:
Filter Run-Time ID: 70415
Layer Name: Receive/Accept
Layer Run-Time ID: 44
In case it's somehow helpful, Filter ID 70415 looks like this:
<item>
<filterKey>{622c993a-2216-483a-9357-8ac5a60403f2}</filterKey>
<displayData>
<name>GUID_MFE_RECV_ACCEPT_CALLOUT_V4</name>
<description>GUID_MFE_RECV_ACCEPT_CALLOUT_V4</description>
</displayData>
<flags numItems="2">
<item>FWPM_FILTER_FLAG_PERSISTENT</item>
<item>FWPM_FILTER_FLAG_PERMIT_IF_CALLOUT_UNREGISTERED</item>
</flags>
<providerKey>{8dfb7ab4-65f2-4889-a54b-e4a929173158}</providerKey>
<providerData/>
<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
<subLayerKey>{436a4032-cb23-4d0e-879a-34807bf2b0f9}</subLayerKey>
<weight>
<type>FWP_EMPTY</type>
</weight>
<filterCondition/>
<action>
<type>FWP_ACTION_CALLOUT_TERMINATING</type>
<calloutKey>{9dc84421-38a7-4908-a24b-8d7b9e311b86}</calloutKey>
</action>
<rawContext>0</rawContext>
<reserved/>
<filterId>70415</filterId>
<effectiveWeight>
<type>FWP_UINT64</type>
<uint64>0</uint64>
</effectiveWeight>
</item>
I was pleased with myself for finding that, but I don't know what it means.
The only thing that's new at all is that I opened port 1883 yesterday, and started running a program that was relaying MQTT messages in addition to the stuff that had been going on with port 8080. But when I left work yesterday everything was working perfectly. About 4 hours later, all incoming traffic on the wireless network started to be blocked. I'd be willing to believe that I screwed something up, but what kind of firewall settings include a time-bomb clause?
Summary:
Has anyone got any idea what might be going on? Or maybe tips on how to track down where filter 70415 is coming from? Or any sort of advice at all, really?
Continue reading...
Other devices on the wireless network connect to services running on the laptop, and it relays messages to the domain network for them. This was working fine until yesterday.
Now the laptop is refusing all incoming connections on the wireless network. I have firewall rules specifically allowing the things I want to come through (nginx as an application rule, port 1883 as an open port). I've also tried disabling the firewall altogether. Still blocks connections.
An example audit log (Event Id 5152):
The Windows Filtering Platform has blocked a packet.
Application Information:
Process ID: 3440
Application Name: \device\harddiskvolume1\users\eshanks\documents\nginx-1.12.1\nginx.exe
Network Information:
Direction: Inbound
Source Address: 192.168.1.104
Source Port: 35533
Destination Address: 192.168.1.10
Destination Port: 8080
Protocol: 6
Filter Information:
Filter Run-Time ID: 70415
Layer Name: Receive/Accept
Layer Run-Time ID: 44
In case it's somehow helpful, Filter ID 70415 looks like this:
<item>
<filterKey>{622c993a-2216-483a-9357-8ac5a60403f2}</filterKey>
<displayData>
<name>GUID_MFE_RECV_ACCEPT_CALLOUT_V4</name>
<description>GUID_MFE_RECV_ACCEPT_CALLOUT_V4</description>
</displayData>
<flags numItems="2">
<item>FWPM_FILTER_FLAG_PERSISTENT</item>
<item>FWPM_FILTER_FLAG_PERMIT_IF_CALLOUT_UNREGISTERED</item>
</flags>
<providerKey>{8dfb7ab4-65f2-4889-a54b-e4a929173158}</providerKey>
<providerData/>
<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
<subLayerKey>{436a4032-cb23-4d0e-879a-34807bf2b0f9}</subLayerKey>
<weight>
<type>FWP_EMPTY</type>
</weight>
<filterCondition/>
<action>
<type>FWP_ACTION_CALLOUT_TERMINATING</type>
<calloutKey>{9dc84421-38a7-4908-a24b-8d7b9e311b86}</calloutKey>
</action>
<rawContext>0</rawContext>
<reserved/>
<filterId>70415</filterId>
<effectiveWeight>
<type>FWP_UINT64</type>
<uint64>0</uint64>
</effectiveWeight>
</item>
I was pleased with myself for finding that, but I don't know what it means.
The only thing that's new at all is that I opened port 1883 yesterday, and started running a program that was relaying MQTT messages in addition to the stuff that had been going on with port 8080. But when I left work yesterday everything was working perfectly. About 4 hours later, all incoming traffic on the wireless network started to be blocked. I'd be willing to believe that I screwed something up, but what kind of firewall settings include a time-bomb clause?
Summary:
- WFP is blocking all incoming traffic on one network interface (but not the other)
- Firewall enabled/disabled makes no difference
- Firewall rules explicitly allowing this traffic are being ignored
- Everything WAS working, and I don't know what changed
Has anyone got any idea what might be going on? Or maybe tips on how to track down where filter 70415 is coming from? Or any sort of advice at all, really?
Continue reading...