deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-16 10:53:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Add periods to alt text

Browse Source 
No other changes
This commit is contained in:
Gary Moore
2021-08-21 13:08:01 -07:00
parent 963086456e
commit 17262985e6
406 changed files with 2100 additions and 2100 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
windows/client-management/troubleshoot-tcpip-connectivity.md
View File

@ -44,17 +44,17 @@ If the initial TCP handshake is failing because of packet drops, then you would
Source side connecting on port 445:
![Screenshot of frame summary in Network Monitor](images/tcp-ts-6.png)
![Screenshot of frame summary in Network Monitor.](images/tcp-ts-6.png)
Destination side: applying the same filter, you do not see any packets.
![Screenshot of frame summary with filter in Network Monitor](images/tcp-ts-7.png)
![Screenshot of frame summary with filter in Network Monitor.](images/tcp-ts-7.png)
For the rest of the data, TCP will retransmit the packets five times.
**Source 192.168.1.62 side trace:**
![Screenshot showing packet side trace](images/tcp-ts-8.png)
![Screenshot showing packet side trace.](images/tcp-ts-8.png)
**Destination 192.168.1.2 side trace:**
@ -79,15 +79,15 @@ In the below screenshots, you see that the packets seen on the source and the de
**Source Side**
![Screenshot of packets on source side in Network Monitor](images/tcp-ts-9.png)
![Screenshot of packets on source side in Network Monitor.](images/tcp-ts-9.png)
**On the destination-side trace**
![Screenshot of packets on destination side in Network Monitor](images/tcp-ts-10.png)
![Screenshot of packets on destination side in Network Monitor.](images/tcp-ts-10.png)
You also see an ACK+RST flag packet in a case when the TCP establishment packet SYN is sent out. The TCP SYN packet is sent when the client wants to connect on a particular port, but if the destination/server for some reason does not want to accept the packet, it would send an ACK+RST packet.
![Screenshot of packet flag](images/tcp-ts-11.png)
![Screenshot of packet flag.](images/tcp-ts-11.png)
The application that's causing the reset (identified by port numbers) should be investigated to understand what is causing it to reset the connection.
@ -110,8 +110,8 @@ auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /fai
You can then review the Security event logs to see for a packet drop on a particular port-IP and a filter ID associated with it.
![Screenshot of Event Properties](images/tcp-ts-12.png)
![Screenshot of Event Properties.](images/tcp-ts-12.png)
Now, run the command `netsh wfp show state`, this will generate a wfpstate.xml file. After you open this file and filter for the ID that you find in the above event (2944008), you'll be able to see a firewall rule name that's associated with this ID that's blocking the connection.
![Screenshot of wfpstate.xml file](images/tcp-ts-13.png)
![Screenshot of wfpstate.xml file.](images/tcp-ts-13.png)