Packet analyze on router does not match client and server

Question

thank you for your time.

My (virtual) network has 3 objects : a client, a server and a router between them.

I'm sniffing the traffic on the 3 machine with the command

tcpdump -i any -s 0 -w [path]

Both client and server captures around 700 packets. The router always captures the exact sum of both, witch is what I don't understand.

In the router, I can see a lot of bad tcp packets (retransmitted, duplicate ack, out of order), but I never capture them client side nor do I see them server side. How come? I mean, if a packets is retransmitted by the client for example, shouldn't the client-side sniffer capture it too? Am I doing something wrong?

Here some screenshots of the handshake and get request so you can see:

client side

server side

router's traffic

---

That was my first problem.

I don't know if I can ask 2 totaly different question in 1 topic, if it bothers I'm going to open a new one.

Otherwise, second problem : no ARP traffic at all on the router but after the TCP connection is closed. Why does the client want to know the adress of the server and vice versa after the TCP connection and not before?

Here a screenshot :

Answer 1

It looks like whatever command you are using to capture the packets on the router is indeed capturing each packet twice. Given the time difference between the two captures, it looks like it is capturing them as they are received on the ingress port, and then (slightly later) on the egress port. In fact that makes sense with the “-i any” option.

To the analysis tool that (correctly) looks like duplicate or out-of-order packets.

You may want to review the command used on the router to capture packets. Are you capturing ingress and egress on all ports? (Yes: “-i any”) I’d suggest only capturing ingress on all ports, or ingress+egress on one port.

No idea on the arp part of your question. Arp responses are cached by hosts (including routers). A “show arp” command on the router prior to the communication may show the entries already in the arp table, explaining why the arp does not happen at the start of the process. But that does not explain the arps at the end.