Flaky and unstable VPN connection with RUTX10

[JP-Rotec]

Let me explain my network setup shortly:
A FRITZ!Box 7590 that is connected to the ‘real‘ internet.
The RUTX10 (10.0.0.200) is In the local network of this fritzbox (10.0.0.1).
The local network inside the RUTX10 (10.0.3.1) has a few devices: 10.0.3.10 (PC), 10.0.3.100 (PLC), 10.0.3.101 (PLC).

My goal was to create a VPN connection so I can access the devices in the 10.0.3.* local network.

So I added the RUTX10 to RMS and created a VPN hub:

Connecting with either OpenVPN Connect or Teltonika RMS VPN sometimes works, but when it does, it is very unstable and flaky. This is an example when pinging 10.0.3.1 (RUTX10) from my remote pc:

ping 10.0.3.1 -t

Pinging 10.0.3.1 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 10.0.3.1: bytes=32 time=27ms TTL=64
Reply from 10.0.3.1: bytes=32 time=26ms TTL=64
Reply from 10.0.3.1: bytes=32 time=26ms TTL=64
Reply from 10.0.3.1: bytes=32 time=26ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 10.0.3.1: bytes=32 time=26ms TTL=64
Reply from 10.0.3.1: bytes=32 time=27ms TTL=64
Reply from 10.0.3.1: bytes=32 time=26ms TTL=64
Reply from 10.0.3.1: bytes=32 time=27ms TTL=64
Reply from 10.0.3.1: bytes=32 time=26ms TTL=64
Reply from 10.0.3.1: bytes=32 time=26ms TTL=64
Request timed out.
Request timed out.
Request timed out.

Both OpenVPN Connect and Teltonika RMS VPN keep cycling in a loop of connecting → connected (shortly) → disconnected. I’ve also never been able to ping any of the devices (10.0.3.10 for example) inside the RUTX10 local network.

What can I do to make the VPN connection stable? Are there any RUTX10 or RMS settings I should check?

[anon65719490]

Hello,

Thank you for reaching out. A couple of things to double-check:

• Do the PLCs have their default gateway set to the RUTX10 LAN IP (10.0.3.1)?
• Can these devices actually be seen in the RUTX10’s ARP table (arp -a) or at least be pinged directly from the RUTX10 itself?

If those look fine, you can also try following the suggestions provided in similar topics here:

• RMS VPN connection to 2 different devices - #3 by Martynas
• RUT241 unable to route to LAN devices through RMS - #3 by Martynas

Additionally, whenever you make changes on the RUTX or in the VPN settings for testing, it’s good practice to regenerate the client certificates for the RUTX and restart the VPN hub.

Let me know how it goes.

Best regards,

[JP-Rotec]

The devices within the RUTX10 lan are visible from the RUTX10, as can also be seen with a scan:

The masquerading mentioned in the community posts was already on because I had looked through the community before posting.

Where is the button to regenerate client certificates? I could not find it, so I assumed if I just fully recreate the RMS to RUTX10 connection the certificates are renewed.
What I did to achieve new client certificates:

• Delete the VPN Client in the RUTX10

  

• Delete the VPN hub in RMS

• Remove/detach the device completely from RMS

• Re-add the device in RMS

• Recreate the VPN hub in RMS

• Reconnect the RUTX10 to RMS

  

• Update the firewall zone settings to include the new automatically generated VPN Client

  

• Reboot the RUTX10

This solved my problem yesterday (stable connection with access to full lan), however when I got back to work this morning I got the unstable connection again.

This might be a shot in the dark, but the pc from which I am using Teltonika RMS VPN is in the same local network as the RUTX10 (10.0.0.76 and 10.0.0.200 respectively). Could that cause any problems?

Thanks in advance!

[anon65719490]

Hello,

Yes, since you are trying to utilize RMS VPN in TAP (bridged) mode while your PC and the RUTX10 are already in the same LAN subnet, this will be the main reason behind the unstable connection you are experiencing.

TAP mode in RMS VPN is currently still in the BETA stage, and at this time it is not recommended for production use due to stability issues. However, if TAP is required for your setup, you may try following the suggestions provided in the relevant thread here:

Layer 2 TAP VPN - RMS VPN HUB

Greetings, By default, the TAP interface isn’t bridged to the br-lan (LAN) interface, which prevents Layer 2 communication over the VPN tunnel. First we will need to connect to the router’s CLI, here are the instructions on how to do so: To resolve the issue, you must edit the /etc/config/network configuration file. Specifically under the br-lan device options, manually add this line list ports ‘tap+’ You can use vim editor, so execute the command vi /etc/config/network, then press Insert o…

Best regards,

[JP-Rotec]

My goal is Layer 3 communication, not Layer 2.
Other devices on 10.0.0.x don’t need to be able to access 10.0.3.x.
I just want to be able to reach the plc’s and pc’s on 10.0.3.x from my computer at 10.0.0.76. So simple pinging, remote desktopping etc.
This means my VPN hub should stay in TUN (not TAP) mode right?

Today for another short moment it worked. It’s not very smooth though.

Here’s a visual network overview in case that helps:

[anon65719490]

Hello @JP-Rotec,

Thank you for the additional clarification and provided topology. Your setup is much clearer now. The main goal is simply to reach the RUTX LAN (10.0.3.X) from the Fritzbox WAN-side network (10.0.0.X).

In this case, you don’t actually need a VPN. The same result can be achieved with simple static routing. A very similar setup was discussed and achieved in this thread here:

Two-way WAN-LAN connection

Hi, Thank you for your patience with me! I replicated the configuration, and on the WAN side, I can only access the Rut951’s web interface (LAN 192.168.113.1). I also tried another Rut951, starting from scratch, but nothing changes. I can’t reach any device connected to the LAN side (192.168.113.0). In the image I’m showing you, I’m trying to reach one of the devices with the IP address 192.168.113.101!! Hoping to resolve the issue, best regards. [Routes] [Tracert]

Basically, to achieve this, you’ll need a couple of things:

• On the Fritzbox, create a static route to destination 10.0.3.0/24 (RUTX LAN) via gateway 10.0.0.200 (RUTX10 WAN IP).
• On the RUTX10, add a static route to destination 10.0.0.0/24 (Fritzbox LAN side) via gateway 10.0.0.1 (Fritzbox LAN IP).
• In the RUTX firewall zone settings, allow forwarding from the WAN zone to the destination LAN zone:
  
  

I hope this helps or at least gives you some useful insight into your desired setup.

Best regards,

[JP-Rotec]

My setup is simply an in-house environment that looks as much as possible like the environments at our customers. At our customers sites we do not even have/want access to the main router (fritzbox in this example).

So I still think VPN is the best way to do this, it is just the instability of the connection that I am trying to improve.

[anon65719490]

Hello,

Could you let me know which VPN server location you are currently using? For stability testing, it may be worth trying to connect through a different one (e.g., Bahrain).

Additionally, could you please provide the VPN client logs from the moment this instability occurs? Also, just to mention, ensure and confirm that the VPN server’s virtual network subnet (that can be found on the VPN hub Configuration tab) differs from the actual RUTX10 subnet (10.0.3.0/24).

Best regards,

[JP-Rotec]

Thanks! Currently the VPN hub is in Germany, but I will surely test another location soon too!

This should be fine:

Is it safe to share my client logs here publicly?

[anon65719490]

@JP-Rotec

Is it safe to share my client logs here publicly?

Yes, you can safely share the RMS VPN/OpenVPN client logs publicly.

Best regards,

[JP-Rotec]

I did not know where to find the logs for the Teltonika RMS VPN application, so here are the logs from the OpenVPN Connect application where it says I connected twice. But during those connections I could not ping the devices inside the RUTX10. I could not upload .log files to your website, so here in plain text:

NOTE: I moved the RUTX10 lan network 10.0.0.x to 11.12.13.x intentionally last week.

⏎[Oct 3, 2025, 08:30:18] Frame=512/2112/512 mssfix-ctrl=1250
⏎[Oct 3, 2025, 08:30:18] EVENT: RESOLVE ⏎[Oct 3, 2025, 08:30:18] Contacting 3.69.106.81:53380 via UDP
⏎[Oct 3, 2025, 08:30:18] EVENT: WAIT ⏎[Oct 3, 2025, 08:30:18] WinCommandAgent: transmitting bypass route to 3.69.106.81
{
“host” : “3.69.106.81”,
“ipv6” : false
}

⏎[Oct 3, 2025, 08:30:18] Connecting to [3.69.106.81]:53380 (3.69.106.81) via UDP
⏎[Oct 3, 2025, 08:30:18] EVENT: CONNECTING ⏎[Oct 3, 2025, 08:30:18] Tunnel Options:V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client
⏎[Oct 3, 2025, 08:30:18] Creds: UsernameEmpty/PasswordEmpty
⏎[Oct 3, 2025, 08:30:18] Sending Peer Info:
IV_VER=3.11.3
IV_PLAT=win
IV_NCP=2
IV_TCPNL=1
IV_PROTO=8094
IV_MTU=1600
IV_CIPHERS=AES-128-CBC:AES-192-CBC:AES-256-CBC:AES-128-GCM:AES-192-GCM:AES-256-GCM:CHACHA20-POLY1305
IV_LZO=1
IV_LZO_SWAP=1
IV_LZ4=1
IV_LZ4v2=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
IV_AUTO_SESS=1
IV_GUI_VER=OCWindows_3.8.0-4528
IV_SSO=webauth,crtext
IV_BS64DL=1

⏎[Oct 3, 2025, 08:30:18] SSL Handshake: peer certificate: CN=teltonika-vpn-5QMV1dxvv9fpxwfw, 2048 bit RSA, cipher: TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

⏎[Oct 3, 2025, 08:30:18] Session is ACTIVE
⏎[Oct 3, 2025, 08:30:18] EVENT: GET_CONFIG ⏎[Oct 3, 2025, 08:30:18] Sending PUSH_REQUEST to server…
⏎[Oct 3, 2025, 08:30:18] OPTIONS:
0 [comp-lzo] [no]
1 [route] [11.12.13.0] [255.255.255.0]
2 [route] [192.168.255.0] [255.255.255.0]
3 [topology] [net30]
4 [ping] [5]
5 [ping-restart] [15]
6 [ifconfig] [192.168.255.10] [192.168.255.9]
7 [peer-id] [1]
8 [cipher] [AES-256-GCM]

⏎[Oct 3, 2025, 08:30:18] PROTOCOL OPTIONS:
key-derivation: OpenVPN PRF
compress: LZO_STUB
control channel: tls-auth enabled
data channel: cipher AES-256-GCM, peer-id 1

⏎[Oct 3, 2025, 08:30:18] EVENT: ASSIGN_IP ⏎[Oct 3, 2025, 08:30:18] CAPTURED OPTIONS:
Session Name: 3.69.106.81
Layer: OSI_LAYER_3
Remote Address: 3.69.106.81
Tunnel Addresses:
192.168.255.10/30 → 192.168.255.9 [net30]
Reroute Gateway: IPv4=0 IPv6=0 flags=[ IPv4 ]
Block IPv4: no
Block IPv6: no
Block local DNS: no
Add Routes:
11.12.13.0/24
192.168.255.0/24
Exclude Routes:

⏎[Oct 3, 2025, 08:30:18] SetupClient: transmitting tun setup list to \.\pipe\agent_ovpnconnect
{
“allow_local_dns_resolvers” : false,
“confirm_event” : “3c0f000000000000”,
“destroy_event” : “380f000000000000”,
“tun” :
{
“add_routes” :
[
{
“address” : “11.12.13.0”,
“gateway” : “”,
“ipv6” : false,
“metric” : -1,
“net30” : false,
“prefix_length” : 24
},
{
“address” : “192.168.255.0”,
“gateway” : “”,
“ipv6” : false,
“metric” : -1,
“net30” : false,
“prefix_length” : 24
}
],
“block_ipv6” : false,
“block_outside_dns” : false,
“dns_options” :
{
“from_dhcp_options” : false,
“servers” : {}
},
“layer” : 3,
“mtu” : 0,
“remote_address” :
{
“address” : “3.69.106.81”,
“ipv6” : false
},
“reroute_gw” :
{
“flags” : 256,
“ipv4” : false,
“ipv6” : false
},
“route_metric_default” : -1,
“session_name” : “3.69.106.81”,
“tunnel_address_index_ipv4” : 0,
“tunnel_address_index_ipv6” : -1,
“tunnel_addresses” :
[
{
“address” : “192.168.255.10”,
“gateway” : “192.168.255.9”,
“ipv6” : false,
“metric” : -1,
“net30” : true,
“prefix_length” : 30
}
]
},
“tun_type” : 0
}
POST np://[\.\pipe\agent_ovpnconnect]/tun-setup : 200 OK
TAP ADAPTERS:
guid=‘{37EFCFE4-D992-4DA3-90B6-F8A70A0073A6}’ index=9 name=‘Local Area Connection’
Open TAP device “Local Area Connection” PATH=“\.\Global{37EFCFE4-D992-4DA3-90B6-F8A70A0073A6}.tap” SUCCEEDED
TAP-Windows Driver Version 9.27
ActionDeleteAllRoutesOnInterface iface_index=9
netsh interface ip set interface 9 metric=9000
Ok.
netsh interface ip set address 9 static 192.168.255.10 255.255.255.252 gateway=192.168.255.9 store=active
IPHelper: add route 11.12.13.0/24 9 192.168.255.9 metric=-1
IPHelper: add route 192.168.255.0/24 9 192.168.255.9 metric=-1
NRPT::ActionCreate pid=[13092] domains= dns_servers= dnssec=[0] id=[OpenVPNDNSRouting-13092]
DNS::ActionCreate interface name=[Local Area Connection] search domains=
DNS::ActionApply: successful
ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
TAP: ARP flush succeeded
TAP handle: 0c09000000000000
⏎[Oct 3, 2025, 08:30:18] Connected via TUN_WIN
⏎[Oct 3, 2025, 08:30:18] LZO-ASYM init swap=0 asym=1
⏎[Oct 3, 2025, 08:30:18] Comp-stub init swap=0
⏎[Oct 3, 2025, 08:30:18] EVENT: CONNECTED 3.69.106.81:53380 (3.69.106.81) via /UDP on TUN_WIN/192.168.255.10/ gw=[192.168.255.9/] mtu=(default)⏎[Oct 3, 2025, 08:31:11] SetupClient: signaling tun destroy event
⏎[Oct 3, 2025, 08:31:11] EVENT: DISCONNECTED ⏎[Oct 3, 2025, 08:32:20] OpenVPN core 3.11.3 win x86_64 64-bit OVPN-DCO built on Sep 16 2025 15:58:53
⏎[Oct 3, 2025, 08:32:20] Frame=512/2112/512 mssfix-ctrl=1250
⏎[Oct 3, 2025, 08:32:20] EVENT: RESOLVE ⏎[Oct 3, 2025, 08:32:20] Contacting 3.69.106.81:53380 via UDP
⏎[Oct 3, 2025, 08:32:20] EVENT: WAIT ⏎[Oct 3, 2025, 08:32:20] WinCommandAgent: transmitting bypass route to 3.69.106.81
{
“host” : “3.69.106.81”,
“ipv6” : false
}

⏎[Oct 3, 2025, 08:32:20] Connecting to [3.69.106.81]:53380 (3.69.106.81) via UDP
⏎[Oct 3, 2025, 08:32:20] EVENT: CONNECTING ⏎[Oct 3, 2025, 08:32:20] Tunnel Options:V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client
⏎[Oct 3, 2025, 08:32:20] Creds: UsernameEmpty/PasswordEmpty
⏎[Oct 3, 2025, 08:32:20] Sending Peer Info:
IV_VER=3.11.3
IV_PLAT=win
IV_NCP=2
IV_TCPNL=1
IV_PROTO=8094
IV_MTU=1600
IV_CIPHERS=AES-128-CBC:AES-192-CBC:AES-256-CBC:AES-128-GCM:AES-192-GCM:AES-256-GCM:CHACHA20-POLY1305
IV_LZO=1
IV_LZO_SWAP=1
IV_LZ4=1
IV_LZ4v2=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
IV_AUTO_SESS=1
IV_GUI_VER=OCWindows_3.8.0-4528
IV_SSO=webauth,crtext
IV_BS64DL=1

⏎[Oct 3, 2025, 08:32:20] SSL Handshake: peer certificate: CN=teltonika-vpn-5QMV1dxvv9fpxwfw, 2048 bit RSA, cipher: TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

⏎[Oct 3, 2025, 08:32:20] Session is ACTIVE
⏎[Oct 3, 2025, 08:32:20] EVENT: GET_CONFIG ⏎[Oct 3, 2025, 08:32:20] Sending PUSH_REQUEST to server…
⏎[Oct 3, 2025, 08:32:20] OPTIONS:
0 [comp-lzo] [no]
1 [route] [11.12.13.0] [255.255.255.0]
2 [route] [192.168.255.0] [255.255.255.0]
3 [topology] [net30]
4 [ping] [5]
5 [ping-restart] [15]
6 [ifconfig] [192.168.255.10] [192.168.255.9]
7 [peer-id] [2]
8 [cipher] [AES-256-GCM]

⏎[Oct 3, 2025, 08:32:20] PROTOCOL OPTIONS:
key-derivation: OpenVPN PRF
compress: LZO_STUB
control channel: tls-auth enabled
data channel: cipher AES-256-GCM, peer-id 2

⏎[Oct 3, 2025, 08:32:20] EVENT: ASSIGN_IP ⏎[Oct 3, 2025, 08:32:20] CAPTURED OPTIONS:
Session Name: 3.69.106.81
Layer: OSI_LAYER_3
Remote Address: 3.69.106.81
Tunnel Addresses:
192.168.255.10/30 → 192.168.255.9 [net30]
Reroute Gateway: IPv4=0 IPv6=0 flags=[ IPv4 ]
Block IPv4: no
Block IPv6: no
Block local DNS: no
Add Routes:
11.12.13.0/24
192.168.255.0/24
Exclude Routes:

⏎[Oct 3, 2025, 08:32:21] SetupClient: transmitting tun setup list to \.\pipe\agent_ovpnconnect
{
“allow_local_dns_resolvers” : false,
“confirm_event” : “240f000000000000”,
“destroy_event” : “280f000000000000”,
“tun” :
{
“add_routes” :
[
{
“address” : “11.12.13.0”,
“gateway” : “”,
“ipv6” : false,
“metric” : -1,
“net30” : false,
“prefix_length” : 24
},
{
“address” : “192.168.255.0”,
“gateway” : “”,
“ipv6” : false,
“metric” : -1,
“net30” : false,
“prefix_length” : 24
}
],
“block_ipv6” : false,
“block_outside_dns” : false,
“dns_options” :
{
“from_dhcp_options” : false,
“servers” : {}
},
“layer” : 3,
“mtu” : 0,
“remote_address” :
{
“address” : “3.69.106.81”,
“ipv6” : false
},
“reroute_gw” :
{
“flags” : 256,
“ipv4” : false,
“ipv6” : false
},
“route_metric_default” : -1,
“session_name” : “3.69.106.81”,
“tunnel_address_index_ipv4” : 0,
“tunnel_address_index_ipv6” : -1,
“tunnel_addresses” :
[
{
“address” : “192.168.255.10”,
“gateway” : “192.168.255.9”,
“ipv6” : false,
“metric” : -1,
“net30” : true,
“prefix_length” : 30
}
]
},
“tun_type” : 0
}
POST np://[\.\pipe\agent_ovpnconnect]/tun-setup : 200 OK
TAP ADAPTERS:
guid=‘{37EFCFE4-D992-4DA3-90B6-F8A70A0073A6}’ index=9 name=‘Local Area Connection’
Open TAP device “Local Area Connection” PATH=“\.\Global{37EFCFE4-D992-4DA3-90B6-F8A70A0073A6}.tap” SUCCEEDED
TAP-Windows Driver Version 9.27
ActionDeleteAllRoutesOnInterface iface_index=9
netsh interface ip set interface 9 metric=9000
Ok.
netsh interface ip set address 9 static 192.168.255.10 255.255.255.252 gateway=192.168.255.9 store=active
IPHelper: add route 11.12.13.0/24 9 192.168.255.9 metric=-1
IPHelper: add route 192.168.255.0/24 9 192.168.255.9 metric=-1
NRPT::ActionCreate pid=[13092] domains= dns_servers= dnssec=[0] id=[OpenVPNDNSRouting-13092]
DNS::ActionCreate interface name=[Local Area Connection] search domains=
DNS::ActionApply: successful
ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
TAP: ARP flush succeeded
TAP handle: 6c0f000000000000
⏎[Oct 3, 2025, 08:32:21] Connected via TUN_WIN
⏎[Oct 3, 2025, 08:32:21] LZO-ASYM init swap=0 asym=1
⏎[Oct 3, 2025, 08:32:21] Comp-stub init swap=0
⏎[Oct 3, 2025, 08:32:21] EVENT: CONNECTED 3.69.106.81:53380 (3.69.106.81) via /UDP on TUN_WIN/192.168.255.10/ gw=[192.168.255.9/] mtu=(default)⏎[Oct 3, 2025, 08:32:52] SetupClient: signaling tun destroy event
⏎[Oct 3, 2025, 08:32:52] EVENT: DISCONNECTED ⏎

[anon65719490]

Hello @JP-Rotec,

Thank you for your update and provided logs. In this case, to assist in troubleshooting and investigating this matter with the unstable RMS VPN connection effectively, we’ll need to continue this process privately, because sensitive/publicly non-shareable information, such as the troubleshoot file, logs, configurations, etc., needs to be collected.

You should find a support request form in the inbox of the email address you used for your forum registration. Kindly fill out the form, and please reference Ticket ID: 15642 when submitting it. Once the form is completed, we’ll contact you directly via email to investigate the issue in detail and help work towards a solution.

Best regards,

[JP-Rotec]

I’ll probably continue with the private support Monday, because today is a busy day for me.

Maybe this helps too:

Yesterday I also created a new VPN Hub in Germany and it worked and I could ping the inner devices.
This morning, after the issues mentioned in the posts above, I created a new VPN Hub in Bahrain instead of Germany and I could ping the inner devices.
Then to be sure I also created a new VPN Hub in Germany this morning and I could not ping the inner devices.

Could there be something wrong with the Germany VPN system?
I just wanted to state this so people with similar issues can try another VPN Hub location.

[JP-Rotec]

Germany VPN Hubs are still not fixed. Fow now, using Bahrain is te best alternative if you can live with 200ms delay/ping.