Hello everyone!
I have a router serving a branch office. All the forward traffic from LAN is being encrypted with IPsec and sent to the HQ. Mikrotik's outside interface is connected to the ISP modem and receives an IP-address via DHCP. At this moment the IPsec tunnel is working fine, LAN devices are reaching HQ devices, and vice versa.
The problem is the NTP sync. I want to sync my Mikrotik to the NTP server from the HQ network. But output traffic is not matching IPsec policy, which catches all traffic from LAN to 0.0.0.0. If I configure one more policy to catch traffic from the outside interface NTP sync works fine. But I don't want to set up an IPces tunnel for NTP only.
My second choice was to use SRC-NAT. I have a mangle rule to mark NTP requests with a connection mark. And I have an SRC-NAT rule to substitute the source address (outside interface IP) with LAN bridge IP. Both rules have logging enabled and I see them being applied each time Mikrotik sends an NTP request. Still, the time is not correct. None of my firewall rules blocks the NTP responses. The torch tool shows me a connection from NTP to LAN bridge IP. With nothing happening elsewhere.
As I can see from the torch, output NTP traffic passes SRC-NAT, matches IPsec policy, and passes to HQ. The issue is to utilize the response.

Are you saying that when you use the src-nat way, the NTP response does arrive from the HQ but is ignored, whereas if you use a dedicated SA for NTP, the same response is used properly?

What makes me cautious is that you say that both the mark-connection rule and the src-nat rule are applied "each time". Normally, the nat rules are applied only to the initial packet of each connection, and the default timeout for unresponded UDP is 10s.

So as you forgot to add the export of the router, my wild guess is that you use some /ip firewall raw rule with action=notrack which matches the NTP responses from the HQ, so they cannot be properly "un-src-nated", and thus the NTP client ignores them because they arrive to a different address from the one from which it has sent the requests.

@sindy

quick one on same topic, i got ipsec-tunnel mode site to site.

I have noticed that when im playing with RAW-table it goes mach more fatter than NAT, but also i have noticed that i cant ping other LAN2 with src=LAN1 , YES it works but i cant ping from LANs from MT.

Is that because the packet doesn't go to connection tracking?

Automatic connections are lovely, much faster => mach fatter is a gem.

Yes, NAT is one of functions of connection tracking, so received response packets exempted from connection tracking cannot be "un-NATed" properly.