Did small test setup that does what you want to do, here’s the config from the central router, the one for the external routers should be self-explaining (no need for policy routing I suppose)
/ip address
add address=10.1.1.1/24 disabled=no interface=ether1 network=10.1.1.0
add address=10.10.10.1/24 disabled=no interface=ether10 network=10.10.10.0
add address=192.168.198.1/24 disabled=no interface=ether3 network=192.168.198.0
add address=172.16.1.1/24 disabled=no interface=ether4 network=172.16.1.0
eth1 / 10 are simulating your “WAN” interfaces. eth4 is your "“LAN” on router 1
Attention: The IP on eth3 I use for IPSec connection because I don’t want it to use a “connected route” for 10.10.10.x which it would have because in the end this is set up in my test LAN, not over internet … so this is better reflecting your real world setup. Short story: wherever i have 192.168.19x.x, you would need to use your actual WAN IP address of eth10 or the external router.
/ip firewall mangle
add action=mark-connection chain=output connection-state=new disabled=no new-connection-mark=\
CONN-eth10 passthrough=yes src-address=192.168.198.1
add action=mark-routing chain=output connection-mark=CONN-eth10 disabled=no new-routing-mark=RM-eth10 \
passthrough=yes
add action=mark-connection chain=input connection-state=new disabled=no in-interface=ether10 \
new-connection-mark=CONN-eth10 passthrough=yes
add action=log chain=postrouting disabled=no log-prefix="" out-interface=ether10
Mark NEW(!) connection with connection mark. One rule for connections initiated by central router (chain output), one rule for connection initiated by outside world. You may note I do not specifically do this for the IPSec protocols, but mark generally connections that have the proper source IP, or come in over the proper interface. In many cases for multi-WAN setups this is needed anyway. Of course you could also apply more specific criteria for the connection marking.
Then put routing-marks on outgoing connection with connection mark for eth10.
The log rule is just for making things visible during testing.
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.10.10.2 routing-mark=RM-eth10 scope=30 \
target-scope=10
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.1.1.10 scope=30 target-scope=10
One default route without routing-mark, and one default gateway for routing-marked packets.
One thing I stumbled across is that if you want to use IPSec, a route for the IPSec packet must exist that HAS NO ROUTING-MARK, even if you want to policy-route it later anyway. So in this example if you disbale the default route on eth1, it will stop working although technically it still COULD work. The routing-decisions done before IPSec encryption already seem to take into account that the packet will be encrypted, and look for a possible route for the encrypted packet. But they do not take routes with routing marks into account. I wish it would be implemented differently, but then again I may not see the bigger picture here 
/ip ipsec peer
add address=192.168.199.1/32 auth-method=pre-shared-key dh-group=modp1024 disabled=no dpd-interval=2m \
dpd-maximum-failures=5 enc-algorithm=3des exchange-mode=main generate-policy=no hash-algorithm=md5 \
lifebytes=0 lifetime=1d my-id-user-fqdn="" nat-traversal=no port=500 proposal-check=obey secret=\
testingsecret send-initial-contact=yes
/ip ipsec policy
add action=encrypt disabled=no dst-address=192.168.1.0/24 dst-port=any ipsec-protocols=esp level=\
require priority=0 proposal=default protocol=all sa-dst-address=192.168.199.1 sa-src-address=\
192.168.198.1 src-address=172.16.1.0/24 src-port=any tunnel=yes
IPSec stuff … nothing special
Good luck!