FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
263 views 1 comments
by anonymous
Situation:

We run a lot of RUT240 on mobile with VPN client connecting to our VPN server. The RUT240 have ping reboot functionality activated, it pings our internal VPN server adress that is only reachable when the VPN tunnel is connected.

The idea behind this is to let the router do automatical reboot after it failed to establish a VPN tunnel. This solved connectivity issues we had in the past. It's a workaround another problem, because sometimes the VPN does not connect and then we either have to reboot or disable the VPN profile by hand via a technician on site and activate it again. So we worked around this bug with ping reboot. We were told a few years ago to configure the ping reboot as "PING from mobile", as it failed when we used "automatically selected".

When we set it as "automatically selected", the ping reboot does not work. The VPN connection fails and until we restart the device on site by hand, never comes back.

Now since version 14.5 we noticed that the bug is still there, so we naturally selected "PING from mobile" again. However, now it seems that nothing works. It looks like that now "PING from mobile" literally uses the mobile WAN interface directly. Obviously, the internal VPN server IP is not reachable via mobile wan. Therefor, now all these routers reboot every 90 minutes even though the VPN connection is online and stable.

When we do a manual ping via SSH or the webinterface, it can ping our VPN server. Only ping reboot does not.

We solved it by discarding ping reboot and now reboot daily via automatic reboot. We ask to fix the ping reboot so it either works correctly weith "automatically selected" or, like in the past, notices that the IP to be pinged has to be routed to the tun interface. This was the case before the latest updates.

Currently ping reboot is unusable for our situation. We run over 600 routers and it's becoming arduous. This is all just a workaround another bug in the firmware. Very often we have to just flag and unflag VPN profile to make it work again. "Just" in brackets, because we have to send a technician several hundred kilometers on site to do that.

Please either fix the VPN tunnel hangup problem or ping reboot to route into tun interface like it did before.

1 Answer

0 votes
by anonymous

Hello,

Thank you for the detailed report.

I would like to know if the issue is reproducible with the latest legacy and RUT2XX_R_00.01.14.6 and RutOS RUT2_R_00.07.02.7 firmware versions?

What VPN is used in your environment?

It would be very helpful if you provided troubleshoot files from devices with the above firmwares, after the issue has occurred, so that it would be visible in the logs. This would make it easier to replicate, investigate and report it to the development team.

To generate troubleshoot files, access router's WebUI, go to System -> Administration > Troubleshoot section and download troubleshoot file from there. 

Best regards,

by anonymous
We will run a test on two different routers and try to reproduce the error.

However, setting up this, I ran into another problem, I unpacked a brand new router, it takes a long time to boot and when I access the overview page, there are no values/variables filled, only "-" is shown. I downgraded from 14.6 to 14.5 hoping it would resolve this issue but it does not.

On every reboot the wizzard keeps injecting itself into the login process as if there's a problem with the flash.