1) when WAN1 is active and mangle rules are active too, you can ping 1.1.1.1 but not 1.0.0.1?
--> yes, I can ping only 1.1.1.1, the 1.0.0.1 answer timeout
here, ping to 1.1.1.1 is marked and goes via WAN1, and ping to 1.0.0.1 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 1.1.1.1 and 1.0.0.1?
--> 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 1.0.0.1 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 1.1.1.1 it says packet rejected, if I ping 1.0.0.1 it works
So the routing-mark must be correctly assigned for both 1.1.1.1 and 1.0.0.1, otherwise the ping to 1.0.0.1 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 or
masquerade 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.