I Have hex s, my lan network is 10.100.102.0/24, the bridge interface on the hex s is set to 10.100.102.1/24
I have a tailscale subnet router on my lan 10.100.102.184/24
i have a static route on the hex s of 10.100.103.0/24 via 10.100.102.184 which means that if i initiate traffic from my lan (10.100.102.0/24) towards 10.100.103.0/24 traffic ingress and egress on the hex s on the same interface (bridge)
if i try to browse to web apps on 10.100.103.0/24 the loading time is very very slow but if i initiate a file transfer i am able to fully utilize the bandwidth avaliable.
If i set a static route on any of the PC’s on 10.100.102.0/0 to send traffic designated to 10.100.103.0/0 directly to 10.100.102.184, web apps works smoothly.
Looks like asymmetric routing. Assuming that you have some “normal” config, client that doesn’t know about the other subnet sends packet to main router, from there it goes to tailscale router, and to destination. Response goes to tailscale router, and from there directly to client, because it’s in same subnet as this router. It doesn’t go via the main router, so its stateful firewall doesn’t see all the traffic it wants to see, and may drop further packets as invalid. Main router informs client using icmp redirect that further packets can be sent directly to the other router, but it’s not guaranteed that client will respect it and how quickly.
So check your main router’s firewall rule that drops connection-state=invalid packets, and add some exception that will allow these.
It sounds like asymmetric flow but since eventually all tcp connections are able to establish and able to push data i didn’t think of, it, if it was as you mentioned tcp connections should have failed to begin with…but tcp connections do establish web app are loaded but very slow and if i stream data (i.e. download file) it utilize the entire available bandwidth.
I’ve observed now all the firewall rules with drop action and initiated a connection to a remote end point, i don’t see any counter increase in any of this rules.
I would say that like in many other cases, sniffing is your friend here.
If a router finds out that the out-interface is the same like in-interface for a packet towards a given destination, it does forward the packet, but it also sends an ICMP message to the original sender, informing it that a better gateway towards that destination than the sending router exists in the same subnet (actually, RouterOS doesn’t even care about the “same subnet” part if eventually multiple subnets are bound to the same interface, but that’s out of scope here). The original sender may or may not make use of that notification; whether it does should depend on the network stack, not on the particular application using it, which does not correlate with your description.
So I would use /tool sniffer on the Mikrotik to visualize the flow - either match only on the IP address of the sending PC if you can be sure that the attempt to connect to that web at 10.100.103.x will be the only traffic during the test, or sniff into a file (or stream the sniffing to another PC) and then view the file using Wireshark whose display filter allows to construct much more precise conditions than the simple capture filter. Bear in mind that to successfully sniff on the Mikrotik, you’ll have to disable the hardware switching on the bridge port through which the PC is connected.