LTE modem disconnects every 2 minutes

RouterOS General
1

Hardware: Mikrotik hAP ac2 RBD52G-5HacD2HnD with LTE modem Alcatel OneTouch Y858V connected to USB port with short cable (20 cm).

Modem works very stable with firmware version 6.43.7. Unfortunately, after upgrading to version 6.45.2, it started to disconnect automatically every two minutes. I tried to upload newer firmware 6.46beta 16 then older 6.45.1 without success. The problem was solved only after changing update channel and uploading 6.44.5 longterm version.
Maybe someone knows what the reason is and can help me.

2

Probably it has some bugs. I’m running 6.45.0 with no problems.

Regards.

3

It turned out that the problem of breaking the connection still occurs. That’s why we exchanged the router for another copy and after that the LTE connection works steadily also with the latest firmware. So it was a hardware problem. Sorry for the confusion.

4

It might have been hardware or firmware…but sometimes LTE carrier drops the connection, not the Mikrotik side, if there are “invalid” packets.

If it happens again, you should always drop invalid packets in the Mikrotik, most of the recent Mikrotik default configuration include this:
/ip firewall filter chain=forward action=drop connection-state=invalid

Also if an NAT’ed/local addresses “escapes” the firewall to the LTE carrier’s networks. e.g. the LTE networks sees a 192.168.88.0/24 address, instead of the IP assigned by the carrier to the LTE interface), some carriers will drop the connection as a security mechanism against DoS attacks using spoofing. And, can happen when NAT “masquerade” is flushing the connection tracking table on the Mikrotik, packets may leave the router without being NAT’ed.

In the most recent versions, Mikrotik’s default configuration for LTE devices prevents both these problems. But if your firewall configuration was based on an earlier version, it lacks the need rules to preventing invalid and non-NAT’ed packets from leaving the router, which can cause the carrier side to just drop.

5

A friend had a broken SIM card that caused similar issues. Any chance to test with another card?

6

@Amm0
It turned out that the problem unfortunately still occurs. So I will have to work on the firewall rules, because you can be right about the causes. Maybe I’m missed something?

/interface bridge
add comment=defconf name=bridge
add name=“bridge wireless guest”
/interface bridge filter
add action=drop chain=input in-bridge=“bridge wireless guest” mac-protocol=ip
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge interface=“wlan N”
add bridge=bridge interface=“wlan A”
add bridge=“bridge wireless guest” interface=“wlan GN”
add bridge=“bridge wireless guest” interface=“wlan GA”
/interface ethernet
set [ find default-name=ether1 ] name=wan
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface list member
add interface=bridge list=LAN
add interface=wan list=WAN
/interface detect-internet
set detect-interface-list=WAN internet-interface-list=WAN

/ip firewall address-list
add address=0.0.0.0/8 comment=RFC6890 list=NotPublic
add address=10.0.0.0/8 comment=RFC6890 list=NotPublic
add address=100.64.0.0/10 comment=RFC6890 list=NotPublic
add address=127.0.0.0/8 comment=RFC6890 list=NotPublic
add address=169.254.0.0/16 comment=RFC6890 list=NotPublic
add address=172.16.0.0/12 comment=RFC6890 list=NotPublic
add address=192.0.0.0/24 comment=RFC6890 list=NotPublic
add address=192.0.2.0/24 comment=RFC6890 list=NotPublic
add address=192.168.0.0/16 comment=RFC6890 list=NotPublic
add address=192.88.99.0/24 comment=“6to4 relay Anycast [RFC 3068]” list=NotPublic
add address=198.18.0.0/15 comment=RFC6890 list=NotPublic
add address=198.51.100.0/24 comment=RFC6890 list=NotPublic
add address=203.0.113.0/24 comment=RFC6890 list=NotPublic
add address=224.0.0.0/4 comment=RFC4601 list=NotPublic
add address=240.0.0.0/4 comment=RFC6890 list=NotPublic
add address=46.x.x.x/29 list=Trusted
add address=10.0.0.0/8 list=Trusted
add address=192.168.0.0/16 list=Trusted
/ip firewall filter
add action=accept chain=input comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
add action=drop chain=input comment=“defconf: drop invalid input” connection-state=invalid log-prefix=“invalid input:”
add action=drop chain=forward comment=“defconf: drop invalid forward” connection-state=invalid log-prefix=“invalid input:”
add action=drop chain=forward comment=“drop forwarded from wireless guest not to WAN” in-interface=“bridge wireless guest” out-interface-list=!WAN
add action=drop chain=input comment=“drop input from wireless guest” in-interface=“bridge wireless guest”
add action=drop chain=forward comment=“drop all packets from internet which should not exist in public network and not ipsec” in-interface-list=WAN ipsec-policy=in,none log-prefix=“!public from WAN:” src-address-list=NotPublic
add action=drop chain=forward comment=“drop all packets to internet which should not exist in public network and not ipsec” out-interface-list=WAN ipsec-policy=out,none log-prefix=“!public from LAN:” dst-address-list=NotPublic
add action=drop chain=forward comment=“drop all from WAN not dstnat and not ipsec” connection-mark=!ipsec connection-nat-state=!dstnat connection-state=new in-interface-list=WAN log-prefix=“!NAT from WAN:”
add action=accept chain=input comment=“remote administration allowed https port 4443 WinBox port 4000” log-prefix=“Remote administration” port=4443,4000 protocol=tcp src-address-list=Trusted
add action=accept chain=forward comment=“accept port forwards” connection-nat-state=dstnat in-interface-list=WAN log-prefix=“port_forwards:”
add action=accept chain=input comment=“accept ICMP” in-interface-list=WAN protocol=icmp
add action=accept chain=input comment=“accept in ipsec policy to router” ipsec-policy=in,ipsec log-prefix=“incoming ipsec:”
add action=accept chain=forward comment=“accept in ipsec policy to LAN” connection-state=established,related in-interface-list=WAN
ipsec-policy=in,ipsec
add action=accept chain=forward comment=“accept out ipsec policy from LAN” connection-state=established,related ipsec-policy=out,ipsec
out-interface-list=WAN
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add action=drop chain=input comment=“drop all not from LAN” in-interface-list=!LAN log-prefix=“dropped in !LAN:”
/ip firewall mangle
add action=mark-connection chain=forward comment=“mark forwarded outgoing IPSec packets” ipsec-policy=out,ipsec new-connection-mark=ipsec passthrough=yes
add action=mark-connection chain=forward comment=“mark forwarded incoming IPsec packets” ipsec-policy=in,ipsec new-connection-mark=ipsec passthrough=yes
/ip firewall nat
add action=accept chain=dstnat comment=“ipsec in no nat” ipsec-policy=in,ipsec in-interface-list=WAN
add action=accept chain=srcnat comment=“ipsec out no nat” ipsec-policy=out,ipsec out-interface-list=WAN
add action=masquerade chain=srcnat comment=“wireless guest masquerade” out-interface-list=WAN src-address=192.168.88.0/24
add action=masquerade chain=srcnat comment=“;;; defconf masquerade” out-interface-list=WAN
/ip firewall raw
add action=drop chain=prerouting comment=“Drop dns udp from WAN” dst-address-type=local dst-port=53 in-interface-list=WAN protocol=udp
add action=drop chain=prerouting comment=“Drop dns tcp from WAN” dst-address-type=local dst-port=53 in-interface-list=WAN protocol=tcp
/routing ospf interface add disabled=yes
/ip neighbor discovery-settings set discover-interface-list=!WAN
/ip settings set rp-filter=strict
/ip settings set tcp-syncookies=yes
/ip ssh set strong-crypto=yes

Below is a fragment of the current log. I’m concerned about “ipsec, error no policy found / generated” hourly messages, whose origins I can not explain. We’ve never met them before, but this is probably a completely different problem that started AFAIR along with the 6.44.5 firmware. Most likely, this is related to the life span of the IKE2 key on the side of our Sophos UTM.

Jul/31/2019 17:23:06 interface,info lte1 detect INTERNET
Jul/31/2019 18:22:30 ipsec,error no policy found/generated
Jul/31/2019 19:22:36 ipsec,error no policy found/generated
Jul/31/2019 20:22:42 ipsec,error no policy found/generated
Jul/31/2019 21:22:48 ipsec,error no policy found/generated
Jul/31/2019 22:22:53 ipsec,error no policy found/generated
Jul/31/2019 23:22:59 ipsec,error no policy found/generated
Aug/01/2019 00:20:38 interface,info lte1 link down
Aug/01/2019 00:20:38 dhcp,info dhcp-client on lte1 lost IP address 192.168.1.191 - lease stopped locally
Aug/01/2019 00:20:49 interface,info lte1 link up
Aug/01/2019 00:20:49 interface,info lte1 detect UNKNOWN
Aug/01/2019 00:20:55 interface,info lte1 detect WAN
Aug/01/2019 00:21:01 dhcp,info dhcp-client on lte1 got IP address 192.168.1.191
Aug/01/2019 00:23:04 ipsec,error no policy found/generated
Aug/01/2019 00:38:11 interface,info lte1 link down
Aug/01/2019 00:38:11 dhcp,info dhcp-client on lte1 lost IP address 192.168.1.191 - lease stopped locally
Aug/01/2019 00:38:22 interface,info lte1 link up
Aug/01/2019 00:38:22 interface,info lte1 detect UNKNOWN
Aug/01/2019 00:38:28 interface,info lte1 detect WAN
Aug/01/2019 00:38:36 dhcp,info dhcp-client on lte1 got IP address 192.168.1.191
Aug/01/2019 01:14:47 interface,info lte1 link down
Aug/01/2019 01:14:47 dhcp,info dhcp-client on lte1 lost IP address 192.168.1.191 - lease stopped locally
Aug/01/2019 01:14:58 interface,info lte1 link up
Aug/01/2019 01:14:58 interface,info lte1 detect UNKNOWN
Aug/01/2019 01:15:04 interface,info lte1 detect WAN
Aug/01/2019 01:15:08 dhcp,info dhcp-client on lte1 got IP address 192.168.1.191
Aug/01/2019 01:23:09 ipsec,error no policy found/generated
Aug/01/2019 02:17:44 interface,info lte1 link down
Aug/01/2019 02:17:44 dhcp,info dhcp-client on lte1 lost IP address 192.168.1.191 - lease stopped locally
Aug/01/2019 02:17:55 interface,info lte1 link up
Aug/01/2019 02:17:55 interface,info lte1 detect UNKNOWN
Aug/01/2019 02:18:01 interface,info lte1 detect WAN
Aug/01/2019 02:18:09 dhcp,info dhcp-client on lte1 got IP address 192.168.1.191
Aug/01/2019 02:24:00 ipsec,error no policy found/generated
Aug/01/2019 03:24:12 ipsec,error no policy found/generated
Aug/01/2019 03:41:29 interface,info lte1 link down
Aug/01/2019 03:41:29 dhcp,info dhcp-client on lte1 lost IP address 192.168.1.191 - lease stopped locally
Aug/01/2019 03:41:41 interface,info lte1 link up
Aug/01/2019 03:41:41 interface,info lte1 detect UNKNOWN
Aug/01/2019 03:41:47 interface,info lte1 detect WAN
Aug/01/2019 03:41:57 dhcp,info dhcp-client on lte1 got IP address 192.168.1.191
Aug/01/2019 03:41:57 interface,info lte1 detect INTERNET
Aug/01/2019 04:24:03 ipsec,error no policy found/generated
Aug/01/2019 05:24:03 ipsec,error no policy found/generated
Aug/01/2019 06:24:04 ipsec,error no policy found/generated
Aug/01/2019 06:43:27 interface,info lte1 link down
Aug/01/2019 06:43:27 dhcp,info dhcp-client on lte1 lost IP address 192.168.1.191 - lease stopped locally
Aug/01/2019 06:43:39 interface,info lte1 link up
Aug/01/2019 06:43:39 interface,info lte1 detect UNKNOWN
Aug/01/2019 06:43:45 interface,info lte1 detect WAN
Aug/01/2019 06:43:51 dhcp,info dhcp-client on lte1 got IP address 192.168.1.191
Aug/01/2019 07:24:05 ipsec,error no policy found/generated
Aug/01/2019 08:24:07 ipsec,error no policy found/generated
Aug/01/2019 08:33:30 interface,info lte1 link down
Aug/01/2019 08:33:30 dhcp,info dhcp-client on lte1 lost IP address 192.168.1.191 - lease stopped locally
Aug/01/2019 08:33:42 interface,info lte1 link up
Aug/01/2019 08:33:42 interface,info lte1 detect UNKNOWN
Aug/01/2019 08:33:48 interface,info lte1 detect WAN
Aug/01/2019 08:33:54 dhcp,info dhcp-client on lte1 got IP address 192.168.1.191

7

did you sort out issue?
if yes how?

8

having the same problem on 6.47 (and many previous versions before that, don’t remember one thats 100% stable)

9

6.47.2 is the latest stable version. Remember to update firmware on LTE modems.

Regards.

10

Beyond invalid packets through the firewall, in some versions, things like IP>Neighbors including the modems (ppp or lte) and/or IP>Cloud>DDNS being enabled can cause issues with PPP modems IMO. Similarly, I haven’t tried it recently, but the newer “Internet Detect” feature has tripped up modems, so we don’t use that either. But when we’ve seen 1-2 minute periodic disconnects, one of those was always enabled (or mis-configured NAT rule wasn’t nat’ing the traffic out to ppp/lte).

In the US, Verizion is very picky on the traffic it accepts: basically they drop the cell connection, if anything isn’t srcnat’d to the provided address. Other carriers may also enforce RFC3704 Strict RP by disconnecting too. Thus any unexpected traffic “leaks” from the Mikrotik internal process that somehow bypass a NAT rule might cause problems.

Now Mikrotik seems to have made fixes in “discovery” and “cloud” in recent versions that I suspect are related… thus the excellent advice to upgrade both the packages(System>Packages) and firmware (System>Routerboard>Upgrade)

I want to say we’ve seen less random disconnect using software form past 6 months, but we also pretty diligent to disable the discovery/cloud/internet detect services from our past experiences.