I am not sure I understand the possible reason you are suggesting. I have my mikrotiks DMZed and all PCs connect through mikrotiks... Should I observe something else?
The DMZ functionality may be implemented in many ways in the LAN->WAN direction. In WAN->LAN direction, a DMZ is always a 1:1 dst-nat that doesn't care about ports and protocols. But if there is more than a single device on LAN, the src-nat functionality must still permit N:1 translation in order that all the devices could access internet. And src-nats use different strategies of allocating ports at the public (outside) address. So if the Mikrotik at local end initiates a new connection towards the Mikrotik at the remote end, the remote end may not see it coming from source port 4500. To check that, use
ip firewall connection print detail where dst-address~":4500" while the IPsec connection is up. If the assumption above is correct, the end where the IP address part of the
dst-address is the local one (i.e. the responder) will show a different port part of the
src-address, example from the real world (the public addresses are not the real ones I use):
initiator:
0 SAC protocol=udp src-address=192.168.255.128:4500 dst-address=103.19.25.221:4500 reply-src-address=103.19.25.221:4500 reply-dst-address=192.168.255.128:4500 timeout=2m59s orig-packets=78 250
orig-bytes=7 721 676 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=78 285 repl-bytes=7 657 905 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=29.1kbps
repl-rate=35.3kbps
responder:
0 SAC protocol=udp src-address=192.168.43.1:9970 dst-address=103.19.25.221:4500 reply-src-address=103.19.25.221:4500 reply-dst-address=192.168.43.1:9970 timeout=2m49s connection-mark="use-main"
orig-packets=109 313 orig-bytes=10 858 681 orig-fasttrack-packets=0 orig-fasttrack-bytes=0 repl-packets=109 431 repl-bytes=10 788 671 repl-fasttrack-packets=0 repl-fasttrack-bytes=0
orig-rate=0bps repl-rate=0bps
To see something useful in the log as @erlinden suggests, you have to do the following once the tunnel gets stuck, ideally at both ends simultaneously:
/system logging add topics=ipsec,!packet to activate detailed logging of IPsec
/log print follow-only file=ipsec-struggling where topics~"ipsec" to start logging the IPsec into a file, as the standard log buffers are quite small
After about two minutes, you should have enough data, so you can press Ctrl-C to break the logging, download the files and start analysing them.