Network connectivity issues diagnosis step by step - Part II.

In the previous post, we discussed how to make sure if Windows Firewall really dropped incoming packets. If the machine is domain joined then group policies might not allow you to turn off firewall. In that case logging or creating inbound rules should be of help to determine the packet drop by WF. There is one other, some what less recommended, way to turn off firewall if policies don't allow to turn it off from Firewall management snapin and that is turning off the BFE service. Its BFE which creates and manages all the firewall filters and turning BFE off removes the firewall filter. Keep in mind that turning off BFE will stop a few other dependent services as well so when you are done with your experiments you should turn on the those dependent services also with BFE.

That's all for windows Firewall. If there are  third party firewalls on your system, they could also be the one causing packets drop. Each third party firewall has different configurations and troubleshooting, about which I can't comment much. However vista onwards most thirdparty firewall use BFE only, so you can see their filters and drop events in the BFE/WFP traces. Look out the command help of "netsh wfp capture" to learn about WFP tracing commands. These traces are  little  bit complex as they deal at filter level. Usually filter description gives some information about the filters source.This trace can be huge since it consists of all the communication esatblsihed with machine and all the filters present in the machine.

WFP auditing can also be used for WFP event log traces. You can enable WFP auditing using auditpol.exe. Below  commands can be used to turn on and off WFP auditing. And the logs can  be checked from Security Event logs.

auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable

auditpol /set /subcategory:"Filtering Platform Connection" /success: disable /failure: disable

So firewall is mostly the reason for packet drops. But in some cases it could be IPSec also. IPSec mostly comes into picture if your machine is domain joined and group policies have pushed IPSec policies on the machine. Needless to say IPSec policies can be there on non-domain joined machine also if the Admin has created them locally, but I haven't seen much such cases. Also if there are no IPSec Policies on the machine, then IPSec is not involved in the communication irrespective of the IPSec/IKE service status(running /stopped).  

Using Netmon you can check if any IKE packets are there in the capture between the two machine, if they are present then IPSes negotiation can be there between two machines and you should turn your attention towards IPSec Policies. IPSec rules can be seen from Firewall control panel(Wf.Msc)-> Connection Security Rule.

If IPSec is being used, you should make sure the corresponding policies are present on both the machine(unless one machine acts as a  boundary machine). Again turning off BFE would disable IPSEC but that should be done on both the machine if you are  doing experiment. I would like again emphasize that BFE and other dependent services should be  turned on again once you are done with verification.  Ping utility comes often handy to verify the communication between machines. More than often ICMP packets are exempted in IPSEC policies by the admins, so ping can be helpful in verifying the connectivity and making sure if IPSEC  is  causing the problem.

There are also authentication issues while accessing shares but they are not related to connectivity between machines but rather to NTFS and SMB permissions.