I’m rather new to Mikrotik/RouterOS, though I’ve been doing lots of other networking for about 20 years. This has me stumped.
I have a RB951G on a cable modem connection, running current stable v6.35.4. It’s doing basic “home router/AP” functionality. eth1 pulls DHCP from the CMTS, eth2 & wlan1 are “LAN” with DHCP server, DNS server, default srcnat masquerade rule for traffic, etc. No queues, no bandwidth throttling, no dynamic routing, no firewall rules, no dstnat, etc.
Most client traffic works as expected. Some traffic, fails miserably because the RB951G sends TCP RST packets towards the client, and remote server on behalf of each other.
I’ve verified via creating a mirror port for both the WAN/LAN connections and running tcpdump/wireshark. I can see the TLS session negotiation and data communication begin, then RST packet(s) are sent from the RB951G to close the connection (to the remote server and to the client).
I don’t like to guess on a platform I’m not terribly familiar with, but it seems like the ‘only-hardware-queue’ is running out of buffers and closes the connection. Or. there may be some MSS/PMTU or Windowing issue that only comes up during a large/long TCP stream.\
Small HTTP requests or REST API calls work well. Large downloads fail every time. Google Play store downloads fail. It’s consistent.
Would anyone have any ideas why this is occurring?
It probably happens because you removed the default firewall rules.
When there are no firewall rules, there is no connection tracking.
When you really want no rules, make sure you set the option for connection tracking to yes instead of auto.
When you have an interface with MTU less than 1500 (e.g. PPPoE), add a “MSS clamping” rule to the mangle table.
I didn’t remove any firewall rules; there were none. I’ve only added the srcnat rule to NAT the outgoing traffic and a couple of filter rules to block things on the ether1 “WAN” interface. Though, even when those are disabled, I still see the same issues.
Per your suggestion, I set connection tracking to ‘yes’ instead of ‘auto’. But, that did not affect the issue.
MTU of all ethernet interfaces is 1500 (except wlan1, which is 1600). The default setting on the ethernet interfaces was 1598. Changing it hasn’t made a difference.
All interfaces are Ethernet, no PPPoE, PPPoATM or anything else for the connection to the cable modem.
I can swap this router for anything else on the shelf and have no issues. I’m sure there must be some setting that isn’t correct, but the symptoms seem to point to something non-obvious.
Not sure what the issue is but I just wanted to point out a nice troubleshooting feature for ROS: you can run a packet sniffer right in the OS and capture to a file which you can download and open in Wireshark. No mirror port required.
It’s in the tools menu, and you can drag-and-drop to download the capture file.
Maybe it is best to reset the router to defaults so that the default rules are back and see what happens.
It certainly is not a common problem.
(also note I did not recommend you to change the MTU - that may cause future problems!)
Of course! I didn’t take that as a suggestion from you, just something I was curious about with the operation of the Mikrotik. Some routers/firewalls have some odd “intelligence” they try to apply to simple things like routing
Reseting to defaults was the next thing I planned to try today. I did that and the problems vanished. Looking through the Firewall Rules, it appears I was missing some of the defconf rules to enable the related sessions and fasttrack forward rule. These rules make sense; as expected, it’s just a slightly different way of doing things on a new/different platform.
Thanks again for all of the assistance!
