Issue with Ring cameras & fasttrack

RouterOS General
1

Had an issue with Ring cameras and fasttrack casing connections to drop and not re-establish.
This was specifically when traffic was being forwarded using routing rules from one router to another via default route in second routing table which was in turn going out to the internet over 4G.

If fasttrack was enabled on both routers, we noticed over the course of a few days, the cameras would stop working in the app, but I could still see established connections on both routers.

As soon as fasttrack was disabled for these connections, the issue seems to have gone away for now.

If fasttrack was enabled, but they egressed via default route/WAN on router 1, no problem. Only when routed via R2.

Cameras connected to VLAN 30 on R1 - 192.168.30.0/24
R1 main routing table - default route from PPPoE client via ADSL
R1 4G routing table - default route via ether5/192.168.66.254 (R1: 192.168.66.250 R2: 192.168.66.254)
No NAT applied to connection via R1, default masquerade rule on R2 for traffic leaving via lte1 interface
Default route on R2 from lte1 interface

Routing rules for source address 192.168.30.x/32 lookup in 4G
(Tried using a mangle rule based on source and destination address lists, but this caused SYN,ACK replies to be dropped as invalid - http://forum.mikrotik.com/t/connections-not-tracked-in-new-state/169180/1)

Any ideas why fasttrack was an issue here?

2

Ros version?
I had an issue with fasttrack when using 7.11, but 7.11.2 resolved it.

http://forum.mikrotik.com/t/problems-with-configuring-fasttrack-with-l2tp-ipsec/169057/1

3

7.11.2…
I upgraded from 7.7 to 7.11.2 last weekend. Issues seem to be noticed following the reboot after that upgrade. But I can’t remember whether I also added the fasttrack rule at the same.time (may have been missing before).

4

An option for matching address list can be something like the following:

Use the route marking to match an entry in the rule table, which then
matches an entry in the route table.

/ip firewall mangle
add action=mark-routing dst-address-list=myList new-routing-mark=ruleViaR2

/routing rule
add action=lookup dst-address=0.0.0.0/0 routing-mark=ruleViaR2 table=ViaR2

You can have other rules (eg. Local address ranges) prior to this one.

/ip route
add comment=ViaR2 disabled=no dst-address=0.0.0.0/0 gateway=192.168.66.254 routing-table=ViaR2

Don’t have an entry in the Route table that has selector of routing-table=ruleViaR2

5

This is what I started with, but resulted in SYN,ACK replies from the internet being dropped as invalid.

6

I’m sure you know that fasttrack interferes with mangling, needed to set routing marks … so it is vital to exclude traffic, which needs to be mangled, from being fasttracked. As soon as connection is fasttracked, it’s subsequent packets don’t hit the mangle part of firewall any more.
There are a few ways of how to do that, which one is feasible (or the best) depends on the rest of setup (firewall filters and mangle rules).