If the packets on the client side contain a vlan tag, all offsets will be off by 4. You can compensate with adding "vlan and ..." in front of your filter (resulting in: vlan and tcp [0x2d: 2] == 0x032f and tcp [0x25: 1] == 0x05).
Please note that using a direct offset from the start of the TCP header will only work if all the frames have no (or the same length) of TCP options. It is better to read the TCP data offset and use that in your filter. The TCP data offset can be calculated with tcp[12]&0xf0)>>2, so your filter will become tcp [(tcp[12]&0xf0)>>2 + 25):2] == 0x032f and tcp [(tcp[12]&0xf0)>>2 + 17):1] == 0x05.
So to make the BPF filter both vlan and TCP option length agnostic, you can use:
( tcp [(tcp[12]&0xf0)>>2 + 25):2] == 0x032f and tcp [(tcp[12]&0xf0)>>2 + 17):1] == 0x05 ) or (vlan and ( tcp [(tcp[12]&0xf0)>>2 + 25):2] == 0x032f and tcp [(tcp[12]&0xf0)>>2 + 17):1] == 0x05 ))
If that does not work for you, could you provide a capture file of the client side so I can check what makes the offsets different there?
`
The obvious conclusion is that your capture filter is excluding the outgoing traffic. Without a pcap (unfiltered) to examine we can't offer much help.
Thank you for your quick reply. I have recorded a file, but unfortunately I can not attach it. My filter looks like this: tcp [0x2d: 2] == 0x032f and tcp [0x25: 1] == 0x05 as I said, on the server side, I see the traffic
You can save the capture file on a public share, e.g. Google Drive, DropBox etc., and then add a comment here with a link to the file.
thanks for the tip, file is here ready
https://ufile.io/x8dgd