KNOT Embedded LTE4 - LTE passthrough DHCP stops working

[evac]

Hi everyone,

I got a KNOT Embedded LTE4 to use as a backup connection and have set it up in passthrough mode to a VLAN interface while keeping ether1 with a fixed IP for management, both connected to my router.

Everything works fine the first time the LTE interface starts up, it picks on my router’s MAC address and shows “found peer”, and it gets an IP through DHCP.

However, if the LTE link goes down for any reason, even just disabling/enabling the interface manually, then the DHCP server will never assign an IP again.

Logs still show “found peer” and the correct MAC address, but the DHCP debug logs say “lease not found, no address to give from static pool”.

Here’s an example of me updating APN config, the resulting LTE link down/up, and DHCP failure (message sequence is bottom to top):

The vlan interface does get an IP, and the IP/subnet shows up in DHCP Servers→Networks, so it does not seem to be a problem with the LTE interface/APN config.

Things I have tried:

• long-term/stable/testing/development channels, issue remains with any of the versions
• explicitly add a DHCP server for the vlan interface
• factory reset
• passthrough to ether1 instead, using vlan iface for management
• connect directly to a laptop to make sure it’s not something on the router side

The behavior is exactly the same with any of the above changes.

I’ve ran out of ideas and thus I’m reaching out here to see if anyone has a clue what could be wrong.

Thanks in advance for any help.

[jaclaz]

In passthrough mode?
The DHCP server should be the one of the ISP, not a local one, AFAICU.

Anyway post your configuration for review, instructions here:

Forum rules

Hello and welcome to the Mikrotik forum For all new users that uses RouterOS for the first time and have some questions regarding their config here is short tutorial on how to access RouterOS configuration using "WinBox" and how to export their configuration and posting it properly in their topic. So after you unpack your new device and connect it to the power supply you need to connect it to the PC. Be careful when connecting because to access your new router you need to use one of…

[evac]

When passthrough mode works properly I do see a DHCP server added to “IP→DHCP Server” as well as a lease with the IP assigned to the client.

I think this is normal, and the documentation also states that you can add a DCHP server explicitly to the passthrough interface if you need to change any of its parameters (e.g. lease time): LTE/5G - RouterOS - MikroTik Documentation

In any case, I reset to factory settings again, tried with different SIM card from another operator, and the issue still remains:

Here, things are working properly and the DHCP server extends the lease from the client, then I disable and enable the LTE interface, the link goes up and it finds the peer when it sends another DHCP request, but there is no DHCP server running (“IP→DHCP Server” is now empty) and no reply.

(this time I didn’t add the DHCP server explicitly, if I do, you see the behavior as in the first post, that there is no lease available, I’m guessing because RouterOS didn’t add the static lease when the peer is found)

I have also tried setting a specific passthrough MAC address on the APN config, and this makes no difference.

Here’s the config as requested:

# 2026-02-14 22:56:50 by RouterOS 7.22beta6
# software id = <removed>
#
# model = EC25-EU&KNe
# serial number = <removed>
/interface bridge
add admin-mac=<removed> auto-mac=no comment=defconf name=bridge
/interface lte
set [ find default-name=lte1 ] allow-roaming=yes band=""
/interface vlan
add interface=ether1 name=vlan30 vlan-id=30
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] passthrough-interface=vlan30 passthrough-mac=auto
/iot bluetooth
set bt1 name=bt1 random-static-address=<removed>
/ip pool
add name=default-dhcp ranges=192.168.188.10-192.168.188.254
/queue type
add fq-codel-ecn=no kind=fq-codel name=fq-codel-ethernet-default
/queue interface
set ether1 queue=fq-codel-ethernet-default
/interface bridge port
add bridge=bridge comment=defconf interface=ether1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=lte1 list=WAN
/ip address
add address=192.168.188.1/24 comment=defconf interface=bridge network=\
    192.168.188.0
/ip dhcp-server network
add address=192.168.188.0/24 comment=defconf dns-server=192.168.188.1 \
    gateway=192.168.188.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.188.1 comment=defconf name=router.lan type=A
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1 \
    in-interface=lo src-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" \
    dst-port=33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=fasttrack-connection chain=forward comment="defconf: fasttrack6" \
    connection-state=established,related
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system gps
set init-string="AT+QGPS=1" port=gps
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

[jaclaz]

Not that I am an expert on devices in passthrough mode, but I can see a few things that look "strange" to me.

You have VLAN30 "attached" to ether1, BUT ether1 is part of a bridge.

As I see it EITHER:

1. you take ether1 out of the bridge
   OR:
2. you attach the VLAN30 to the bridge

For what it costs (nothing) I would add to interface list member BOTH ether1 and VLAN30 interfaces as LAN (should be not needed for normal operation, but it should make no harm and likely allow connection to the router also through the VLAN30 via Winbox).

Then you have loads of (defconf) settings that make little or no sense in passthrough mode, they should be not used at all, but maybe they create some (unwanted) conflict.

I would try disabling everything in /ip firewall filter and /ip firewall nat (both the IPV4 and the IPV6).

Then you have 2/3 of a "local" DHCP server, I would disable both:
/ip dhcp-server network
/ip pool
and the DNS entries:
/ip dns
/ip dns static

[evac]

Thanks for the hints.

Some I had already tried before doing a factory reset but in summary I:

• Added vlan30 on the bridge
• Removed unnecessary firewall rules
• Removed local DHCP server, IP pool, DNS server
• Tried /32 subnet passthrough mode

Always the same behavior, at first boot when the LTE link goes up, a DHCP server is created in the 10.0.0.0 range once a peer is detected (or immediately if a passthrough MAC is set), client gets assigned an IP, all is fine.

If for whatever reason the LTE link goes down and then back up, the DHCP server is never started again and the client can’t get an IP anymore.

I also tried to passthrough directly to the bridge without any VLAN interfaces, here you lose access to the device for configuration, so I removed and re-insterted the SIM card to trigger a link down/up event.

Again, all works fine after boot. After removing and re-inserting the SIM card, the LTE status light goes back on, but no DHCP replies…

Besides all the config trials, I’ve tried different operator SIM cards and different clients both on Linux and BSD, so I’m not sure what else to try here…

Has anyone been able to set up LTE passthrough on the KNOT Embedded LTE, is this a bug?

[jaclaz]

Try taking ether1 out of the bridge and attaching the VLAN directly to ether1.

When the LTE resets/whatever what happens if you disable and re-enable the VLAN interface (or the ether1 beneath It)?

It could also be something on the client side, the default lease time should be 1 minute for passthrough mode.
I suspect that such a short default Is set because until half of the lease time has passed there will be no DHCP requests from the client.
So when LTE connection goes down and then up, there won't be any new requests for only 30 seconds at the most.

[evac]

@jaclaz

It could also be something on the client side, the default lease time should be 1 minute for passthrough mode.
I suspect that such a short default Is set because until half of the lease time has passed there will be no DHCP requests from the client.
So when LTE connection goes down and then up, there won't be any new requests for only 30 seconds at the most.

I’m testing this on a linux box where I’m starting/stopping the DHCP client manually and can force a DHCP discovery, so this is not the issue.

I also can see on “IP→DHCP Server” that the server has not started, which should happen as soon as the logs show the peer MAC address has been found.

So, now I edited the config to remove the bridge, firewall rules, local DHCP, etc, so that only the ether1 and vlan30 interfaces remain.

The issue still remains, but disabling and re-enabling the vlan interface as you suggested seems to fix the issue, and the DHCP server is started. I guess that’s something…

I still think this is likely a bug, but as a workaround, I put together a script that checks if the LTE interface is running and there no DHCP leases, then it disables and enables the vlan interface.

I scheduled it to run every minute and this seems to work around the issue. Not perfect, but better than not working at all.

[jaclaz]

Yep, definitely there is something that doesn't work as it should or at least not as expected.

The workaround through script remains a workaround.

Now that you have a clean or as clean as possibnle configuration, if I were you I would open a ticket with support.

The fact that you have tried with different SIMs/ISPs rules out the original server, your manual tests exclude the client, so all that remains is the Mikrotik thingie.

[nevolex]

I regret buying this device, it must have been something with the MODEM or the Firmware, I had a different LTE Mirktoik device sitting in the same place where the KNOT LTE4 is, using the same sim and I Never had an issue with the OLD mirktoik device…

my LTE drops almost every 2 hours non stop and I did log the case and sent them the log, I hope they will reply