TRB501 ICMP anywhere WAN issue?

Hi,

Maybe stupid question, but didn’t find exactly similar issues..

TRB501 just bought and firmware is TRB501_R_00.07.22.3.

I can access WAN OK in bridge or pass through setting, which is my intention as I have FW after modem and don’t wan’t double NAT..

I cannot see any issue with OUT or IN connections, either than ICMP echo request/reply issue :open_mouth:

I cannot ping anything outside, from:

  • TRB501 CLI
  • firewall
  • lan

what gives, with another modem there is no such issue,

what I tried is to look fw rules and add more ICMP allowed rules without success,
Allow Ping from any to wan:

Allow-Ping-A-to-W
Incoming
IPv4
ICMP
From
Any zone
To
wan

Accept forward

Active
IPv4

1.79 K packets

but no replys?!
root@TRB501:~# # ping -4 teltonika.lt
root@TRB501:~# # ping teltonika.lt
root@TRB501:~# ping 8.8.8.8 -c 1
PING 8.8.8.8 (8.8.8.8): 56 data bytes

-– 8.8.8.8 ping statistics —
1 packets transmitted, 0 packets received, 100% packet loss
root@TRB501:~# ping google.com
ping: bad address ‘google.com

____________
LAN client:
03:08 user@pc ~ $nslookup teltonika.lt
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: teltonika.lt
Address: 52.29.225.78
Name: teltonika.lt
Address: 2a05:d014:2eb:6e40:44a6:35b8:b8fc:604c

03:09 user@pc ~ $ping teltonika.lt
PING teltonika.lt (52.29.225.78) 56(84) bytes of data.
^C
— teltonika.lt ping statistics —
20 packets transmitted, 0 received, 100% packet loss, time 19458ms

e. : to add the mobile SIM is using carriers public dynamic wan IP pool, not carrier NAT mobile network

Hello,

Could you please let me know which modem firmware version is currently installed on your TRB501?

If the modem firmware version is RG520NEBDCR03A01M4G , please update the modem firmware using these instructions Modem Firmware Update guide for TRB501 RG520NEBDC and let me know whether this helps resolve the issue.

Best regards,

Hi Marija!

Thanks for reply!

root@TRB501:~# gsmctl -A AT+QGMR
RG520NEBDCR03A02M4G_OCPU_02.200.00.000

I’ve actually been just trying to pinpoint the issue in NAT mode. So the Carrier is DNA Finland, and when the mobile connection is set to use:

  • ipv4+ipv6 PDP = ICMP via ipv6 works but not via ping -4
  • ipv4 PDP mode = No ICMP either

With ipv4 or ipv4+ipv6 PDP normal internet surfing works, DNS, games, etc. But there seems to be issues with ICMP and with some work related services like company resources, VPN etc, i.e. VPN tunnel to work establishes but there is some services which seems to be unreachable.

Let me know if I can share more details, either directly to Teltronika or non-private via this forum.

I’ve tried a bunch of things regarding zone forwarding/routing via chatgpt regarding forwarding rules unsuccessfully, here is extended AI summary of trial and errors and status:

:clipboard: TRB501 IPv4 forwarding issue (post-reset)

After a factory reset on a Teltonika TRB501X (OpenWrt 21.02 / kernel 5.4.197, Quectel RG520 modem), the LTE interface (rmnet_data0) is fully operational and receives both IPv4 and IPv6 addresses from the mobile network (DNA Finland). The router itself has working internet access and correct routing via the LTE interface.

LAN (br-lan) is correctly configured, DHCP works, and clients receive valid IPs (192.168.2.0/24) with correct gateway and DNS. NAT MASQUERADE is present and enabled on the WAN zone. A LAN → WAN forwarding rule is also configured and active.

:cross_mark: Problem

LAN clients cannot access IPv4 internet (ICMPv4 fails completely). IPv6 works normally from both router and LAN, indicating the issue is specific to IPv4 forwarding/NAT path.

The router itself can sometimes reach IPv4 destinations, confirming WAN-side IPv4 connectivity is functional.

:fire: Firewall / forwarding behavior

Firewall configuration appears correct:

  • LAN → WAN forwarding rule exists and is enabled
  • zone_lan_forward is active
  • zone_wan_forward exists but often shows 0 packet counters
  • iptables FORWARD chain uses default DROP policy (expected)
  • NAT MASQUERADE rule is present in WAN postrouting chain

However runtime behavior is inconsistent:

  • IPv4 LAN traffic does not consistently traverse the FORWARD chain
  • zone_wan_forward often remains at 0 packets during tests
  • LAN-side forwarding shows activity, but WAN-side forwarding does not

:test_tube: Troubleshooting already done

  • Verified LTE interface (rmnet_data0) has IPv4 + IPv6 connectivity
  • Confirmed routing table and default gateway are correct
  • Checked LAN bridge (br-lan) and DHCP operation
  • Recreated LAN → WAN forwarding rule via UCI
  • Restarted network and firewall multiple times
  • Verified NAT (MASQUERADE) is present and active
  • Checked ipset rules (ipb_*) — all empty
  • Confirmed IPv6 forwarding works end-to-end

:bar_chart: Key findings

  • IPv6 forwarding works normally
  • IPv4 WAN connectivity exists and is reachable from router
  • NAT configuration is correct and present
  • LAN DHCP and routing are functional
  • IPv4 LAN → WAN forwarding does not reliably enter or traverse firewall FORWARD chain
  • WAN forwarding zone often shows 0 packet counters even under traffic

:warning: Conclusion

This does not appear to be a missing NAT, routing, or DHCP configuration issue. All core components are correctly configured.

The issue is most consistent with a runtime firewall/netfilter forwarding path problem affecting IPv4 only, where LAN-originated IPv4 traffic is not consistently processed by the WAN forwarding zone, while IPv6 traffic remains unaffected.

Problem persists across firewall and network restarts, suggesting a runtime zone attachment or firewall state inconsistency rather than static misconfiguration.

Adding more info, to me this seems to some sort of IPv4 return path/conntrack issue?

Via tcpdump we can actually see that packages are returning (my real public IP’s changed).

root@TRB501:~# ping -c 3 -4 -I rmnet_data0 dns.google
PING dns.google (8.8.8.8): 56 data bytes
— dns.google ping statistics —
3 packets transmitted, 0 packets received, 100% packet loss

root@TRB501:~# tcpdump -ni rmnet_data0 icmp or host 8.8.8.8
14:26:26.767005 IP 8.8.8.8 > 123.123.123.123: ICMP echo reply, id 15890, seq 0, length 64
14:26:27.739426 IP 123.123.123.123 > 8.8.8.8: ICMP echo request, id 15890, seq 1, length 64
14:26:27.759509 IP 8.8.8.8 > 123.123.123.123: ICMP echo reply, id 15890, seq 1, length 64
14:26:28.739690 IP 123.123.123.123 > 8.8.8.8: ICMP echo request, id 15890, seq 2, length 64
14:26:28.759014 IP 8.8.8.8 > 123.123.123.123: ICMP echo reply, id 15890, seq 2, length

root@TRB501:~# ping -c 3 -6 -I rmnet_data0 dns.google
PING dns.google (2001:4860:4860::8888): 56 data bytes
64 bytes from 2001:4860:4860::8888: seq=0 ttl=119 time=18.907 ms
64 bytes from 2001:4860:4860::8888: seq=1 ttl=119 time=21.702 ms
64 bytes from 2001:4860:4860::8888: seq=2 ttl=119 time=21.833 ms

— dns.google ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 18.907/20.814/21.833 ms
root@TRB501:~# tcpdump -i rmnet_data0 -n icmp6
tcpdump: WARNING: arptype 519 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v[v]… for full protocol decode
listening on rmnet_data0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
14:41:22.605762 IP6 2001:14bb…:0000 > 2001:4860:4860::8888: ICMP6, echo request, id 16865, seq 0, length 64
14:41:22.644365 IP6 2001:4860:4860::8888 > 2001:14bb…:0000: ICMP6, echo reply, id 16865, seq 0, length 64
14:41:23.606351 IP6 2001:14bb…:0000 > 2001:4860:4860::8888: ICMP6, echo request, id 16865, seq 1, length 64
14:41:23.625939 IP6 2001:4860:4860::8888 > 2001:14bb…:0000: ICMP6, echo reply, id 16865, seq 1, length 64
14:41:24.606663 IP6 2001:14bb…:0000 > 2001:4860:4860::8888: ICMP6, echo request, id 16865, seq 2, length 64
14:41:24.632943 IP6 2001:4860:4860::8888 > 2001:14bb…:0000: ICMP6, echo reply, id 16865, seq 2, length 64

Okay, made some test, to me this is clear software issue.

How can I be sure that the issue is worked on if Teltronika’s model is devop style development & support?!

I’d like to file a bug report, or change the label:

  • TRB501_R_00.07.16.2 out-of-box conf reset / no WAN ipv4/ipv6 icmp replies / internet still accessible via GCNAT or Public

  • TRB501_R_00.07.16.2 out-of-box conf reset / no WAN ipv4/ipv6 icmp replies / internet still accessible via GCNAT or Public

  • TRB501_R_00.07.17.5 out-of-box conf reset / no WAN ipv4/ipv6 icmp replies / internet still accessible via GCNAT or Public

  • TRB501_R_00.07.18.3 out-of-box conf reset / no WAN ipv4/ipv6 icmp replies / internet still accessible via GCNAT or Public
    (this fw can automatically connect to internet after device reset)

  • TRB501_R_00.07.19.4 out-of-box conf reset / no WAN ipv4/ipv6 icmp replies / internet still accessible via GCNAT or Public

  • TRB501_R_00.07.20.3 out-of-box conf reset / no WAN ipv4/ipv6 icmp replies / internet still accessible via GCNAT or Public

  • TRB501_R_00.07.21.3 out-of-box conf reset / no WAN ipv4/ipv6 icmp replies / internet still accessible via GCNAT or Public

  • TRB501_R_00.07.22.3 out-of-box conf reset / no WAN ipv4 icmp replies / internet still accessible via GCNAT or Public

→ same to the lastest latest TRB501_R_00.07.23.3

I do have to say I like a lot already, but would some RUTX or other model be more mature?

I have the same problem in Germany with the TRB501, FW Version 00.07.23.6.
Testet it with following Modem Firmware’s RG520NEBDCR03A01M4G, RG520NEBDCR03A02M4G and RG520NEBDCR03A03M4G wich was installed by support and have bug by showing Signal Values for N1 Band on the WebUI.

My ISP is DTAG with a special APN to provide static IPv4.

I can ping 1.1.1.1 with out problems but, then I ping 8.8.8.8 or 8.8.4.4 or 9.9.9.9 there is 100% Packet loss.

I also find out, the Traceroute doesn’t show the Hops there are only no IPs *.
In a ZTE MC888 i tested the same SIM with same APN and static IP, ping to 8.8.8.8 or 8.8.4.4 or 9.9.9.9 works with out problems. Also traceroute show all Hops with IP
addresses and no *.

Is there any solution of this problem in work ?

It’s really frustrating to paying high price for enterprise hardware and find out cheap customers works better and with no errors / bugs.

Also i have the problem it show many time limited serices and not registerd home. With other device’s are no problems with the Celluar.