Not all packets, of course. Just a few, but enough to be potentially a problem if it WERE an LTE interface.
OK, so the autodestruction of the connections is not fast enough (which is no surprise as it probably wasn't a design objective to prevent any packet with a wrong source address from leaking out a wrong interface).
I am not familiar with a mode for the LTE interface. It is a USB modem that I plug in. I also have the LTE package installed. When I plug the modem in, a dynamic interface is created. It is dynamically added to DHCP clients. The only changes aside from default I have made are to the default APN. I just changed the default route distance to 3 and removed "Use peer DNS".
Some USB (and PCI) devices emulate serial modems so the lte package creates a ppp (L3) interface for this type of modems, while others emulate Ethernet network cards so the lte package creates an L2 interface with a dynamically created dhcp client attached to it. As yours creates the DHCP client, it supports the network card emulation mode, so it makes sense to dig further in that direction.
I don't have one handy to try myself, so I can just suggest you to try to create a bridge (named e.g. lte-bridge), set the passthrough-interface
parameter of the /interface lte apn
row you use to lte-bridge
, and attach a manually configured dhcp client to that bridge. If all these steps succeed and the manually configured dhcp client gets an address, you can use the lte-bridge as the backup WAN instead of the previously used lte interface and create an /interface bridge filter
rule preventing packets with ether1's address from leaking to the LTE.
If that doesn't work, there is still an ugly workaround consisting in forcing a double pass through Mikrotik's IP firewall by setting up an IP-IP tunnel from Mikrotik to itself. Let me quote myself from here
The solution is to take any two local addresses and establish an IP-IP tunnel between them, so that we could run the same packet through the whole firewall machinery twice on a single machine. We receive the packet from a physical interface, route it "out" using one of the IP-IP tunnel's ends as the output interface, and we "receive" it the second time from the other end of that tunnel.
So in your case, you would use the "inner" end of the IP-IP tunnel as the backup WAN, and use policy routing (routing-mark, connection-mark and that kind of stuff) to route whatever pops up from the "outer" end of the IP-IP tunnel out via the LTE interface, and route anything that arrives via the LTE to the "outer" end of the IP-IP tunnel. There would be no src-nat or masquerade handling for packets leaving through the "inner" end of the IP-IP tunnel - it would only be applied at the path between the "outer" end of the IP-IP tunnel and the LTE interface.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.