TRB500: Bridge Mode Performance in 2026

[svgyda]

Hi,
We searched through all the possible posts regarding the bridge mode problem with the TRB500 and TRB501 and have found no solution yet. All the existing topics got closed and always end with somebody from Teltonika redirecting the problem to a ticket or privat conversation.

How is it possible that after more then two years we still don’t have a working bridge mode on the TRB500? (and as i read, the “new” TRB501 also has the same problem.) We bought multiple TRB500 for deployment at our locations and clients but have them laying in boxes as our test setup still can’t achieve more then 200mbits in bridge mode (but easily 500-600mbits in NAT, maximum what our SIM provider gives us).

Our Test-Setup right now is running the latest Device and Modem Firmware:
Device: TRB500_R_00.07.21.1
Modem: RG501QEUAAR12A11M4G

Stability is fine(-ish) after the upgrade to the newest Modem Firmware, thanks to the user @gt-solutions (PatrickWegmann on Github). Sometimes the UniFi Firewall can’t aquire the IPv4 address. Newest Device Firmware with the “Local DHPCv4 lease off” toggle fixed it for us.

What we observed so far:

• NAT mode perfomes well, with low latency and full speed. Using a TRB500 and QuMax Omni
• Bridge mode with same hardware barely gets 200, more like 160-180, latency is very high and can’t be fixed with any limiters or queues
• While using bridge mode and running the speedtest, CPU Load spikes to an extreme. WebUi sometimes freezes.
• Random disconnects at night (around 01:00), we have to clarify with our ISP but its probably some routine from their side. Problem is: the TRB500 sometimes doesn’t reconnect and has to be power-cycled. Happens around 3-4 times in a month.
• Very often we encounter the error “Events Log could not be accessed because the database is being optimized.” Event Logs then don’t work. After multiple restarts sometimes they start working, till we restart again. Then they are broken again.

Our goal is to finally have a working, full-speed bridge mode modem. We have yet to find a solution to this.

Does any solution finally exist or should we just write off our loses and buy a different product?

[Justinas]

Greetings,

Our research and development department is aware of this issue and they are working on a fix. The reason for this issue is that when going into bridge or passthrough mode, all traffic goes through our device’s firewall, which our device has to handle, essentially slowing speeds by 2 or 3 times.

There is no ETA currently, but as soon as I get an update, I will get back to you.

Best Regards,
Justinas

[svgyda]

Greetings,

Thanks for answering my post.
Is there an ETA at all, as this issue dates back already to around January 2024 (first posts i found concerning this issue, so over two years of working on this problem)?
In some posts other Teltonika Members speak of a problem with the software/framework provided by Quectel, the maker of the Chipset you guys used in the TRB500.

I don’t really unterstand the point that it goes through the “device’s firewall” as the whole point of bridge mode is to disable and bypass all of that. To me it looks more like a Software defect where the traffic in bridge mode is handled fully in software and not using specific hardware accelerators of the chipset?
As a counter argument: we tried the device in NAT mode running infront of our firewall, then set up a DMZ for the firewall. That way we semi-bypass double NATing and can access our services from outside by our IPv4. So TRB500 (in NAT mode) → DMZ → 3rd-Party-Firewall
By going this route we get the full advertised speed and kind of “bridge mode”. Its a highly janky solution and the firewall doesn’t get the real IPv4 on its interface tho.

It’s not a real solution but shows that it’s not a “device’s firewall” problem, as all the traffic now passes through the build in routing/firewall of the TRB500.
Sorry to say but to me this bridge problem is a fundamental software/driver problem of the OS running on the Quectel chipset.

Would be quite happy to hear atleast some real progress and ETA on that issue. Else we can’t really trust a promise “one day it will be fixed” kinda-deal.

Kind regards,
Vincent
SV-wtu e.U.

[Justinas]

Greetings,

I will clarify with the R&D team if they have any update on this issue and get back to you as soon as possible.

Best Regards,
Justinas

[Morphin]

Hi, I’m very interested in the model TRB501 but i really fear that the issues (Bridge Mode Performance, Moden Beta firmware Version ) etc. is still a problem and users are going away because of this. I will come back in a few month and then hopefully i see this issue fixed and see a more stable version. Thank’s.
Andy

[r.janssen]

Yeah, I also really want to put or TRB500 in bridge mode as our provider has now moved from dynamic public IP towards CGNAT (private IP in 100.64 range), so we get ever more NAT steps in the way (own router, TRB500, ISP CGNAT).

[Bjorn]

@Justinas I cannot see any update from you after your 4 March post. Was there no answer from the R&D team regarding this issue?

@svgyda I’m having the same performance issues as you describe related to bridge mode. Did you hear back from Teltonika regarding the issue, or find a solution? If so, could you please share?

[svgyda]

@Bjorn We didn’t hear anything back from Teltonika Team till today and to be honest have given up on deploying the TRB500 Range of devices at our clients. We won’t be getting any new Teltonika Network devices as well. (GPS Series from Teltonika on the other hand is still heavily in use with us)

The TRB500 is a lost cause… we had even worse problems with our test deployment where the 5G NSA completely stopped working after an update and the auto updater was completely broken. Choosing a stable release still updated to the latest… unacceptable…

You can check our other Post here: TRB500 - 5G NSA not possible after upgrade, 5G RSSI N/A, Type jumping between 5G and 4G+ - #2 by svgyda

One TRB500 is still in our test deployment and stable IF we run FW 00.07.19.4 and NAT Mode. Then the full capacity of our provider can be used. Everything else and the TRB500 is a bottleneck.

Let me know if you find out anything new or Teltonika R&D will get back to you, as we are sitting on multiple pieces of TRB500.

[Justinas]

Greetings,

Apologies that it took so long to get back to you.

@Bjorn @r.janssen @svgyda
The issues should be fixed in the newest firmware release (07.24.1)

Please let me know the results once you test it out.

Best Regards,
Justinas

[svgyda]

So this fix was released yesterday? Exactly after our posts?

Updating as we speak on our test deployment. Will come back with feedback as soon as it’s tested. We are still running the older FWs which also didn’t break 5G NSA. Hope this has been fixed aswell, as nobody ever answered my other post?

@Bjorn let us know how it looks on your side and which provider and 5G connection you are running

[r.janssen]

I checked for firmware updates (latest version) but it offered only 7.24 not 7.24.1

Has the update been pulled?

[Bjorn]

@svgyda Thanks for the update.

@r.janssen The page TRB500 Firmware Downloads - Teltonika Networks Wiki (at least for me) lists TRB500_R_00.07.24.1

@Justinas

• Due to vacation, I cannot currently test the new firmware.
• I expect that Teltonika already has rigorously tested the FW before releasing it, and therefore expect it to work as advertised in the release notes.
• I’ll monitor this thread and post my results (if not already verified by other users).
• By the way, the firmware changelog mentions the Passthrough mode but not Bridge mode. Is there a reason for this limitation, or will a solution come also for Bridge mode?

[svgyda]

Dear people in this thread, I found some time after work hours to go through the update and test all possible options. First to answer some quick questions:

@r.janssen Auto-Updater was also not showing the newest 7.24.1 to me, only 7.24. Can’t trust the Auto-Updater. Downloading the file from the Wiki and flashing it that way worked out.

@Bjorn I don’t know why or how, but it looks like the fix is only applicable to the Passthrough mode, as when selected there is a new toggle for “IPv4 Hardware offloading”. Bridge Mode doesn’t show the toggle. Maybe because Passthrough is like a faked bridge mode which is in reality a NAT Mode with special setup. (Maybe a NAT Setup with DMZ and DHCP Server assigning the public IP to only one client???, don’t really know or get how they make Passthrough work)

Without spending to much time talking about the toggle and Passthrough mode and just in short: This still doesn’t work, not on my end. I am asking other users to test aswell and let us know of your findings. Dear Teltonika Team, i really want to work with you guys and make those devices work, i am not here to dunk all the time on the TRB500 or other devices.

I took the time and made some screenshots and documented my findings. Attached first the config of my modem:

Data is not confidential and the standard setup for Magenta Business SIM in Austria (Magenta is our local T-Mobile Name). Here you can see the new toggle and Passthrough mode selected.

Next we have a speedtest to Nessus locally in Vienna. Settings are as in the first picture. You can clearly see that the CPU is pinned again at 100 percent and we get 180mbit constant. (just like mentioned in my first post). Just so i know that i am not going mad, i have an old iPhone 13 next to me with one of our Magenta SIM cards inserted, achieving 380/13 on the same APN. Upload is worse but maybe the iPhone is struggling there.

Next a speedtest with NAT mode, nothing else changed, same physical position, same APN, just a change in Mode. CPU is at a low 4-5 percent, speed is instantly at 220-230mbit down and especially look at the ping… 283 vs 50ms (idle ping is same, but as soon as we hit traffic it goes crazy. CPU bottlenecking for sure)

Also attached the Speedtest Log of our UniFi Setup. We have an automatic Speedtest at 5AM (to a server chosen by the UniFi System, but always the same) You can clearly see the speed before the update. (here we were running an old FW with NAT Mode, TRB500_R_00.07.19.4, because anything newer blocked our 5G reception) And instantly when i got your message on the forum on the 21st i decided to upgrade and check out the fix. (with some speedtest forced by me but also a speedtest at 5am)

Thats the status on my side right now.
We will keep it for now on the new firmware and run it in NAT mode to see how the 5G NSA connection behaves, as we had some problems with those before.

@Vilius I will be answering you in the other post about the 5G NSA problem we had with FW TRB500_R_00.07.23.6 but just so you know about this thread and also that atleast with the newst FW 07.24.1 we are not seeing problems with 5G NSA and speed is again up to par with NAT mode atleast.
If anybody is interested here is the other thread about a different problem but i hope this has been fixed with the update knock on wood

TRB500 - 5G NSA not possible after upgrade, 5G RSSI N/A, Type jumping between 5G and 4G+

After upgrading our Test Setup TRB500 to the newest firmware, we are getting high packet loss, slow speeds and noticed that the 5G shows RSSI N/A. Following behaviour observed: In idle state Mobile Status shows Network Type as 5G (NSA) with 5G n78 RSSI N/A. (Position and Provider didn’t change, we always had good 5G reception) While under high traffic (or speedtest) connection will drop completely (modem restart, uptime reset) or will jump down to 4G+. No matter what Network Type shows, speed…

[Justinas]

Greetings,

@svgyda, could you please test this out with the option “Disable DHCPv4” turned off, keep in mind offload will apply on on the one device that has the wwan IP address.

For further troubleshooting, we will require more sensitive information from your end, such as the troubleshooting file, which may contain passwords, public IP addresses, serial numbers, and such. To avoid leaking this information, we have sent you a form to fill out, which you will receive in your e-mail inbox that you have registered your account with in the forums. In the Ticket ID field of the form, please enter the ID of this thread, which is 18074

Best Regards,
Justinas

[svgyda]

Dear Justinas,

We tried the option you mentioned already before, but when we turn “Disable DHCPv4” off we don’t get a working connection somehow.

Pinging from the CLI of the TRB500 works but our Firewall has no internet connection or possibility to ping anything on WAN side. The firewall gets the public IP assigned to its interface and that’s it. Not sure if the gateway address is being correctly assigned to the Firewall. It looks like it gets the 192.168.2.1 of the TRB500 as gateway address but also gets our public IP as the interface address. Maybe here lays the problem as it should get a gateway address assigned according to the upstream IP of our provider?

I will try this again completely stand-alone on my work laptop later in time to rule out some weird behaviour on the UniFi Firewall. When using passthrough, is there anything else we should set to make it work?

[Bjorn]

Hi,

I never got around to test before you posted your 22 July update. Did the troubleshooting result in any insights regarding the issues you described?

I now see that 00.07.24.1 is listed as stable … and then one would expect the feature “Mobile: added bridge hardware offload capabilities in passthrough mode” to work.