1) when WAN1 is active and mangle rules are active too, you can ping 18.104.22.168 but not 22.214.171.124?
--> yes, I can ping only 126.96.36.199, the 188.8.131.52 answer timeout
here, ping to 184.108.40.206 is marked and goes via WAN1, and ping to 220.127.116.11 must be marked with toWanUsb, otherwise it could use the route via WAN1 in the default routing table, either due to getting no routing-mark at all and thus using the default table directly, or due to getting a misspelled routing mark and thus using the default table as a fallback as no marked route for the misspelled routing mark would exist. So the routing mark matches at least the one of the blackhole route.
2) when WAN1 is active and mangle rules are not, you can ping both 18.104.22.168 and 22.214.171.124?
--> yes, in this case I can ping both
because both pings take the default routing table (no routing-mark assigned), so both go via WAN1
3) when WAN1 is not active, you can ping 126.96.36.199 regardless whether mangle rules are active or not?
--> with mangle disable I can ping both
so the route via WAN2 (ppp-out1) works, as it can be used when the default routing table sends the packets there
--> with mangle active when I ping 188.8.131.52 it says packet rejected, if I ping 184.108.40.206 it works
So the routing-mark must be correctly assigned for both 220.127.116.11 and 18.104.22.168, otherwise the ping to 22.214.171.124 would not be responded also in this case.
So there must be something else which causes that. With packets generated by Mikrotik itself, there is the so-called "routing adjustment" phase
, allowing policy routing to work also for locally originated packets. So the route for a locally originated packet is first determined using the default routing table, and then the mangle rules in chain=output
eventually assign the routing-mark
- and if they do, the route is chosen again. There is, however, a trap - for locally originated packets, the source address is chosen based on the route, but only during the first routing stage. So if the mangle rules assign a routing-mark
and thus the route is chosen again, the source address of the packet remains unchanged, unless you forcifully change it using a src-nat
rule. And ISP's ppp links often drop packets with a different source address than the one assigned to the customer's end of the link. Some ISPs even drop the whole link and it has to be re-established.
So a rule
action=masquerade chain=srcnat out-interface=ppp-out1 src-address-type=local
as the topmost one in chain=srcnat
in /ip firewall nat
should fix this.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.