Given that you bothered to hide the WAN addresses of both peers (Mikrotik and Meraki) on the screenshots, I figure they are both public. Therefore, the Phase 2 SA uses bare ESP, but your firewall filter rules (at least the ones that did fit into the screenshot) do not accept incoming ESP. So if the connection is intiated from the Meraki side after a long pause, the ESP packet sent by Meraki is not accepted by Mikrotik.
You also seem to be a bit lost in how the firewall configuration works, as you explicitly accept the IPsec-related traffic in the output chain, but there is no drop rule in that chain, so the rest of output traffic is accepted implicitly.
Instead of posting a ton of screenshots, use /export hide-sensitive file=somenicename on the command line, then download the file somenicename.rsc, remove the serial number and replace usernames for various services by xxxxx; for public IP addresses, replace their first three bytes systematically by distinct a.b.c patterns in such a way that the relationship between addreses and subnets remains unchanged, and post the redacted version between [code] and [/code] tags.
Please explain what you mean by Secondary address. Your description is hard to understand overall, could it be that you use some translator that blurs the idea? If so, can you reveal your native language?
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.
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.
