So I've been testing LTE for the past few days and notice and if left overnight, in the AM i usually get the DHCP client with status 'stopped'. The only way to re-enable it is to restart LTE interface. Why is it happening and is there way around it? Also, setting netwatch or script to monitor connection, is difficult as its D (Dynamic) interface on DHCP client. Lastly, re-enabling LTE interface doesnt always work either for resetting LTE DHCP-client.

Any idea why its happening and how can that be resolved.

Although this one smells like something for support@mikrotik.com as the interface says it is running but the DHCP client is stopped which doesn't look like a normal behaviour, it may actually be simply T-mobile taking down connections whose uptime exceeds some pre-defined value (it's T-mobile after all, so you are not supposed to spend your whole life sitting next to the a single BTS).

So first do the following:
Then disable the LTE interrface, re-enable it and wait until the system gets to the strange state. Then use
Then download the file and read it; if it makes sense to you, fine, if it doesn't, post it here (after the usual Ctrl-H to replace the public address(es) appearing there).

Also, setting netwatch or script to monitor connection, is difficult as its D (Dynamic) interface on DHCP client.

If you have in mind that as soon as the VPN gets up and due to your configuration choice it overrides the default route provided by the DHCP client on the LTE interface by its own one with lower distance value, so the netwatch pings take the new default route, there really is an issue because the /interface lte itself currently doesn't provide a hook for a script to be called on up and down events, and the dhcp client is added to the interface automatically so RouterOS won't allow you to set a script on the dhcp client either; the same is the case for /interface l2tp-client. So I'm afraid that only a workaround can be used, consisting in creating the "monitoring routes" based on the default routes added dynamically by the /interface lte and /interface l2tp-client as they come up if their gateway values differ from the new ones. To make it even funnier, you have distinguish the two dynamic routes from one another based on their distance values as no other property is different.

So it would be something like
The script only changes the routes, it does not create them, so you must add them manually in advance. As the script may be called while one of the interfaces is down, the outer-most if in each block prevents it from failing if the respective route currently does not exist.

I think the issue above was cause by faulty and amature firewall setup, with blocking ICMPs etc. After using the suggested approach in the other thread, everything seems to get back online so far. We'll see how it will work.

I do agree with you, that 'Dynamic' state for those interfaces doesnt help resolve those issues easily. I wonder, why Mikrotik team chooses to create that state. I understand that its a by-product of certain configuration, but RouterOS is claims to be one of the most open router os out there. Secondly, i get that 'Dynamic' helps a lot in certain situations to avoid more issues and make it easier to use... though, my final though is that it should give user an option to decide weather to elect dynamic or not.