I work in a telecom NOC and we had a strange problem with the RouterOS. One of our customers was using a server in the local LAN to send data to a remote server using HTTP POST. During this TCP connection RouterOS would generate and send a RST bit to the server all on its own for no apparent reason even tho the router was never communicating with the server but eather just forwarding and NAT-ing traffic. We were sniffing data on the LAN and on the uplink and were noticing this strange behaviour.
The router was configured with NAT and the local LAN server was NAT-ed over a bridge interface with a public IP address 213.147.120.27. In the sniff you can distinctly see that after recieving a packet numbered 21 that the router generates packet 22 which is a RST packet. Every subsequent packet that is recieved by the router destined to the loopback public ip from the remonte servers ip 213.202.103.125 is responed to by the routerOS with a RST packet. This stops the remote server connection and it stops transmitting which causes the whole connection to be dropped which can be seen in packets 25-30 where the local server starts sending retransmitions and then gives up and sends a RST ACK. This keeps happening constatly and normal operation of the communication is not possible.
The RST packet that is seen in packet 22 is never seen on the local lan and the local LAN server never generates it, it is generated on the router.
Does anyone know why this would be happening, is there some security feature in the router that causes this problem. We tried removing all the firewall filters, we tried replacing the router with a different one but same model, we also tried upgreading the OS.
We are unable to replicate this issue because it has been observed only with this specific server-client configuration and we had to fix the customer problem. We did however capture some snff files and i am sending the one i was talking about in the attatchement.
Hmm… this is an interesting issue. i would love to know the reason. are you using /ip proxy ? if yes, disable it and disable the associated dst-nat rule . see if it solves the problem.
If its really the router that is generating those RST packets, i think you should be able to block them with something like this:
if it didn’t work, put it in forward chain, see if its counter goes up. that will help to narrow down the problem. also, create similar rules in mangle prerouting, postrouting, output and forward. and set the actions to passthrough. see which one of those counters will go up. (just make sure you put all of those rules above other ones)
Unfortunatley we are unable to perform any tests anymore since we were forced to replace mikrotik router with a cisco 871 router which solved the problem. The customer was very impatient and would not allow us time to fully test this. We are unable to simulate this process since the server owner is also not cooperative.
There was no ip proxy being used and no dst-nat only src nat for NAT-ing local LAN addresses to a public ip which was configured on a bridge interface this address was 213.147.120.27. If we disabled this nat then no traffic would pass through to the device on the local LAN.
I am sure that the rotuer was generating these RST packet because we were sniffing traffic on the uplink interface (link after packets leave the router to the internet) and also at the same time we were sniffing taffic on the device which was communicating with the server on the local LAN. We neever saw this device generating those RST packets but we were seeing them on the uplink.
We were sniffing using wire taps not on the mikrotik sniff tool.
I was hoping someone might have had a similar issue because it is impossible to recreate this problem now…
Well that’s a shame. i was looking forward to see what the problem was. and i believe with just a little time, we could have found it. the chance of it being a bug is quite unlikely, it most likely was the result of some misconfiguration.
Could be a missconfiguration. But we have over 1500 mikrotik devices in our network with the same config and we have only had this problem with this mikrotik-server configuration. I was suspecting that maybe some TCP packet option or a combination of conditions is causing some kind of a mikrotik security feature to be triggered which then causes the mikrotik device to reset the connection. Im just guessing though. I guess we will never know since we are unable to test. The customer would not allow us to prolong this any longer and we had to replace the device…
