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).
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.
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.
I actually tried something similar to this a long time ago, but I could never get it to show that the LTE interface was connected to the bridge, nor pull DHCP on the bridge. Furthermore, when I set the passthrough interface, the LTE interface goes up and down several times before not coming back up again. If we could figure out how to make this work, I think it would be great.
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.
While I love the creativity here, I want this to be a bit more standard on several routers that I put out, and having this level of complexity is a little more than I would want my support techs to have to deal with. That’s why I wanted to avoid scripts, even though you stated the scripts would not be fast enough. I do thank you for that bit of advice, however. I may use the practice of running it through the filter process twice like this in later situations.
Was this resolved?
i suspect this is why my link does not last longer than 50 minutes. I am using USB tethering as my Primary link. The connection goes stale the lte connection is up but not passing traffic.