#
|
Name
|
Protocol
|
TCP/UDP Ports
|
Description
|
Comment
|
1
|
ping
|
ICMP
|
NA
|
ping 1.1.1.1
icmp echo, icmp
reply between both end systems.
|
Can be used to
test MTU with additional parameters
ping -f -l 1472 destIP
This will try to
send the packet with MTU 1500.
1472 + 8 ICMP
Header + 20 IP header = 1500
Reduce 1472 to
lower number if you get errors until you reach the number that works.
(linux uses udp
ports in the range of 30'000 to 33'000 and needs to be forced to use icmp
ping -M do -s 1472 -c 1 destIP
|
2
|
tracert
|
ICMP
|
NA
|
traceroute -d
1.1.1.1
icmp echo, with
increasing time to live, starts with 1 and usually ends at 30.
Every system on
the way to the end system should return a Time to live exceeded message and
therefore you will be able to identify the IP of a machine in the path
|
If the end system
does not respond the tool will continue to present up to 30 entries all with
****
(-d does not
resolve DNS names, which can take longer. Better for trouble shooting to
start with -d and then if you need the names rerun or do a dns lookup
individually for the ones you want.)
|
3
|
telnet
|
TCP
|
any
|
telnet 1.1.1.1
3389
telnet 1.1.1.1 389
Can be used to
test TCP on specified ports.
|
Somewhat dangerous
as it can be misleading without a network trace if it really worked or not.
The behavior
should be that you connect and it erases the content of the screen and you
have a blinking cursor in the top left
corner. To end the session sometimes you have to quit cmd completely.
|
4
|
nslookup
|
UDP (+ TCP)
|
53
|
nslookup 1.1.1.1 2.3.4.5
nslookup
system.com. 2.3.4.5
Can be tested to
query a DNS server, default is UDP connection
|
first parameter is
the label which can be IP or DNS name, please make use of FQDN with the . at
the end then it will only do 2 queries instead of x (based on search
suffixes)
2nd is the DNS
server you want to test.
If you are not
doing zone transfer and the answer is less than 512 Bytes (usually all single
client connections are less) then it's always UDP otherwise it can be TCP
|
5
|
net view
|
TCP
|
445
|
net view \\1.1.1.1
|
|
6
|
nbtstat
|
UDP
|
137
|
nbtstat -A 1.1.1.1
|
|
7
|
netsh
|
netsh trace start
capture=yes persistent=yes tracefile=c:\temp\capture.etl
Do your tests and
then stop
netsh trace stop
The file can then
be analyzed by Microsoft Message Analyzer
|
The directory uses
in tracefile= must exist before you can start.
|
||
8
|
procmon
|
|
This tool is not
installed by default, must be downloaded from live.sysinternals.com, is a
Microsoft official tool now.
If you don't stop
the collection and configure the settings the tool will respond very sluggish
at best.
|
||
9
|
Message Analzer
|
Microsoft Network
Analysis tool (Wireshark).
But very important
it captures traffic before it hits the windows firewall, whereas Wireshark
will not see the packets if blocked by the windows firewall.
|
On Windows packet
captures can be created without installing any software.
|
||
10
|
QRadar
|
Use Netflow tool to verify if packets travelled and in which direction etc.
Network Activity,
you'll be able to see in real time the flows
|
|||
11
|
hfs
|
Not installed by
default, small executable, is a http server for download and upload.
Used to upload
captures to my client for analysis.
|
So a test series should look something like this:
- ipconfig /all on both
- route print on both
- ping
- tracert
- telnet (must be added, usually can be done without installation path/dvd, just add feature)
- net view
- nbtstat
- nslookup
Here is an example of a test protocol where A-B communication did not work (only UDP and ICMP issue on a single system) but for the windows guys it was both ways for A and B.
Firewall was on but allowed the packets specified. System was a DC so 389 was also used, regular windows system should have TCP/3389(rdp), TCP/445(smb) open as well as UDP/137. Not going into protocol specifics there is much better material available.
Ping
|
C
|
to
|
A
|
ok
|
|
C
|
to
|
B
|
ok
|
||
C
|
to
|
E
|
ok
|
||
C
|
to
|
F
|
ok
|
||
C
|
to
|
D1, D2, D3
|
ok
|
||
A
|
to
|
C
|
ok
|
||
B
|
to
|
C
|
ok
|
||
A
|
to
|
B
|
FAILED
|
||
B
|
to
|
A
|
FAILED
|
||
B
|
to
|
E
|
ok
|
same network as A
|
|
A
|
to
|
F
|
ok
|
same network as B
|
With the help of netflow and or wireshark, netsh trace, message analyzer or procmon it was seen that A does not process incoming ICMP and UDP packets.
Further tests:
telnet
|
C
|
to
|
B
|
3389
|
ok
|
|
telnet
|
C
|
to
|
B
|
389
|
ok
|
|
net view
|
C
|
to
|
B
|
445
|
ok
|
|
nbtstat
|
C
|
to
|
B
|
UDP/137
|
ok
|
|
telnet
|
C
|
to
|
A
|
3389
|
ok
|
|
telnet
|
C
|
to
|
A
|
389
|
ok
|
|
net view
|
C
|
to
|
A
|
445
|
ok
|
|
nbtstat
|
C
|
to
|
A
|
UDP/137
|
ok
|
|
telnet
|
A
|
to
|
B
|
3389
|
ok
|
|
telnet
|
A
|
to
|
B
|
389
|
ok
|
|
net view
|
A
|
to
|
B
|
445
|
ok
|
|
ping
|
A
|
to
|
B
|
icmp
|
FAILED
|
|
nbtstat
|
A
|
to
|
B
|
udp/137
|
FAILED
|
|
same tests
|
A
|
to
|
E
|
all ok!
|
||
telnet
|
B
|
to
|
A
|
3389
|
ok
|
|
telnet
|
B
|
to
|
A
|
389
|
ok
|
|
net view
|
B
|
to
|
A
|
445
|
ok
|
|
ping
|
B
|
to
|
A
|
icmp
|
FAILED
|
|
nbtstat
|
B
|
to
|
A
|
udp/137
|
FAILED
|
|
same tests
|
B
|
to
|
F
|
all ok!
|
||
TCP connections A - B all work,
only icmp and udp fail. Then it got weirder as dns to primary dns was also failing, as well as ICMP but not to 2nd IP of the primary DNS.
Reboot of the server solved the issue, but I would love to have nailed it down, maybe with procmon but was not sure.
