Let me explain what's happening right now.

We want to communicate with 192.168.88.1 (Mikrotik) ↔ 192.168.128.1, 192.168.135.1 (Meraki).

We have it set up like in the picture above, but if we enable both at the same time in the policy, one of them will not communicate (we have them set up as VLANs on different ports).

First of all, we added ipsec-esp (output) to the firewall rule as you said.

And by secondary address, I meant "Secondary IP", which is a technique to give multiple subinterfaces within one interface.

Secondary IP is a way to divide the bandwidth by giving different addresses on one port.

As above, if I set the main IP (192.168.128.1) and the sub IP (192.168.129.1), the communication is lost. Is there a workaround for this as well?

And finally, you mentioned that ESP packets are not accepted when the connection starts after a long pause, what is the approximate duration of that?

I have attached the file you are referring to, thank you...

Translated with DeepL.com (free version)Let me explain what's happening right now.

We want to communicate with 192.168.88.1 (Mikrotik) ↔ 192.168.128.1, 192.168.135.1 (Meraki).

We have it set up like in the picture above, but if we enable both at the same time in the policy, one of them will not communicate (we have them set up as VLANs on different ports).

First of all, we added ipsec-esp(output) to the firewall rule as you said.

And by secondary address, I meant "Secondary IP", which is a technique to give multiple subinterfaces within one interface.

Secondary IP is a way to divide the bandwidth by giving different addresses on one port.

As above, if I set the main IP (192.168.128.1) and the sub IP (192.168.129.1), the communication is lost. Is there a workaround for this as well?

And finally, you mentioned that ESP packets are not accepted when the connection starts after a long pause, what is the approximate duration of that?

I have attached the file you are referring to, thank you...

• a secondary address is another IP address attached to the same interface like the primary one directly, i.e. without any VLANs
• a "sub-interface" is a Cisco name for a VLAN interface attached to a physical one, so an IP address attched to a sub-interface of interface X is not considered a secondary address of interface X

The following translation was made by the free version of DeepL, and the fact that you have posted the original text in Korean has helped me understand the layout of your Original Post; more important, in this DeepL translation, I do not see any sentences that do not make much sense, like I did in the Original Post.

Let me explain what's happening right now.

We want to communicate with 192.168.88.1 (Mikrotik) ↔ 192.168.128.1, 192.168.135.1 (Meraki).

We have it set up like in the picture above, but if we enable both at the same time in the policy, one of them will not communicate (we have them set up as VLANs on different ports).

First of all, we added ipsec-esp (output) to the firewall rule as you said.

And by secondary address, I meant "Secondary IP", which is a technique to give multiple subinterfaces within one interface.

Secondary IP is a way to divide the bandwidth by giving different addresses on one port.

As above, if I set the main IP (192.168.128.1) and the sub IP (192.168.129.1), the communication is lost. Is there a workaround for this as well?

And finally, you mentioned that ESP packets are not accepted when the connection starts after a long pause, what is the approximate duration of that?

I have attached the file you are referring to, thank you...

Translated with DeepL.com (free version)Let me explain what's happening right now.

We want to communicate with 192.168.88.1 (Mikrotik) ↔ 192.168.128.1, 192.168.135.1 (Meraki).

We have it set up like in the picture above, but if we enable both at the same time in the policy, one of them will not communicate (we have them set up as VLANs on different ports).

First of all, we added ipsec-esp(output) to the firewall rule as you said.

And by secondary address, I meant "Secondary IP", which is a technique to give multiple subinterfaces within one interface.

Secondary IP is a way to divide the bandwidth by giving different addresses on one port.

As above, if I set the main IP (192.168.128.1) and the sub IP (192.168.129.1), the communication is lost. Is there a workaround for this as well?

And finally, you mentioned that ESP packets are not accepted when the connection starts after a long pause, what is the approximate duration of that?

I have attached the file you are referring to, thank you...

Please excuse my "western simplicity" and let me describe the issues in the most straightforward way.

Regarding secondary addresses and subinterfaces, this is my understanding:

• a secondary address is another IP address attached to the same interface like the primary one directly, i.e. without any VLANs
• a "sub-interface" is a Cisco name for a VLAN interface attached to a physical one, so an IP address attched to a sub-interface of interface X is not considered a secondary address of interface X

From the policies in the configuration export, I gather that you use two subnets at Meraki side. From the point of view IPsec, it does not matter whether they share the same (V)LAN or whether each of them is attached to a dedicated VLAN (sub)interface, as IPsec is interested solely in L3 and higer layers.

Regarding IPsec not working:
I am afraid you may attribute the symptoms you observe to different causes than the actual ones. The operation of IPsec interacts heavily with other parts of the configuration, and you have to take this into account and modify the configuration accordingly when adding IPsec to an existing configuration. Whereas most manufacturers take some assumptions and do a lot of adjustments "under the hood", Mikrotik "lets you feel the road" and requires that you do everything manually. This gives you the maximum possible flexibility; the price to pay is the complexity of the configuration.

An issue with NAT:
Matching the packets about to be sent against the traffic selectors of IPsec policies is the very last step of packet processing, which is taken even after src-nat. Since there is no other route to the Meraki subnets than the default one in your configuration, the regular routing sends packets from 192.168.88.0/24 to 192.168.128.0 or 192.168.129.0 via the default route to a.b.c.1, which means that the action=masquerade rule in /ip firewall nat changes their source address to a.b.c.54. And since the traffic selectors only look at the packet after NAT has been executed, they ignore it as it does not match them any more. The /ip firewall nat table is only consulted when handling the initial packet of each connection (like a TCP session or a UDP stream) and all subsequent packets belonging to that connection inherit the same NAT treatment, so this issue affects only connections initiated by hosts on the Mikrotik side. The simplest way to avoid it is to add a match condition dst-address=!192.168.0.0/16 to the action=masquerade rule, but there are several other ways how to achieve the same effect. The goal is always the same, to prevent NATing of the traffic that has to be delivered using IPsec. In some other cases, it is the other way round, you need the traffic to be NATed in order to match an IPsec policy, but that's not relevant for your case.

An issue with fasttracking:
Fasttracking makes processing of packets faster by skipping some stages of packet processing for most packets; IPsec policy matching is one of the steps being skipped. So to quickly resolve this, re-enable the two rules action=accept ipsec-policy=... before the action=fasttrack-connection one in chain forward of /ip firewall filter. One of the purposes of these rules is to prevent connections that need to be forwarded using IPsec from getting fasttracked, see below.

Firewall filter:
Firewall rules can be seen as a programming script. Each packet passes them from the first (top) to last (bottom) one in a given chain (input, output, forward, prerouting, ...) in a given table until it either matches all conditions of that rule or it gets past the last rule without matching any of them. The default behavior of all chains is "accept" and on Mikrotik, it cannot be changed. So no rules in chain output of table filter mean that all packets in that chain will be accepted, so there is no need to add explicit action=accept rules.
Chain input handles packets whose destination is the router itself (so there is no out-interface for such packets); chain output handles packets sent by the router itself (so no in-interface exists for them); chain forward handles packets the router forwards from one external host to another external host. So there is no need to permit UDP ports 500 and 4500 and ESP in forward.
The firewall uses a connection tracking module to analyse the traffic and make it possible to implement a "stateful firewall". This allows you to put a single rule "accept packets belonging or related to already existing connections without further inspection" to the top (beginning) of each chain, and place all the selective permissive rules after (below) that one. So to save some CPU cycles, move the three IPsec-related rules in chain input below the action=fasttrack-connection rule. You can also put both 500 and 4500 as a list of ports to a single rule and remove the other rule.
The rule action=accept ipsec-policy=in,ipsec I have mentioned with regard to fasttracking also prevents payload packets that came encapsulated inside IPsec transport ones from getting dropped by the last rule in chain forward, which says "drop anything that came in via WAN unless it has been dst-nated". The thing is that IPsec does not use any virtual interfaces, so the payload packet inherits the in-interface attribute from the transport packet from which it has been decapsulated.

If it does not work after implementing the changes listed above, please post a fresh export of the config.

Why not.
At least it will be more interactive.
The fact that notifications about new posts don't work again is annoying.

Please follow this post (and a few subsequent ones if needed).

@rlaalstn1055, I have sent you an e-mail message yesterday. Have you received it?

Or can you please contact ...?