RUT240/241 - [major problem] Passthrough feature not cooperate correctly with Juniper & Huawei Routers

NETWORKING SOLUTIONS
1

Hello Teltonika,
I spend many hours and days and did some testings that I’d like to share to this Community concerning Teltonika RUT240 (RUT241 acts similarly) set to Passthrough mode and pluggedin to behind-connected different Business routers from most well-known Companies on the market: Cisco’s, Juniper’s and Huawei’s.

Generally speaking, only Cisco routers are compatible and cooperate correctly with RUT240, but Juniper and Huawer routers plugged-in to RUT240 doesn’t work at all effectively with Passthrough mode.
It doesn’t matter which version of RutOS I use, this problem persists and is visible starting from RutOS 7.01/02/03 and now 7.04 (even with latest available firmware: 7.04.4 doesn’t work).

What is interesting here, old Legacy firmware RUT2XX_R_00.01.14.6 (I guess it had implemented this feature differently) Passthrough is not affected with that, so it works smoothly withouth any problems, no matter what other Router we gonna plugg-in: Cisco, Juniper, Huawei etc., RUT240 always sends out traffic to Internet, withouth any blocking etc.
In my earlier topic, I have mentioned about that behavior in the old Forum, but that was mostly concering only remote management via HTTPS/SSH, you can read it with this threat:

So, what is exactly going on? What I am doing exactly? [Step-by-Step]

  1. I reconfigure Teltonika RUT240 [Mobile interface mob1a1s1] from NAT mode to Passthrough mode, set additional MAC Address of behing-connected router.
  2. Plugg-in third Party Router (this case one of the: Cisco, Juniper, Huawei) set it’s interface WAN interface to acquire IP address from DHCP Process and plug RJ45 cable to lan RUT240 Teltonika ( interface was also tested here, no differences at all).
  3. My Router interface (set as DHCP Client) is getting and is assigned public IP address correctly from Teltonika DHCP Server, I also receive default-routing to the Internet (0.0.0.0/0) through RUT240, which should be enough to have some connectivity to Internet.
  4. However, from my router’s WAN interface (let’s say its Juniper/Huawei), when I want to execute simple ICMP Echo PING test to the Internet (like to destination IP 1.1.1.1 - this might be any whatever public IP) sourced from my public IP (get from Teltonika) traffic is being send out to the next-hop IP to Teltonika RUT240
    and here traffic is being blocked or dropped at all. No communication out to the Internet.
    In simple: I don’t have (working) routing out to the Internet - even that I see and have default-routing in routing table, traffic is being blocked or dropped at the ingress of Teltonika RUT240, or something is messing this.
  5. I tried even to reconfigure from Passthrough mode directly to Bridge mode - it ends with same results/behavior, failing. I even changed from DHCP-assigned IP address to static IP address configuration, but it doesn’t matter at all.

Few things in my head to consider, here:

  • RUT240 might wrongly recognizes and process incoming (my) IP packets generated from my Juniper/Huawei at it’s Firewall, so it’s being blocked/dropped implicitly etc. It doesn’t try to send it out to Internet, at all.
    (Here: I even tried to set in Firewall section, additional rules: LAN_to_WAN and WAN_to_LAN permit all traffic, without any positive results).

  • it has something to do with working with network masks /30 or /32, here - Teltonika might miscorrectly recognizing (my) IP traffic - that was originated from my router from the same IP address that it has on it’s mobile interface mob1a1s1.
    This might mess recognition traffic at routing-table standard rules etc. I don’t know.

Here, what is interesting, Teltonika RUT240 is assigning via DHCP IP address with mask /32 get from ISP 4G LTE Network to my LAN-connected device and creates special virtual-IP-subnetwork with mask /30, where:

  • first IP/30 - network itself (not usable; network subnet)
  • second IP/30 - public IP address given and assigned to my device from RUT240
  • third IP/30 - public virtual-gateway IP address at Teltonika RUT240 >>> this doesn’t exist anywhere its local-scoped IP used for routing-out traffic to Internetm allthough its public IP address
  • fourth IP/30- broadcast (not usable)
    ATTENTION! This virtual-gateway IP address << placed at Teltonika RUT240 >> is not responding to ICMP Echo Pings at all, even locally between my router and Teltonika, so using this IP as the next-hop for default-route is problematic, because we don’t know is it usable or not at all.

Cisco generally is very flexible and is able to correctly route the traffic into DHCP Process itself (from which I received IP address) while Juniper and Huawei probably need to have explicitly defined and usable (and likely to responding) next-hop IP address to send traffic out to Internet, not sure.

Which devices I have tested:

  • Cisco 897 - Passthrough works 100% OK, Teltonika assings IP address correctly, full routing-out to the Internet through default-route to RUT240
  • Juniper SRX300 - Passthrough not works OK, Teltonika assings my device IP address correctly, but no routing out to the Internet through default-route to RUT240
  • Huawei AR1200F - Passthrough not works OK, Teltonika assings my device IP address correctly, but no routing out to the Internet through default-route to RUT240

Below:

  • I attach few pictures and topology to uderstand it better at close look.

- I WANT TO BUT I CANNOT HERE !! to add attachements but I get message " Sorry, new users can not upload attachments."!! please Contact and PM to me, I can provide you:
- full Report’s from Test with 39 pages in Words (configs RUT240, Cisco,Juniper, Huawei etc. / logs / troubleshooting / debugs etc.), that might give you clue to developers what is problematic.

  • collected from Teltonika (5) PCAP’s files - for futher analysis

Desk laboratory:

desk laboratory
desk laboratory1920×1440 196 KB

Physical Topology– attached below
Logical Topology– attached below

Please address this topic to your Developers to find some solution that should be globally implemented, fixed this permanently in new RutOS firmwares, since this is not fixed for 2 years from now (counted from LegacyOS RUT240 which is no longer developed, but where everything was working fine).
This problem refer to the large number of models and some other Vendor devices too I guess (if u need - I might check out other Juniper’s and Huawei models) but I guess this is repeatable issue, no mater which model I choose.

(BTW Last time when I reported case-related to, it was operated by: Zygimantasbilu and DaumgatasG from old Forum).

Kind Regards,
Robert.

1 Like
2

Physical Topology
obraz

3

Logical Topology
obraz

4

Hello @roberttz ,

It seems that you have a lot of additional information that includes sensitive data. Thus, I suggest that you reach out to your designated sales manager or the reseller from whom you acquired the devices in question. They should be able to assist you in addressing this matter more effectively.

Let me know how it goes.

Kind Regards,

5

I don’t think I have sensitive data to be attached here that could expose something.
Now I don’t have option to add or edit anything else to the topic created by myself.
In the Old Forum I could attach files visible only to Moderators, and it worked well.

Also, I don’t have direct contact with local Sales Manager or Reseller, but I heard one of my company network manager is in contact with some guy Ernestas at Teltonika, but I’m not sure if he reported same case falling to this problem. Anyway, I just heard that some issue is with file 'mobile.sh’ placed at /lib/functions/mobile.sh and possible netmask.

6

Hello,

Currently, there is no private method to send files or messages. This is why I suggested a different approach. If your manager has relevant contacts, do you think it would be possible for you to pass this information through your manager?

Kind Regards,

7

Hi,
OK, thx for information about this new forum limitations.

Well, soon I’m starting my 2 weeks holidays and I’ll be abscent, so I’ll wait for further advance in ongoing case opened from my colleague-manager in company.
I asked him should I share some additional files, but at this point it was not needed further, because some problems were narrowed down via remote session with Support at Teltonika (guy Ernestas Bendzelauskas). So I think right now I don’t want to mix a thread.

Well, if nothing changes (in preparing some solution) in the middle of August, I’ll try to contact with you guys via Contact Form and share files and links to some share servers (dropbox,google drive etc).

Kind Regads, Robert.

8

Hi Robert,

I just started testing out Teltonika (RUT240) for some of our backup internet and IoT applications and I think I might’ve run into a similar issues with the passthrough mode.

First, I’d like to thank you for your detailed posts related to getting remote HTTPS access working when RUT is set to Passthrough mode - this was my first major issue that I encountered on the platform, and your post helped to me to resolve it by creating/configuring the port forward rule exactly as you described. Thank you!

As mentioned, I have a RUT240 (running latest firmware) equipped with SIM card and cellular data service that includes a static public IP. I’ve set the device to Passthrough mode as I want the public IP assigned to our main router/firewall which is connected to the RUT240’s LAN port. First thing I noticed is that when set to Passthrough mode, RUT creates “mobile_bridge” LAN interface with an IP of the next value from my static public IP (similar to your 46.77.101.130). This “mobile_bridge” IP can be pinged from anywhere. In fact I just tried and I was able to ping yours… Which presents a security concern. Secondly, we utilize an external testing service (VoIP Spear) to test whether a site is up/down as well as monitors latency and packet loss. The service is setup to send regular ICMP traffic to the public IP. With our prior setup (Netgear LB1120 in Bridge mode) we had no issue (normal latency and packet loss). Since implementing RUT240 in Passthrough mode we see higher latency and about 60% packet loss - but this is only affecting remote ICMP traffic coming in (local ICMP traffic going out is fine). The RUT240 seems to be doing some kind ICMP filtering/limiting but I can’t find how to disable this. Note that there’s no issues with remote ICMP traffic to the public “mobile_bridge” IP, just to the main public IP.

I haven’t tested yet whether setting the RUT to bridge mode resolves the remote ICMP traffic issue. I also noticed the DMZ feature under Firewall settings… Hoping to test that some time this week.

It would be really helpful if Teltonika could provide documentation that details specifically what features and functionality are disabled when the device is set to passthrough and bridge modes.

9

@ryser.technology: thanks for the attention and your input here. I see you’re experiencing same thing as me. I’m glad to hear and help you out to deal with remote HTTPS issue with combination with Passthrough.
As you mentioned, additional “mobile_bridge” LAN interface is created, this is something usuall and expected to be created (not only Teltonika does it, MiktoTik’s do it in the same way) and visible between RUT and your router/firewall.

Regarding your questions & concerns I answer:

Ad. 1:
When set Mobile interface to Passthrough mode, RUT creates additional virtual subnet as “mobile_bridge” LAN interface from derived SIM IP address /32 and tries to assign to your LAN interface.
It is doing it by expanding public /32 IP address assigned from your ISP into new /30 IP subnet. This happens only locally (on the fly) between Teltonika and your device interfaces and this “new” subnet /30 is not advertised back to Internet to your ISP.
Your Ethernet interface (router/firewall) will be assigned from RUT DHCP process correct public IP address, but you need also another gateway public IP address to create and have static default route out to Internet for this interface (just like you would normally do if you have normal Ethernet LAN interface /24 subnet or other, you need at least 1-IP address functioning as the gateway IP).
Anyway, interesting fact here for you is: usually Mobile ISP expect that you use and have inserted SIM card to cellphone/smartphone that gets only single IP /32 address it, ISP doesn’t need to create IP subnet blocks organised as /30 for every each customer. Smartphones doesn’t need it, routers does.

What I want to say is: you don’t need to be much concerned about security, because even that you see “mobile_bridge” LAN interface as subnet /30 with possible usable two public IP addresses, in fact your device possess only one public IP/32 address and it is seens from perspective of Internet as this public SIM IP address, nothing else.
Presented helper virtual-gateway IP address (in my case it’s 46.77.101.130) is simply locally routing traffic one way out to the Internet. Yes, it does exist in public Internet, but you don’t own it.
Its another different mobile user somewhere in Internet.
I know this might be confusing at this point, because it’s breaking little bit routing rules.

All you need to know here is that:

  • routing OUT to Internet is little bit different than routing IN from Internet to you.

BTW: From perspective of Internet (incoming IP traffic to you) if you are pinging my gateway-IP (46.77.101.130) it simply means that: you are not hitting me and you are just targetting different customer with pings that have this IP.
Lot of words here, better I should draw some picture but I think I explained it in nice way.

Ad. 2:
I guess your testing-service(VoIP Spear) is OK, but I suspect that one of Teltonika’s process is flapping, so there are moments you have perfect low latency [ms] and no packet loss rate score, but another time packets are being dropped and discarded at incoming to Teltonika and not going out to Internet (simply timeout) so you get overall bad score for your tests. Trust me, its not strictly ICMP filtering/limiting, it’s something more simplier and more general lower-layer network issue.

This I will try explain little bit more in my solution, which might help to improve stability of your tests.

1 Like
10

@AndzejJ & All-other-readers:

I’m back from my holiday and I have a promising information to you for finding solution.
One of my network manager from my company assisted with Teltonika developers to craft temporal candidate solution-fix that I would like to share with Community. Case will be, I believe, partially solved I think so.

In the next longer post, I will try to explain surrounding picture little bit further, just so you know what’s going on behind the scene and what’s the origin problem. I just need more 1-2 days to put everything all together.

11

Hello,

@roberttz

Thats good news. Great to hear that you were able to communicate via another channel. Thank you for an update!

Kind Regards,

12

@roberttz Hello, and thank you for the additional info!

I’ve done some more testing over the past few days and I agree that the IP belonging to the “mobile_bridge” interface (created when you switch to passthrough mode), is indeed not accessible over the internet, and if you do get an echo reply then it’s another client/device on the internet. Thank you for confirming.

What’s interesting and curious is why Teltonika creates a virtual /30 subnet… The two Netgear modem models (LB1120 and LM1200) that I’ve been using for years (and have no issues with the ICMP traffic) create a /24 subnet by default when switched to passthrough/bridge mode (they only have “Router” and “Bridge” mode). Why does Teltonika use /30 subnet? What if, because it’s using /30, the IP assigned to the “mobile_bridge” interface is the same as the actual default gateway of the cellular connection and there’s an IP conflict? Or could this strange ICMP traffic behavior be due to the Teltoknika “sharing” the single public IP (only one device [RUT or downstream client/device] can talk at the same time)? Or maybe it’s just cuz the latest firmware is too heavy for the limited resources of the RUT240 (which I realize is EOL)?

13

Hi All,
below I present you closer my Passthrough origin problem discovery and possible solution-fix (this I have tested with RUT240 firmware RutOS 7.04.2, then switched to the latest 7.04.5, but it’s also applicable to RUT241 and working fine, too). :grinning:

Issue background and origin :

Once set Teltonika RUT240 Mobile interface mob1s1a1 to Passthrough mode, RUT starts to assign it’s SIM IP address through DHCP Process and its internal Ethernet LAN port to device you are about to plug-in (Actually to let you know, if you decide to use (alternatively) WAN set as LAN mirror bridge-port, effect would be the same it’s just different br-interface, as in my case).

As the RUT240 router already have on its LAN port interface [eth0, but in my case its br-interface] created and using default LAN subnet 192.168.1.0/24, DHCP Server process in the first step tries “temporarily” to assign our device IP address from that pool 192.168.1.x/24, not our final exactly SIM IP for our specified MAC Address that we expect.

Then, in the second step DHCP is “recognizing” that for defined MAC Address it should not use internal LAN DHCP-binding 192.168.1.x/24 but use our SIM-IP binding. This private IP 192.168.1.x DHCP binding still exist but will not be usable anymore.

BTW: Same behavior I also see on any of my tested routers: Cisco/Juniper/Huawei (set as DHCP Client-interface), they get for single moment private IP address from pool: 192.168.1.x/24 but then after a short while it’s changed to expected and correct public IP address. I can see that behavior logged in syslogs, anyway.

Next, Teltonika RUT240 following DHCP process also creates at L2 specific ARP entries in its ARP Table (CLI command you may check it: ip neigh ), that should match current state of visible devices:
{IP Address} {interface} {MAC Address} {STATE result entry}.
However, here RUT240 crashes and hangs up and have general problem.

It is doing exactly as DHCP process tells it:
first → creates ARP Entry for MAC Address and assign it some random IP address from pool 192.168.1.x/24 – this will not be afterwards cleared/flushed/deleted.
second → tries to creates another APR Entry for MAC Address for Passthrough for SIM IP Address → here it crashes, stucks and have entry as INCOMPLETE, or null(blank) etc.

This is the main reason and root case why it’s failing at L2 ARP - Teltonika already is holding in its ARP first entry private IP address, not applicable here any longer, as our device-router will not have and use this IP, but its blocking overriding to second and vaild entry SIM IP for MAC Address in ARP Table.

this would looks like this, in my case:
192.168.1.140 dev br-lan lladdr e4:fc:82:dc:98:88 STALE
46.77.101.129 dev br-lan lladdr e4:fc:82:dc:98:88 INCOMPLETE

If we will simply correct this second ARP Entry we will have full access and correctly forwarding 100% of IP traffic to Internet .

Solution is very simple: clear and delete first ARP Entry - meaning general refresh it - and let router again to learn new ARP Entry by defining it as static entry in table. That’s it, nothing else.

Now:
Duplication of IP addresses on the interface of my Juniper SRX300 itself does not occur - at finally it gets correct destination IP of SIM cards from DHCP (when I see at router’s ARP Table private entry disappears, it doesn’t exist) and creates correct one ARP entry only for associated Gateway IP address, but duplication is happening and you can see it from perspective of RUT 240 - after running PASSTHROUGH at the same time, for br-lan interface with DHCP, first it tries to lease LAN IP address from private pool 192.168.1.x/24 and then try to replace it again with second mobile SIM IP - at final stage it holds only one valid entry in ARP table for preferred subnet 192.168.1.x/24 with assigned my Juniper MAC address, and another entry with correct mobile IP is just ignored (my case IP 46.77.101.129) it has constant ARP Incomplete state entry.

Teltonika developers promised to correct this behavior with newer firmware version to be released soon.

Solution is very simple:

login via SSH to Teltonika and execute two commands (sometimes you need to repeat it couple of times as this entry is not removed everytime):
root@RUT240:~#ip neigh del 46.77.101.129 dev br-lan
root@RUT240:~#ip neigh add 46.77.101.129 dev br-lan lladdr e4:fc:82:dc:98:88 ->> simply change your correct SIM IP and mac-address

After that ARP Table should looks like this (Example, in my case):
192.168.1.140 dev br-lan lladdr e4:fc:82:dc:98:88 STALE
46.77.101.129 dev br-lan lladdr e4:fc:82:dc:98:88 PERMANENT

However, this solution works only untill you don’t reboot RUT240 either: soft reboot or power outage, then it disappears and you need to repeat again, it start working.

Router starts to pinging something in Internet:
admin@Router> ping 1.1.1.1 source 46.77.101.129
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=36.675 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=36.939 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=44.814 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=33.685 ms
^C

— 1.1.1.1 ping statistics —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 33.685/38.028/44.814/4.121 ms

1 Like
14

Another issue about Passthrough with locally created SIM virtual-subnetwork (general ICMP unreachability from our router to Teltonika virtual-gateway) background:

Once set Teltonika RUT240 Mobile interface mob1s1a1 to Passthrough mode, RUT executes functions defined in script placed at /lib/functions/mobile.sh
One of the parameter is called “bridge_mask” and its default mask is used for communication for Passthrough-device, but its value here is /32 = 255.255.255.255, this is not enough, so any behind-connected device that gets its IP via (DHCP) will have problem reaching local Gateway at Teltonika (like for ICMP Echo pinging locally).

This is the root case for issue – mask /32 works OK at Teltonika but with combination with Passthrough is problematic.

Solution here is to change mask settings and replace this value “bridge_mask” in bridge/passthrough function script for something more wider - from /32 to at least /31 - this will allow at Teltonika to create virtual-gateway and correct handle local routing between devices.

After that, it updates automatically and applicates ‘on the fly’ settings in processes with new modified parameters and starts working.

(In my example/case: applied changes on RUT240/241 router, cause locally created virtual connection between Juniper SRX and Teltonika to become reachable (from derived SIM IP address: 46.77.101.129/32 it replaces mask and for routing purpose subnet of 2 IP addresses /31 for me it’s: IP address .129 - dedicated to router, IP address .130 - virtual-gateway on Teltonica, we don’t need broadcast here)).

You also need to:
re-update firewall entries
re-updates routing/nat entries
restarts mobile interface (again)

For me, what is interesting here: this is the most correct and desirable result, because it worked the same way in old Legacy RutOS 14.6 software and it looked, I guess similar. I wish this should be somehow included and little reimplemented permanently in the firmware, as some exception in script only for Passthrough.

Thanks to this: we gain additional diagnostics, visibility and control of IP traffic management in local network segment between our Cisco/Juniper/Huawei/any-other-device router and our Teltonika.

It’s not a big deal, but it’s useful if you need to do some troubleshooting.

Solution commands → log in via SSH to Teltonika and execute following commands :
(here simply change only Public SIM IP address)

root@RUT240:~# sed -i ‘s/bridge_mask=255.255.255.255/bridge_mask=255.255.255.254/g’ /lib/functions/mobile.sh
root@RUT240:~# iptables -I forwarding_wan_rule -m comment --comment “!fw3: Mobile bridge” -j zone_lan_dest_ACCEPT
root@RUT240:~# iptables -t nat -I postrouting_rule -o wwan0 -j SNAT --to 46.77.101.129
root@RUT240:~# ifup mob1s1a1

Important to note:
from perspective of firmware RutOS 7.04.5 version, you can see good results and desired effect of changes (however below RutOS 7.04.4 version, despite applied our fix - it will not work you won’t see any changes).

Now:
on router that gets leased IP from Teltonik, finally you can ping IP address of virtual-gateway subnet to which default-routing is directed. Previously, it was not possible to run simple ICMP Echo Request ping - even when tested with Cisco, this IP address didn’t respond to the ping (timeout).
Thanks to this, now we can be sure that local routing is working and expected and IP traffic is going correctly from /to Internet and it is visible with ping/traceroute’s.

For example, for me:
46.77.101.129 - IP address assigned from Teltonika on Juniper SRX300
46.77.101.130 - Gateway IP address on Teltonica through which traffic to the Internet goes

admin@Router> show route
inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

  • = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Access-internal/12] 1d 11:37:54
> is 46.77.101.130 via ge-0/0/0.0
46.77.101.128/30 *[Direct/0] 1d 11:37:54
> via ge-0/0/0.0
46.77.101.129/32 *[Local/0] 1d 11:37:54
Local via ge-0/0/0.0

admin@Router> show arp no-resolve
MAC Address Address Interface Flags
00:1e:42:28:01:ac 46.77.101.130 ge-0/0/0.0 none

admin@Router>
admin@Router> ping 46.77.101.130 source 46.77.101.129
PING 46.77.101.130 (46.77.101.130): 56 data bytes
64 bytes from 46.77.101.130:
icmp_seq=0 ttl=64 time=1.342 ms
64 bytes from 46.77.101.130: icmp_seq=1 ttl=64 time=2.398 ms
64 bytes from 46.77.101.130: icmp_seq=2 ttl=64 time=1.372 ms
64 bytes from 46.77.101.130: icmp_seq=3 ttl=64 time=1.164 ms
64 bytes from 46.77.101.130: icmp_seq=4 ttl=64 time=1.240 ms
64 bytes from 46.77.101.130: icmp_seq=5 ttl=64 time=1.417 ms
^C
— 46.77.101.130 ping statistics —
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.164/1.489/2.398/0.415 ms

1 Like
15

To summarize all things together :

CLI commands will be effective until next reboot of the RUT240/241 device or execute factory reset.
After it happens you need to enter this CLI commands once again to restore it to function.

To automate things up you may also use GUI to auto-apply commands once RUT will boot up:

Simply go directly in WebUI to 'System → Custom Scripts’, and here Copy-Paste all necessary commands. Now, you can forget about manually logging in via SSH and executing commands after each reboot. (Just paste it all as it is - change only specific values of MAC’s, IP’s etc. corresponding to your device) :smiley::
In case of factory reset, repeat whole procedure once again.

sed -i ‘s/bridge_mask=255.255.255.254/bridge_mask=255.255.255.254/g’ /lib/functions/mobile.sh
iptables -I forwarding_wan_rule -m comment --comment “!fw3: Mobile bridge” -j zone_lan_dest_ACCEPT
iptables -t nat -I postrouting_rule -o wwan0 -j SNAT --to 46.77.101.129
ifup mob1s1a1
ip neigh del 46.77.101.129 dev br-lan
ip neigh add 46.77.101.129 dev br-lan lladdr e4:fc:82:dc:98:88

I believe this is all I wanted to show for anybody interested in this topic :slight_smile: :slight_smile: :slight_smile:

Case is at least temporarily solved at forum, so you can craft a patch to your configurations.

2 Likes
17

Hello,

@roberttz

Thank you for a very comprehensive explanation of the issue and its solution. While the issue will be addressed with newer firmware releases, your insights can greatly help other users who encounter similar issues right now, allowing them to find a solution. It may also be helpful for people who can’t easily update their firmware to the newest version due to various reasons. Thank you!

Kind Regards,

1 Like
18

I no longer believe my ICMP routing issue is related to the Teltonika (or if it was then some combination of reboots and/or removing and re-installing SIM card fixed it). I now believe it was a carrier issue as I haven’t used the device for over a week and now today it’s working fine. That said, I wanted to echo @ArcticArrow comment and thank you @roberttz for the extensive testing and detailed results you’ve provided. Passthrough mode is critical for our applications so any means of helping Teltonika devs improve that functionality and/or eliminate related bugs is extremely helpful to us and I’m sure many others!

Great work!

20

Hello,

Thanks to this post, I managed to route secondary public IPv4 hosted by devices behind a RUT241 in passthrough mode (firmware 00.07.04.5).

The last problem is the SNAT rule pushed by default by the passthrough mode :
I managed to remove it so the device behind RUT241 talks with his own public source IP address :

iptables -t nat -D postrouting_rule -o wwan0 -j SNAT --to <SIM_public_address>

But if I do that the RUT241 is not connected anymore to RMS. I tried to put a more restrictive SNAT rule applied to the br-lan local IP address but it still not works :

iptables -t nat -A postrouting_rule -s <BR_LAN_private_address> -o wwan0 -j SNAT --to <SIM_public_address>

My question is : which source IP is used by the RMS service ?

23

This fix should be already implemented I guess in the newest 7.5 series of RutOS’es but somehow Teltonika didn’t make it to include, so I guess next 7.6 RutOS should have fixed ARP problem as they know about it for at least 3-4 months. I hope I helped you with fixing issue.

25

Hello @KIT_AF,

Apologies for the delayed response.

We would like to investigate your case. Would it be possible for you to contact us through your assigned sales manager or the reseller from whom you purchased the device? If this is not feasible, kindly fill out the ‘contact us’ form here. Please, mention this forum topic and provide some details about the current situation within the form. Thank you!

Kind Regards,