Imagine the following scenario. You have 2 WAN’s. One is the primary gateway (ISP landline) wan0 (assume it’s 4.4.4.1), and the second is the secondary gateway (ISP starlink or VPN) wan1 (assume it’s 3.3.3.1). When you try to access some website, that does not respond (IP packet isn’t received in response, i.e. output packet was src:4.4.4.1 to dst: 8.8.8.8, so, the response packet should be src: 8.8.8.8 to dst:4.4.4.1). That might be caused by external blocking firewall.
If the response packet isn’t received after timeout (5 sec), you might try second wan1 (3.3.3.1)
if the response is received - add a temporary record to the routing table (or in the memory address list) to use wan1 for that IP.
This should avoid keeping or maintaining the full routing table for the second wan1. Learn routes instead of listing, less memory & CPU.
To achieve such functionality, MikrotikOS should just keep track of IP connections, that have not received IP packets in response after timeout (it might keep them for a minute or so until the script is able to check accessibility through multi-wan and convert those entries to routes or address list records).
Something close to:
/ip firewall connection print where dst-address~"192.0.2.1" and !seen-reply and repl-packets=0
/ip firewall connection print where !seen-reply and tcp-state="syn-sent"
If the external website has been contacted, the response has to come back via the same channel.
The external website has no way of knowing what your second WAN address is.
Sometimes, it’s okay to get “Could not connect” for the first time and be able to connect from the next attempt.
Still, it’s better than getting “Could not connect” for multiple attempts by trying the same WAN, where the resource is blocked.
Yeah, I know you might switch all traffic by ping, in this case, it’s more granular.
It’s closer by its behavior to MPTCP, which is nice, as it’s optimizing latency.
Yes, it may put non-replied IPs to the address list or another in-memory table with expiration ( 1 or 5 minutes). So the script should be able to loop through the table, try via different wan, and if handshake succeeds - add the routing rule. No load.
Firewall may use the list or not be used at all (i.e. routing table is used instead, but I would prefer firewall)
underneath the forwarding table there are route cache to reduce cpu overhead.
if you want to do pbr by ping test certain target - you just need to ping test intervals, save the results and modify the route automatically. no need to overhaul something that isn’t broken.
and then there will be broken sessions as well (if you use nat) to think about