Mobile broadband with LTE Passthrough on IP Fire

velifire · 13 January 2026 08:39

Hi,

I have a Mikrotik ATL16 5G (integrated antenna router) that I am looking to use for replacing my SOGEA modem. Currently, IPFire is picking up a WAN IP using PPP over the SOGEA modem (bridge mode)

Goal

ATL16 can be setup in bridge mode using APN “passthrough”, which allows the WAN IP to be passed over to a mac address of a device connected to the ATL16’s single ethernet port. Passthrough mode, turns ATL16 into a layer-2 switch, bridging modem and ethernet port and resulting in all layer 3 router capabilities bypassed.

Challenge

The drawback of this approach is that you loose access to the management interface hence there is no way to monitor Radio band selection, signal strength, etc. The only way to regain access to management interface, is to physically reach for the antenna and press the “reset” button.

Desired Solution: Trunk LTE & Management traffic on IPFire RED nic

Convert ATL16 single ethernet port to VLAN trunk with LTE VLAN traffic handled by IPFire RED zone and Management traffic by GREEN or ORANGE zones.

The two step setup involves

Step 1: Setup the ATL16 VLAN trunk port using info from this youtube video
- LTE → VLAN 30
- Mgmt → VLAN 20
Step 2: Map VLAN trunk port on IPFire RED, taking steer/ideas from this guide

Implementation

Using the shell setup command, I configured RED to DHCP mode from PPP.
Then from UI, I performed the following zone configuration given the VLAN trunk arrives on RED native and rebooted ipfire.

Results & Observations

Following a reboot

I can access the ATL16 management VLAN 20 interface from green
I can see the DHCP traffic between LTE and IPFIRE RED VLAN 30
RED VLAN 30 picks LTE IP address, LTE gateway and DNS servers
Routes created with default gateway the LTE IP address
No traffic is routed to WAN

Here is how IPFire looks from 1 to 5

[ipfire] # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul
t qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: green0p1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc cake master gree
n0 state DOWN group default qlen 1000
    link/ether 12:81:6c:4f:21:39 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP group de
fault qlen 1000
    link/ether 02:81:6c:4f:21:39 brd ff:ff:ff:ff:ff:ff
4: blue0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc cake state DOWN gro
up default qlen 1000
    link/ether cc:b8:a8:dc:f1:78 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.1/24 scope global blue0
       valid_lft forever preferred_lft forever
5: green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP gro
up default qlen 1000
    link/ether 02:43:e1:58:88:43 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 scope global green0
       valid_lft forever preferred_lft forever
6: eth1.20@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake master green0 state UP group default qlen 1000
    link/ether 02:99:e2:6d:f6:a6 brd ff:ff:ff:ff:ff:ff
7: red0@eth1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP group default
 qlen 1000
    link/ether 02:ee:1d:ec:e7:65 brd ff:ff:ff:ff:ff:ff
8: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
    link/ether a6:b8:05:12:79:09 brd ff:ff:ff:ff:ff:ff
9: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
    link/ether ea:88:23:40:e5:89 brd ff:ff:ff:ff:ff:ff
14: imq0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc htb state UNKNOWN group default qlen 32
    link/ether d6:52:88:6a:1f:a6 brd ff:ff:ff:ff:ff:ff

[ipfire] # bridge -d vlan
port              vlan-id
green0p1          1 PVID Egress Untagged
                    state forwarding mcast_router 1
green0            1 PVID Egress Untagged
                    state forwarding mcast_router 1
red0.20           1 PVID Egress Untagged
                    state forwarding mcast_router 1

[ipfire] # ip route
default via 10.177.0.6 dev red0 proto dhcp src 10.29.221.180 metric 1007
10.177.0.6 dev red0 scope link src 10.29.221.180 metric 1007
192.168.1.0/24 dev green0 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev blue0 proto kernel scope link src 192.168.2.1 linkdown

[ipfire] # ping 10.177.0.6
PING 10.177.0.6 (10.177.0.6) 56(84) bytes of data.
^C
--- 10.177.0.6 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6129ms

[ipfire] # ping 10.29.221.180
PING 10.29.221.180 (10.29.221.180) 56(84) bytes of data.
64 bytes from 10.29.221.180: icmp_seq=1 ttl=64 time=0.484 ms
64 bytes from 10.29.221.180: icmp_seq=2 ttl=64 time=0.401 ms
64 bytes from 10.29.221.180: icmp_seq=3 ttl=64 time=0.480 ms
64 bytes from 10.29.221.180: icmp_seq=4 ttl=64 time=0.483 ms
64 bytes from 10.29.221.180: icmp_seq=5 ttl=64 time=0.427 ms

However routing isn’t working and subsequently local services like DNS

[ipfire] # ping 188.31.250.129
PING 188.31.250.129 (188.31.250.129) 56(84) bytes of data.
^C
--- 188.31.250.129 ping statistics ---
51 packets transmitted, 0 received, 100% packet loss, time 51180ms

The red0@eth1 interface cannot be accessed with tcpdump, only red0 and which shows

[ipfire] # tcpdump -i red0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on red0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
00:04:33.737070 IP ipfire.cottageNet > gateway: ICMP echo request, id 53473, seq 65, length 84
00:04:35.704542 IP ipfire.cottageNet.4639 > 188.31.250.128.domain: 52139+ [1au] Type65? www.google.com. (43)
00:04:35.781599 IP ipfire.cottageNet.36229 > 188.31.250.128.domain: 53349+ [1au] PTR? 128.250.31.188.in-addr.arpa. (56)
00:04:36.438633 IP ipfire.cottageNet.5560 > 188.31.250.128.domain: 50127+ [1au] Type65? sync-v2.brave.com. (46)
00:04:41.949172 IP ipfire.cottageNet.6330 > 188.31.250.128.domain: 1604+ [1au] Type65? prod-dynamite-prod-00-us-signaler-pa.clients6.google.com. (85)
00:04:43.072537 IP ipfire.cottageNet.13083 > 188.31.250.128.domain: 51265+ [1au] Type65? chat.google.com. (44)
00:05:47.945037 ARP, Request who-has ipfire.cottageNet tell ipfire.cottageNet, length 28
00:05:47.985486 IP ipfire.cottageNet.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 02:ee:1d:ec:e7:65 (oui Unknown), length 300
00:05:48.001305 IP gateway.bootps > ipfire.cottageNet.bootpc: BOOTP/DHCP, Reply, length 300

I suspect the RED VLAN might not be configured as it should however I cannot find a way to validate it.

Any thoughts/ideas on what I have missed or did wrong ?

ms · 13 January 2026 09:25

Hello,

it seems that you IPFire system is properly connected.

In this output, the red0 interface does not show an IP address, but it seems that IPFire is communicating out of the interface with something as it is shown in the tcpdump output. So I would argue that IPFire is configured correctly and the modem might be filtering the packets.

velifire · 13 January 2026 10:46

Thanks @ms.

The DHCP lease seems to be assigned to red0@eth1 based on its mac address.

The LTE modem when in passthrough / layer-2 mode, is locking on the very first mac address (auto mode) it finds so I assume this is the red0@eth1 mac address and not red0.

Given the tcpdump output on red0, my hypothesis is that traffic goes out (red0eth1 → layer-2 → LTE) but it doesn’t flows back in, LTE → layer-2 → red0eth1

Trying tcpdump on red0eth1 gives interface not available … so how can I tell that ipfire correctly handles frames arriving on WAN port and find correctly their way to red0@eth1 ?

ms · 13 January 2026 11:23

The output of the “ip route” command shows that, just not “ip addr”.

Yes, but that would not be a problem because that MAC address won’t change. It is just a different one.

The interface you are looking for is “red0”. The @ is only some help to indicate on top of which other interface the VLAN is configured.

IPFire is definitely sending packets. I would try to ping the gateway and see if you can at least reach the modem and go from there… It might simply be that the modem is not online and therefore cannot send the packets to the internet.

velifire · 14 January 2026 23:39

I have further investigated the issue and I confirm that the VLAN Trunk setup appears to be working as it should.

red0 picks the IP form the Mobile Operator DHCP server, however with a sort lease of 60s

[ipfire]# ip addr show dev red0
7: red0@eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP group default qlen 1000
    link/ether 02:fc:c6:7f:4d:60 brd ff:ff:ff:ff:ff:ff
    inet 10.146.91.104/28 brd 10.146.91.111 scope global dynamic noprefixroute red0
       valid_lft 55sec preferred_lft 47sec

[ipfire]# ip route
default via 10.146.91.105 dev red0 proto dhcp src 10.146.91.104 metric 1007
10.146.91.96/28 dev red0 proto dhcp scope link src 10.146.91.104 metric 1007
192.168.1.0/24 dev green0 proto kernel scope link src 192.168.1.1
192.168.2.0/24 dev blue0 proto kernel scope link src 192.168.2.1 linkdown

[ipfire]# ip neigh show dev red0
10.146.91.105 lladdr 04:f4:1c:a1:18:27 DELAY

For a very sort while, I can see the traffic leaving eth0 tagged correctly. In this case, pinging the gateway, however I can also browse the internet for a very sort period.

[ipfire]# tcpdump -i eth0 -vv -nn -e icmp

tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:43:31.544991 04:f4:1c:a1:18:27 > 02:fc:c6:7f:4d:60, ethertype 802.1Q (0x8100), length 102: vlan 30, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 9955, offset 0, flags [none], proto ICMP (1), length 84)
    10.146.91.105 > 10.146.91.104: ICMP echo reply, id 60956, seq 988, length 64
21:43:32.548810 04:f4:1c:a1:18:27 > 02:fc:c6:7f:4d:60, ethertype 802.1Q (0x8100), length 102: vlan 30, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 64, id 9983, offset 0, flags [none], proto ICMP (1), length 84)
    10.146.91.105 > 10.146.91.104: ICMP echo reply, id 60956, seq 989, length 64

And all of the above lasts for 60s until the Mobile Operator decides to drop the IP !

2026-01-13 22:49:24 lte1 link up
2026-01-13 22:49:33 lte1 apn: mobop found peer: 02:FC:C6:7F:4D:60
2026-01-13 22:50:38 mobop assigned 10.149.240.167 for 02:FC:C6:7F:4D:60 ipfire
2026-01-13 22:51:38 mobop deassigned 10.149.240.167 for 02:FC:C6:7F:4D:60 ipfire

I did not have this issue (no IP drop) when the ATL16 was set in passthrough mode and connected natively (no VLAN trunk) directly on IPFire.

I have tried the below with no luck

lock the modem to a stable band
lock passthrough to the red0 mac address
allow only ipv4 on APN settings

So I have run out of ideas

PS: here is an idea of the red0 DHCP logs

...
21:20:21	dhcpcd[15018]	: red0: soliciting a DHCP lease
21:19:04	dhcpcd[15018]	: red0: deleting default route via 10.146.91.105
21:19:04	dhcpcd[15018]	: red0: deleting route to 10.146.91.96/28
21:19:04	dhcpcd[15018]	: ps_root_recvmsg: Broken pipe
21:19:04	dhcpcd[15018]	: ps_dostop: Broken pipe
21:19:04	dhcpcd[15018]	: ps_sendpsmmsg: Broken pipe
21:19:04	dhcpcd[17435]	: ps_root_recvmsg: Cannot assign requested address
21:19:04	dhcpcd[17435]	: ps_inet_listenin: Cannot assign requested address
21:19:04	dhcpcd[15018]	: red0: DHCP lease expired
21:19:04	dhcpcd[15018]	: ps_root_recvmsg: Network is unreachable
21:19:04	dhcpcd[15018]	: red0: failed to renew DHCP, rebinding
21:04:47	dhcpcd[15018]	: red0: adding default route via 10.146.91.105
21:04:47	dhcpcd[15018]	: red0: adding route to 10.146.91.96/28
21:04:47	dhcpcd[15018]	: red0: leased 10.146.91.104 for 60 seconds
21:04:43	dhcpcd[15018]	: red0: probing address 10.146.91.104/28
21:04:43	dhcpcd[15018]	: red0: offered 10.146.91.104 from 10.146.91.105
21:04:37	dhcpcd[15018]	: red0: soliciting a DHCP lease
21:04:36	dhcpcd[15018]	: red0: IAID ff:00:00:1e
21:04:36	dhcpcd[15018]	: DUID 00:01:00:01:2c:ab:02:ad:02:29:e3:4d:48:fc
21:04:36	dhcpcd[15015]	: dhcpcd-9.4.1 starting

ms · 15 January 2026 11:00

This is suspicious.

And it reminds me of what Cable modems do when they don’t have a connection to the internet. Instead of connecting to the provider and fetch your assigned IP address, they will give you an IP address from a private address space with a lease time of 60 seconds. That way, the client connected to the modem will come back after 60 seconds and hopefully the modem has successfully connected to the internet by then.

This does however not fit well with that you have internet access for a very short time.

velifire · 15 January 2026 22:22

It appears that I have solved the problem as the red0 IP hasn’t dropped for 3h.

I realised that when the LTE model was coming up Mikrotik is setting up a DHCP server on its lte.vlan.30 interface with 60" lease time.

So what I did was to clone the dynamically created DHCP Server config and change its lease to 1h while keeping all other parameters the same.

(also explained in RouteOS official documentation)

Clearly I don’t understand what is happening behind the scenes when Mikrotik’s ATL16 APN is set to “passthrough” mode, however given that the there has to be a DHCP service to provide the red0 interface with an IP of the 10.x.x.x address range, I hypothesise the modem must also expose another interface on the carrier end which deals with the public IP address. Therefore the modem does some layer-2 bridging between internal and external interfaces ?

I would try different lease times so I can find the smallest value that do not causes dropping of the IP.

Would it worth documenting the process for setting up the VLAN trunk on ipfire ?