/tool sniffer seems to miss hundreds of UDP encapsulated ESP datagrams that are about to leave the device:


(80. is the RouterOS device, 85. is the Windows client)

each of the lines above is Wireshark reporting that a different ESP sequence number was expected, implying one or several hundred missing ESP datagrams.

Sniffer setup:

I did the same packet dump on the other side and the RouterOS sniffer dump does *not* represent, what the receiver got.

Any ideas?

You filter on UDP and port number, but if IP packets are fragmented (which is likely the case here), the L4 addresses (ports) are only present in the first fragment, so the second fragment doesn't match the filter. But since the first fragment is not a complete packet, it doesn't make it to the sniffer output either.

You filter on UDP and port number, but if IP packets are fragmented (which is likely the case here), the L4 addresses (ports) are only present in the first fragment, so the second fragment doesn't match the filter. But since the first fragment is not a complete packet, it doesn't make it to the sniffer output either.

Not one single IP Packet in the dump above has ip.flags.mf (More fragments) set so I guess that can't be it.

Of course there is no MF flag in packets which did make it to the capture. You are interested in those which didn't. As I've understood, you can see those "as-if-missing" packets at receiving side, what is their size there? Also, for the same reason as described (port numbers only present in the first fragment), firewalls often reassemble fragmented packets before matching them to rules/conntrack, so the fragment size may differ at the sender and at the recipient.

First fragments usually contain the L4 header (8 bytes UDP in this case), ip.flags.mf=1 and ip.offset=0.
If ip.flags.mf is not set anywhere, no fragments will follow.

First fragments usually contain the L4 header (8 bytes UDP in this case), ip.flags.mf=1 and ip.offset=0.
If ip.flags.mf is not set anywhere, no fragments will follow.

This is correct. But what I am saying is that the sniffer filter only looks for complete packets if you ask it to match on protocol and port, and it doesn't do reassembly itself, hence it skips any fragments, including the first ones. So if the Mikrotik fragments a larger-than-mtu packet when sending it, the sniffer with this filter (UDP 4500) misses it completely. Try filtering on the remote IP address only, not on UDP 4500, and see what happens.

Try filtering on the remote IP address only, not on UDP 4500, and see what happens.

I just did, same result.
Many more missing ESP UDP datagrams on the sending than on the receiving side.

I just did, same result. Many more missing ESP UDP datagrams on the sending than on the receiving side.

If so, it looks like an overload of the device or a bug of the sniffer.

I just did, same result. Many more missing ESP UDP datagrams on the sending than on the receiving side.

If so, it looks like an overload of the device or a bug of the sniffer.

I assume the latter, the device is not in use and mostly idle.