Packet Sniffer changes router behavior

Hi, Mikrotik community!
My device is: RB5009 with ROS 7.15.2

Short prehistory:
All ISPs in my country use DPI to block access to some site list, that government means undesirable. Each ISP has it’s own method for site blocking. I was going to investigate the blocking method of my current ISP using Mikrotik’s Packet Sniffer.

Question:
Suddenly I find out that provider’s DPI block stops working when I enable Packet Sniffer on Mikrotik. My browser established connection and that connection worked fine even when I turned off Packet Sniffer. When I tried to reestablish connection after Packet Sniffer already was turned off, the site, as expected, didn’t opened. This issue (enable Packet Sniffer and try to open the blocked site) was repeated couple of times with different sites: only site whose IP-address was used in “IP Address” field of Packet Sniffer is able to establish connection with my browser.
I’ve attached archive with 3 dumps:

  1. PC_wo_Mikrotik.pcapng - TCP-dump collected on my PC without Mikrotik’s Packet Sniffer enabled. Connection to a web-site wasn’t established.
  2. Mikrotik_synched_with_pc_anon.pcapng - TCP-dump collected by Mikrotik’s Packet Sniffer. It’s anonymized, so please consider 123.123.123.123 as my white IP-address. This dump is synchronized with file 3.
  3. PC_synched_with_Mikrotik.pcapng - TCP-dump synchronized with file 2. Collected on my PC using Wireshark.

The only thing I see in dumps is that Mikrotik for some unknown (for me) reason changes packet order: packets 4 and 5 sent by my browser (file 3) are sent by router in reverse order (file 2). What do you think, is it a ROS bug? Maybe this reverse order makes my provider’s DPI go mad and allows me to connect?
TCP-dumps.zip (21.5 KB)

Packet sniffer disables fasttrack … which in turn means that your mangle rules actually apply to all your traffic (fasttrack and mangle are uncompatible).

Sorry for OT, just remark on this

Depends on config, it can work in combination…
Snippet from my config:

/ip firewall mangle
...
add action=accept chain=prerouting comment="Skip mangle for non WAN" in-interface-list=!WAN
add action=accept chain=postrouting out-interface-list=!WAN
add action=mark-connection chain=prerouting comment=DNS connection-mark=no-mark dst-port=53,853 \
    new-connection-mark=DNS passthrough=yes protocol=udp
add action=mark-connection chain=prerouting connection-mark=no-mark dst-port=53,853 new-connection-mark=DNS \
    passthrough=yes protocol=tcp
add action=mark-packet chain=prerouting connection-mark=DNS new-packet-mark=DNS_D passthrough=no
...
/ip firewall filter
...
add action=fasttrack-connection chain=forward connection-mark=no-mark \
    connection-state=established,related hw-offload=yes
...

In this case fastrack will be skipped for marked connections, non WAN connections are not marked and fastrack is used, WAN connections and packets are marked and packets are prioritized with queue tree (not shown in config above).

I’m not saying that fasttrack can not be used … I’m saying that mangling and fasttrack are uncompatible (or is it incompatible?) … with addition: one connection can either be mangled or fasttracked, it can’t be both (and fasttrack takes precedence).
Enabling packet sniffer disables fasttrack, hence my hunch that @OP is trying to do both.

Yes, for mangling connections for which fastrack rule in firewall is applied it will not work, it was a bit general statement so I wrote example where it can work…
In this OP case can be that connections mangling is used for routing and marked connections are using route over non restricted gw (VPN, Xray?) other over ISP WAN - simple solution, disable fastrack rule in firewall and reboot router.

Optio, mkx, thanks for your replies.
No, I don’t use fastrack or mangle. And even if I used them, it doesn’t answers the question about how I braked through the providers DPI, that is blocking access to certain web-sites.
Maybe you can assume why router changed packet order (I think it could be an answer)?

If there is no setup currently on router to avoid ISP DPI, it seems that packet order confuses ISP DPI when sniffer is enabled and avoids filtering as you concluded, there are no other reasons why is this happening if you are sure this wasn’t some temporarily condition on ISP side. Seems strange but it can be bad setup or software which is performing DPI on ISP side.

Optio,
I don’t think that Packet Sniffer itself can change packets order. Can it be some Mikrotik function activated by Packet Sniffer when enabled?

Idk, afaik fastrack is disabled when packet sniffer is started, what else internally ROS is performing when running not sure.