Hi guys,

I use two VPN connections to remote sites: PPTP client on RouterOS directly, and OpenVPN tun client routed via external box (as Mikrotik does not support it...).

I use both RB2011 and RB3011 - and on both routers local traffic works perfectly fine, but whenever I activate fasttrack connection for local LAN, for established and related in forward chain (on RB3011 I tested with default config) - TCP packets to be sent through VPN tunnels die after sending 3965 bytes, no more, not less, always after sending 3965 bytes... So ping, and other diagnostic services work fine, just not larger data packs... And that happens only when fasttrack connection is active in firewall filters - disabling fasttrack solves the problem, just then creates issue with performance. I double checked MTU, it is set everywhere to 1500. I also tested this with 6.37rc34 and the problem is still there...

Any idea what could be wrong? For me it sounds like RouterOS bug, but I'm not really expert...

Are you using Mangle on the packets to the VPN?

If so you'll have to exclude those connections from the Fasttrack rule. I do that by only fastracking established/related connections with connection mark "no-mark" (I mark the connections in mangle before I mark the packet) and are in the "main" routing table.

mikrotik supports openvpn but only the tcp based and not udp based.

If so you'll have to exclude those connections from the Fasttrack rule. I do that by only fastracking established/related connections with connection mark "no-mark" (I mark the connections in mangle before I mark the packet) and are in the "main" routing table.

Thank you, it worked!

Still, it sounds like workaround - I do not find logical explanation why fasttrack would damage those packets...

FastTrack is a feature to reduce CPU overhead on the router by flagging certain connections to almost completely bypass the firewall and queues after the first few packets. This includes filters and mangles. No mangle no route marks on the following packets and they don't get routed properly.

So not a workaround, just have to be sure not to fasttrack connections that require filters, mangles and queue's. (NAT and a few other things will still work)

Your arguments would be valid, just there is one issue: once TCP socket-to-socket connection is established - it should continue via already established route, and not change it after 3965 bytes (actually that was a size I got when testing it with wget, so it could be a bit more).

Each packet has to be marked individually by mangle for the routing mark to be added. The routing mark is not part of connection tracking. Route doesn't work by connection marks, but by packet routing mark.

When FastTrack is set not all TCP packets bypass the firewall. Ones that establish/breakdown a connection, etc., so some packets will come through and be processed by mangle and other would bypass.