RUT200, VPN hub, route issue not connecting

Networking Solutions
1

I’m facing a persistent issue that I haven’t been able to resolve. I’m using an RUT200 router and I want to connect to it via an RMS VPN Hub. In the Hub, I’ve added a route pointing to an IP address in the router’s LAN (10.0.0.100), where a Modbus device is located.

The problem is that the setup works inconsistently.

When the VPN connection (Teltonika RMS VPN) is established, sometimes the route is successfully pushed into the client machine’s routing table, but other times it isn’t. Even when the route appears, I still can’t ping the target device, nor access port 502 on that IP. Occasionally the connection works flawlessly for a long period, but then suddenly stops without any clear reason.

So far, I have tried the following without success:

  • Recreated the VPN Hub multiple times and restarted it

  • Tested with several different routers (same issue)

  • Tested with firmwares 07.16.3 and 07.17.1

  • Enabled LAN forwarding in RMS Hub for the route

  • Verified that both Client and Device appear under Sessions

What would be the best way to start troubleshooting this?

2

Right after writing the message, it suddenly started working again. Nothing was changed. The connection had been up for about 24 minutes when it began to work.

4

Hello,

Thank you for your latest update. Could you please let me know if you noticed any connection drops during this period since your last comment until now?

If the described issue occurs again, please let me know so we can troubleshoot it further and gather the necessary logs privately.

Best regards,

5

Maybe I notice a little repetition. It seems that when the connection is finally established (it can take 10s or 30min), then it stays up just fine (Teltonika VPN client)

I tried it on three different machines to be sure and it all happened in the same way. In all the experiments I used Teltonika’s VPN client.

When I ping the device at the end of the route, there are sometimes a lot of drop-outs and the response takes a long time. When it works well, the ping is clearly shorter and 100% throughput. So the VPN connection seems to stay up, but the throughput of messages is significantly reduced.

Oh and just for information, when i ping from router’s CLI it works flawlessness avg ~1ms (— 10.0.0.100 ping statistics — 104 packets transmitted, 104 packets received, 0% packet loss
round-trip min/avg/max = 0.612/0.912/5.225 ms) so most likely not a LAN issue.

Now of course the question arises whether this only happens through the Teltonika VPN program. It is really good in terms of usability, but of course it is still in the beta phase.

Router settings are pretty much default, except static ip for routed device. VPN hub is set in Germany.

6

I had time to look router’s openvpn logs. There are few points to notice. I am not that familier with your VPN system, but let see if this open some ideas:

-repeated “TLS key negotiation failed” and “TLS handshake failed” messages, followed by “SIGUSR1[soft,tls-error]” restarts.
→The router seem to chnage between two server IPs (3.69.106.81 and 3.65.167.143); one of them seems to fail more often. (i hope these are you ips :wink:

Even when the tunnel is established successfully (“Initialization Sequence Completed”), it often disconnects after 2–3 minutes with “Inactivity timeout (–ping-restart)”, mayby keepalive packets are not passing through all the time?

7

Well, maybe I’ll find more tips. At the moment the connection is stable and the ping from the remote machine is on average less than 100ms without packet drops.(when the connection is bad, the ping avg is almost a second and there are a lot of drops)

So it works perfectly atm. I haven’t compared the time/log, but at least at the moment the connection: 3.69.106.81:36997 seems to work completely stable. So will the problem occur when peer connection is initiated for 3.65.167.143, even though they now seem to point to the same AWS cluster?

….Continued from the previous:

Indeed, when I looked through the log, every time it’s 3.65.167.143, there are errors in the log and no errors when 3.69.106.81

Of course, some kind of work-around would be to force it to a single IP address in the profile, but I don’t know if that would work with Teltonika’s VPN program.

…And now the problems start again, and here is some briefing from log

12:51-13:4 VPN tunnel was stable and running normally.

13:43 First error:

(UDPv4: Network unreachable (fd=5,code=128))

WAN uplink or routing dropped, causing the VPN session to break.

13:49-4:47: Multiple TLS handshakes and certificate verifications occurred, no “Initialization Sequence Completed” entry. → not a stable tunnel.

14:47 Another handshake sequence started, but again no successful initialization is logged.

15:17 Clear success

(Peer Connection Initiated with [AF_INET]3.69.106.81:36997
Initialization Sequence Completed)

So, the VPN was stable until 13:43, then there was a clear outage between 13:43 and 15:17, with repeated unsuccessful connection attempts. The session recovered successfully at 15:17 when it connected to server 3.69.106.81.

Now after last sequence complete, ping is fast & no drops and connection is stable. Teltonika app uptime is now 4h20min.

8

Because this problem became interesting now, I dug into more logs :wink:

13:43, the WAN/VPN connection dropped. Looking at the logs, it wasn’t a random network issue. The router shows that the admin user logged into the web interface and changed the network configuration(and obviously i was not that who did this). That triggered a service reload (mobifd), which then forced the mob1s1a1 (mobile WAN) interface to stop and reconnect.

So basically, the disconnection was caused by a manual config change from the web UI, not by the LTE network itself and i was not in the webview that time, or neither i did any changes.

…so a very liberal idea. Is there a process triggered via RMS that causes this?

Oh and after this log fest, most likely problem has nothing to do with AWS ip’s

9

Hello,

Thank you for your update and digging deeper into logs.

If the logs show that the admin user accessed the WebUI, they should also include the IP address of the session, which can help determine whether this was done by a known user or not.

To clarify, RMS service cannot trigger mobile connection restarts or restart the mobifd service. These actions would have had to be performed manually by someone with access to the device.

If possible, could you share that part of the system logs here (with any private or sensitive data hidden)? From what you’ve described, the mobifd service restart should be the primary reason why the RMS VPN connection was disrupted.

Best regards,

10

This topic was automatically closed after 60 days. New replies are no longer allowed.