This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Help understand wireshark log

0

Hello,

I´m new wireshark.

I have a IPSEC VPN with a client. Now I need to access the 398 port of his server, but it´s not working.

My ip : 172.16.30.2
Client ip: 10.2.1.133

I type on cmd : “telnet 10.2.1.133 398” and got the error below

Connecting To 10.2.1.133...Could not open connection to the host, on port 398 : Connect failed.

So I´ve ran wireshark with filter tcp.port == 398

176 2.092776 172.16.30.2 10.2.1.133 TCP 66 51166 → 398 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
247 5.088552 172.16.30.2 10.2.1.133 TCP 66 [TCP Retransmission] 51166 → 398 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
401 11.096685 172.16.30.2 10.2.1.133 TCP 62 [TCP Retransmission] 51166 → 398 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1

Bad tcp = black line

I´ve understood that my computer (172.16.30.2) ask a conection [SYN, ECN, CWR], but the other side didn´t answer, so is the problem client?

Is it possible to know if the other site got my packet?

Thanks

asked 28 Jul '16, 11:24

fabiomoraes055's gravatar image

fabiomoraes055
6113
accept rate: 0%

edited 29 Jul '16, 07:45

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k1850


2 Answers:

1

Is it possible to know if the other site got my packet?

If someone at their end can run Wireshark or tcpdump, then yes.

the other side didn´t answer

Or it has answered but the answer never got back to your PC, possibly due to routing misconfiguration on their side.

answered 28 Jul '16, 11:38

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

0

This could be due to one of several possible problems.

But if your capture filter is set for only TCP port 398, then you might be missing part of the picture.

1) Blocked Port Symptoms: Attempt to capture using no filter and check for any ICMP packets which have "administratively filtered" in the payload. This will happen if a router/switch/ACL or firewall/proxy server blocks that port from passing through to the destination. The source IP address of that device blocking the port will be in the ICMP packet itself and can easily point you to where the port is being blocked.

2) Route configuration Symptoms: Try to ping 10.2.1.133 and see if you get a reply. If you get a reply, you know the route is properly configured. If you don't get a reply, it could be either because ICMP packets are blocked or there might be a possible route configuration problem.

3) VPN configuration Symptoms: When making an IPSEC VPN connection, you usually need to have both UDP port 500 and ESP (protocol 1) ports open. Are the IPSEC Phase I and Phase II handshakes completing properly?

4) Capture Interface selection: When capturing IPSec packets from the PC using IPSec, you have to option to choose either the standard network interface (to capture IPSec handshaking protocols) or the VPN tunneled interface (to capture the unencrypted packets). So make sure you choose the proper interface to look at the proper packets.

But it's easiest to have the other side capture packets as well to see whether they really received the packets or not.

FWIW

answered 30 Jul '16, 17:26

wbenton's gravatar image

wbenton
29227
accept rate: 0%