What needs to be configured to pass traffic from ipsec to mikrotik?

Question

Mikrotik

I configure ipsec Mikritik-DFL260e.
The grid behind the DFL is visible from the side of the grid behind the microtome, but the grid behind the microtome is not visible (except for the microtome itself).
I understand that the matter is somewhere in the marshutization on the microtab "buried", but it does not reach where exactly.
Comrades experts, tell me please.

Answer 1

The firewall rule on the clients is to blame for everything, blocking the connection from the second network.

Answer 2

If the question concerns "pure" IPSec, then:
- there is no routing in it, as such. All information is stored in SAD and SPD. SPD is the Policies tab in the IPSec window, SAD is the Installed SAs tab, it is generated dynamically.
The thing to remember here is that
IPSec goes through the firewall twice . For a clear understanding of how it all turns out, I always recommend this picture.
Let's look at the example of my home router (RB450G), where 1.1.1.1 is my external IP, 2.2.2.2 is the external IP of the remote network. My subnet is 10.54.2.0/24, the remote one is 10.54.1.0/24
The very first thing is the policy setting. It is the policy that decides whether this packet should be encrypted or not?

/ip ipsec proposal
add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=proposal1
/ip ipsec policy
add comment="To Cat's Home main VPN" dst-address=10.54.1.0/24 proposal=proposal1 sa-dst-address=\
    2.2.2.2 sa-src-address=1.1.1.1 src-address=10.54.2.0/24 tunnel=yes

What they did:
Added proposal1, in which ASES256 with a Galois counter was chosen as the encryption algorithm . Since it is self-authenticating, no separate authentication algorithm needs to be specified. Replacing encryption keys every hour.
We set a policy according to which all packets to the network 10.,54.1.0/24 from 10.54.2.0/24 will be turned into ESP protocol packets from IP 1.1.1.1 to IP 2.2.2.2. Actually, this is our "routing table".

/ip ipsec peer
add address=2.2.2.2/32 auth-method=rsa-signature certificate=\
    "RB2011 cert (SHA256) with key" comment="To Cat's Home main VPN" dpd-interval=\
    disable-dpd enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=2h nat-traversal=no \
    proposal-check=strict remote-certificate="RB450G cert (SHA256)"

What they did:
Added a peer - a remote server. Certificate authentication, AES256 encryption, re-key exchange after 2 hours.
Now you need to configure the firewall. Because as shown in the picture, IPSec packets go through it twice .
Let's assume I on a computer with the address 10.54.2.1 I type the command "ping 10.54.1.1".
The packet goes through the tables mangle prerouting, nat prerouting, mangle forward, filter forward (and here, if you have strict filtering and there is no rule allowing traffic from 10.54.2.0/24 to 10.54.1.0/24, it will die), mangle postrouting , nat postrouting and is ready to go to the default gateway, but at this moment the bucket checks it against SPD - shouldn't it be encrypted and resent? Yeah, the packet is subject to policy, so we encrypt it and convert it. And the icmp packet from 10.54.2.1 to 10.54.1.1 is encrypted and packaged into an esp packet from 1.1.1.1 to 2.2.2.2!
Here it is necessary not to forget to insure against NAT. The fact is that when the packet passed nat postrouting, the general rule is

/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether6 to-addresses=1.1.1.1

replaced the source IP so that the "return address" is unique and now the packet is out of policy. And it doesn't fit the policy - it won't be encrypted, but will follow the general routing rules. And the default gateway of the router will turn the packet, turn it - and say "who are you? Come on, goodbye."
To avoid this, you need to specify not to touch packets to which the IPSec policy is applicable - let them pass through NAT unchanged, encrypt them anyway:

add chain=srcnat comment="Does not touch IPSec ESP packets to avoid break packets checksum" \
    ipsec-policy=out,ipsec log-prefix="NAT avoid" out-interface=ether6

The encrypted bucket packet again re-injects into the network stack, it again - already in its new quality - passes mangle output, nat output, filter output (and here, if there is no permission for traffic towards 2.2.2.2 or for the esp protocol, it will die ), mangle postrouting, nat postrouting - and sends it to tyrnet to a remote point.
We assume that on the other hand, the router is configured in the same way, that is, it has its own SPD and its own list of peers. What happens when the package is received:
the packet will go through mangle prerouting, nat prerouting, mangle input, filter input (and if traffic from 1.1.1.1 or the esp protocol is not allowed, then it will die here) ... and is already ready for transmission to higher OSI levels, but here is a bucket checks - but does it need to be decrypted? (and here, if the checksum does not converge, it will die). If the packet matches the policy - it will be decrypted and turned from an esp packet from 1.1.1.1 to 2.2.2.2 into an icmp packet from 10.54.1.1 to 10.54.2.1 - and will be pushed back onto the network stack. And mangle prerouting, nat prerouting, mangle forward, filter forward will go again (and here, if traffic from 10.54.2.0/24 to 10.54.1.0/24 is not allowed, it will die), mangle postrouting, nat postrouting - and finally will get to the output interface where we have 10.54.2.1 connected.
Routing table (the one in the bucket) - not used, all traffic for routers looks local :)