OK. How "routing" works in plain IPsec: after all the standard routing and firewall handling has been done, and the last thing left is to send the packet out via the physical interface, the header of the packet is matched against the list of all active IPsec policies, top to bottom. If one of the policies matches the packet header and that policy's
action is
encrypt (which is the default one), it steals the packet and sends it out via its associated security association instead of sending it out via the initially chosen port.
1. How to ping from one router to another - The ping says "Host Unreachable" and names the WAN address
This is because the source address of locally originated packets is chosen depending on the output route. You have two routes, but both via the same connected subnet (provided by DHCP on WAN interface
ether1), so the local source address of the icmp echo request (ping) towards the LAN subnet of the remote Mikrotik is the one assigned to local WAN by DHCP, hence your existing IPsec policy doesn't match it. You have added a dedicated
route with
dst-address matching the other Mikrotik's LAN subnet into the configuration, but haven't set the
pref-src parameter of that dedicated
route to the local IP address from the local LAN subnet. Once you set this parameter of this dedicated route on both machines, ping between them will start working.
2. How to default the Sub Office so all internet traffic goes though the main office.
By changing the IPsec policy at both ends accordingly. In the branch office, set the policy's
dst-address to
0.0.0.0/0; in the headquarter office, set the policy's
src-address to
0.0.0.0/0. But as you need to allow the devices in local LAN and the L2TP clients to talk to the Mikrotik itself and to the devices in the other one of these two groups, in the BO (red) machine you have to add two exceptional policies with
action=none above this one to the list, so the whole list will look as follows:
/ip ipsec policy
add action=none comment="exception for locally terminating traffic" dst-address=192.168.65.0/24 src-address=0.0.0.0/0
add action=none comment="exception for locally terminating traffic" dst-address=192.168.99.0/25 src-address=0.0.0.0/0
add comment=MyVPN dst-address=0.0.0.0/0 sa-dst-address=xx.xx.xx.xx sa-src-address=0.0.0.0 src-address=192.168.65.0/24 tunnel=yes
If you want the L2TP clients of the Red device to be able to talk to devices in Black's LAN (and to get to the internet via Black's WAN), you have to add a copy of the existing
action=encrypt policy to both machines and replace
192.168.65.0/24 by
192.168.99.0/25 in the copy.
Other than that, as you have configured
/ip firewall raw to exclude packets between site LANs from connection tracking, you don't need the
action=accept rules for these subnets in the
/ip firewall nat table because that table is never used for packets excluded from connection tracking. But it also means that the
/ip firewall filter rules in
input and
forward chains with
action=accept and
connection-state=established,related,untracked will match on all such packets, so you cannot use the firewall to restrict traffic between the two LANs - or, more precisely, you can but without the help of connection tracking which makes it a much more complex task.