Remote Access, Site-to-Site VPNs and RMS VPN Explained
OpenVPN appears in the specifications of most Teltonika industrial routers.
That sounds straightforward enough. You open RutOS, go to Services → VPN → OpenVPN, create a client or server and configure it.
But that skips the important question:
What are you actually trying to achieve with it?
If you have a Teltonika router connected to a PLC in a factory, an IP camera on a remote site or an industrial controller inside a roadside cabinet, OpenVPN can provide a secure route to that equipment across the Internet.
It can also connect an entire remote network back to a central office, connect a Teltonika router to somebody else’s corporate VPN infrastructure, or form part of a much larger network containing hundreds of remote sites.
And then there is Teltonika RMS VPN, which uses the same broad concept of secure VPN connectivity but removes much of the work involved in operating the VPN infrastructure yourself.
These are different ways of solving related problems.
This guide explains what OpenVPN does on a Teltonika router, the common ways it is deployed, how the traffic actually gets from your laptop to a remote device, where RMS VPN fits into the picture, and some of the problems that repeatedly catch people out.
What Is OpenVPN?
OpenVPN is an open-source VPN technology used to create encrypted network connections across untrusted networks such as the Internet.
At its simplest, imagine an engineer standing beside a PLC.
They connect their laptop to the local network:
Engineering laptop → Ethernet → PLC
The PLC might have an address such as:
192.168.10.50
The engineer opens their programming or management software and connects to that address.
Now move the engineer 200 miles away.
The physical Ethernet connection no longer exists.
OpenVPN can provide a secure virtual network path between the engineer and the remote network:
Engineering laptop → Internet → OpenVPN tunnel → Teltonika router → PLC
The PLC can still be 192.168.10.50.
The difference is that traffic destined for that network is now routed through an encrypted VPN tunnel.
That makes OpenVPN useful for applications including:
- remote PLC programming and diagnostics
- CCTV and IP camera access
- HMI maintenance
- building management systems
- industrial controllers
- remote PCs and servers
- renewable energy installations
- telemetry equipment
- vending and kiosk systems
- machine builders providing remote support
- remote access to an entire industrial LAN.
The VPN is effectively creating a private route across a public network.
But that last word — route — is important.
A working VPN connection does not automatically mean every device behind the router will be reachable.
We’ll come back to that.
The Main Ways to Use OpenVPN on a Teltonika Router
There isn’t one standard “Teltonika OpenVPN setup”.
There are several fundamentally different network designs.
Understanding which one you need is more important than knowing which boxes to tick in RutOS.
1. Teltonika as an OpenVPN Client
One of the most common industrial configurations is for the Teltonika router to act as an OpenVPN client.
The architecture might be:
PLC / HMI / Controller
↓
Teltonika Router
↓
4G / 5G / Ethernet Internet connection
↓
OpenVPN Server
↓
Company Network
The router initiates the VPN connection to a server elsewhere.
That server could be:
- at the company’s head office
- inside a data centre
- running in AWS, Azure or another cloud
- hosted on a VPS
- an OpenVPN Access Server
- part of an existing corporate VPN infrastructure.
This architecture is particularly useful with cellular routers.
Why?
Because the connection starts from the router and travels outwards.
A normal mobile broadband SIM will often sit behind Carrier Grade NAT, or CGNAT. The Teltonika can access the Internet, but devices on the Internet cannot necessarily initiate connections directly back to it.
An outbound OpenVPN connection avoids that problem.
The router establishes the tunnel to a known server and keeps that connection available.
This is one reason client-based VPN architectures are so common in IoT.
2. Teltonika as an OpenVPN Server
You can turn the arrangement around.
The Teltonika router can itself operate as the OpenVPN server:
Engineer laptop
↓
Internet
↓
Teltonika OpenVPN Server
↓
Local LAN
↓
PLC
This can be a perfectly good solution for individual sites or relatively small deployments.
There is an important catch.
The OpenVPN server must be reachable.
If your Teltonika is using a normal cellular SIM behind CGNAT, an engineer on the Internet usually cannot simply initiate a connection to it.
You may therefore require a suitable public IP SIM/APN or another Internet connection that provides inbound reachability.
If the public IP is dynamic rather than static, Dynamic DNS can potentially provide a hostname that follows changes to the router’s Internet address.
This is why “does the RUT241 support OpenVPN server?” isn’t quite the right question.
It does.
The next question is:
Can anybody actually reach that server from the Internet?
3. Site-to-Site OpenVPN
OpenVPN can also join networks rather than simply connecting an individual engineer.
Imagine two locations.
Factory
192.168.10.0/24
↓
Teltonika Router A
↓
OpenVPN tunnel
↓
Teltonika Router B
↓
192.168.20.0/24
Office
Devices on one network can then be routed to devices on the other.
This can be useful where an organisation has multiple:
- factories
- renewable energy sites
- utility installations
- temporary locations
- control systems
- buildings
- CCTV networks
- remote machines.
Instead of somebody manually starting a VPN whenever access is required, the routers can maintain the VPN between the sites.
This creates an important network-design consideration.
Don’t Give Every Site the Same LAN Address
Imagine you have 100 machines.
Every installer leaves the Teltonika on:
192.168.1.0/24
Eventually you want to bring all 100 sites into the same VPN infrastructure.
You now have 100 different networks all claiming to contain:
192.168.1.50
Which one does the VPN route traffic to?
This is why IP addressing needs to be considered when designing a large remote-access estate rather than after it has been deployed.
Something as mundane as the LAN subnet can determine how easily the system scales later.
OpenVPN Doesn’t Require Teltonika at Both Ends
This is an important advantage.
OpenVPN is not a proprietary Teltonika-to-Teltonika protocol.
A Teltonika router can connect to other OpenVPN infrastructure.
For example:
Teltonika → OpenVPN → Linux Server
Teltonika → OpenVPN → OpenVPN Access Server
Teltonika → OpenVPN → MikroTik
Teltonika → OpenVPN → Corporate VPN Infrastructure
That makes it useful when an industrial router is being installed into a network controlled by somebody else’s IT department.
Rather than adopting another remote-access platform, the IT department may provide the installer with its existing OpenVPN configuration.
Teltonika provides worked examples for both OpenVPN Access Server and connections involving MikroTik equipment.
Using an .OVPN Configuration File
If you have used OpenVPN before, you may already have encountered an:
.ovpn
file.
An administrator can provide a pre-built OpenVPN client configuration containing the information required to connect to their server.
Instead of manually recreating all of those settings in RutOS, the configuration can be imported.
On current RutOS versions, OpenVPN is generally found under:
Services → VPN → OpenVPN
A client instance can then be created and configured using the supplied OpenVPN configuration file.
Depending on the VPN implementation, additional certificates, keys or authentication credentials may also be required.
This is useful when an organisation tells an installer:
“Here is our OpenVPN configuration. Connect the router to our VPN.”
The Teltonika doesn’t need to be the centre of the VPN architecture.
It becomes another VPN endpoint.
TUN and TAP: What’s the Difference?
OpenVPN documentation quickly introduces two terms:
TUN
and:
TAP
They refer to different types of virtual network interface.
TUN — Routed VPN
TUN operates at Layer 3.
In practical terms, you are routing IP traffic between networks.
For example:
VPN network: 10.8.0.0/24
and:
Remote industrial LAN: 192.168.10.0/24
The router knows that traffic destined for 192.168.10.0/24 needs to go to the remote site.
For most normal remote-access and IoT VPN applications, this is the arrangement to consider first.
TAP — Bridged VPN
TAP operates at Layer 2.
Rather than simply routing IP packets between separate networks, it can extend Ethernet-level connectivity across the VPN.
There are situations where that is useful, particularly where software or legacy equipment depends on broadcasts or Layer-2 behaviour.
But it also introduces additional traffic and complexity.
Don’t assume that bridging two networks together is automatically better than routing between them.
For most modern remote-access applications, routed networks are cleaner and easier to control.
TCP or UDP?
OpenVPN can operate using either TCP or UDP.
A traditional OpenVPN configuration commonly uses:
UDP port 1194
although neither the protocol nor port is mandatory.
UDP is generally the preferred starting point because VPN traffic doesn’t normally need another TCP reliability layer wrapped around applications that may already use TCP.
TCP can still be useful where firewalls or network policies restrict UDP connectivity.
The choice should therefore be based on the networks through which the VPN needs to operate rather than simply changing TCP/UDP when something doesn’t work.
Certificates and Authentication
OpenVPN supports several authentication methods and RutOS exposes a range of configuration options depending on device and firmware.
Modern OpenVPN deployments commonly use TLS certificates.
You may therefore encounter:
CA Certificate
The Certificate Authority used to establish which certificates should be trusted.
Server Certificate
Identifies the OpenVPN server.
Client Certificate
Identifies a client connecting to the VPN.
Private Key
The secret cryptographic key associated with a certificate.
These allow the endpoints to verify who they are talking to and establish encrypted sessions.
This is considerably stronger than simply exposing an administration interface to the public Internet and protecting it with a password.
The private keys, however, really are private.
Treat OpenVPN configuration files and credentials as security-sensitive material.
What Actually Happens When You Connect to a Remote PLC?
This is the part that makes VPN troubleshooting considerably easier to understand.
Suppose your engineering laptop receives the VPN address:
10.8.0.10
The remote PLC is:
192.168.10.50
You open your software and connect to:
192.168.10.50
Your laptop needs a route telling it:
192.168.10.0/24 → VPN
The packet travels through the encrypted tunnel and reaches the Teltonika.
The Teltonika then forwards it onto its LAN.
So far, so good.
The PLC receives a packet from:
10.8.0.10
and now needs to reply.
And that is where many installations fail.
The Return Route Problem
The PLC asks:
“Where is 10.8.0.10?”
It isn’t on the PLC’s local network.
So the PLC sends the reply to its configured default gateway.
If that gateway is the Teltonika, the router can return the traffic through the VPN.
But what if the PLC has:
no default gateway?
Or its gateway points at:
another router?
The incoming VPN packet may successfully reach the PLC while the response never finds its way back.
The result looks like a VPN problem.
But the VPN may be working perfectly.
This issue repeatedly appears in Teltonika’s own support community.
Why Masquerading Can Fix It
A common solution mentioned by Teltonika support is masquerading.
Masquerading is a form of Source NAT.
Instead of forwarding:
10.8.0.10 → PLC
unchanged, the Teltonika changes the source address.
The PLC effectively sees:
Teltonika LAN IP → PLC
The PLC therefore believes the request originated from its own local network and replies directly to the Teltonika.
The router remembers the NAT translation and returns the response to the correct VPN client.
This can be extremely useful with PLCs and other industrial equipment that:
- have no configurable default gateway
- have limited routing capabilities
- expect management traffic to originate locally
- cannot easily have their existing network configuration changed.
A recent Teltonika Community example involved a RUT142 and Siemens PLC where cameras and printers communicated correctly but the PLC did not. Enabling the appropriate masquerading configuration solved the problem.
Teltonika support explained that the likely problem was the PLC’s return route. Source NAT made the VPN traffic appear to originate from the RUT142’s LAN address, allowing the PLC to reply correctly.
That is a much better explanation than simply saying:
“Tick masquerading.”
A VPN Connection Does Not Mean LAN Access Is Working
This is probably the most important troubleshooting lesson in this entire guide.
You can have:
OpenVPN: Connected
while still being completely unable to reach:
192.168.10.50
The VPN tunnel is only part of the journey.
Think about the path:
Laptop
↓
VPN tunnel
↓
Teltonika VPN interface
↓
Firewall
↓
LAN
↓
PLC
↓
Return route
↓
Teltonika
↓
VPN
↓
Laptop
Every stage has to work.
That means troubleshooting should be systematic rather than changing random OpenVPN settings.
Teltonika OpenVPN Troubleshooting
Here is a useful order to work through.
1. Does the Teltonika Have Internet Access?
Start with the obvious.
If the router cannot access the Internet, the VPN isn’t the problem.
Check cellular/WAN connectivity first.
2. Can the OpenVPN Client Reach the Server?
Check:
- server address
- DNS
- port
- TCP/UDP
- firewall
- public IP reachability.
3. Is the VPN Actually Connected?
Check the OpenVPN status and system logs in RutOS.
A successful connection normally produces a virtual VPN interface and assigned VPN addressing.
4. Can You Reach the Router Through the VPN?
This separates the VPN itself from the LAN behind it.
If you can communicate with the Teltonika over the VPN, you have already proved a substantial part of the system.
5. Is There a Route to the Remote LAN?
If the remote network is:
192.168.10.0/24
the VPN client needs to know that this network is reached through the tunnel.
RMS VPN has the same fundamental requirement: routes are added for networks or endpoints behind the Teltonika.
6. Is VPN-to-LAN Forwarding Allowed?
The Teltonika firewall still applies.
Traffic arriving on the VPN interface needs permission to reach the LAN.
7. Does the PLC Have the Correct Gateway?
If the PLC needs to reply to another subnet, its gateway needs to know how to reach it.
Often this should be the Teltonika LAN address.
8. Would Masquerading Solve the Return Path?
If the end device cannot be given the appropriate gateway or route, Source NAT may provide a practical alternative.
9. Are Any Networks Overlapping?
This catches people surprisingly often.
Your laptop might currently be on:
192.168.1.0/24
while the remote factory also uses:
192.168.1.0/24
Now your laptop has two possible interpretations of:
192.168.1.50
Local device?
Or remote VPN device?
Avoid overlapping networks wherever possible.
10. Test the Actual Application
Ping is useful.
It isn’t definitive.
ICMP can be blocked while the application you actually need still works.
Conversely, a PLC may respond to ping while the programming software still cannot automatically discover it.
Test the required port and application as well.
Why TIA Portal Can Be Particularly Confusing
Siemens PLC access provides a good example of why Layer 2 versus Layer 3 matters.
A Teltonika Community user could access a Siemens S7-1500 through RMS VPN but encountered problems with automatic discovery.
Teltonika support pointed out that RMS VPN was providing a Layer-3 tunnel.
TIA Portal may therefore not automatically discover the PLC in the same way it would when the engineering laptop is physically connected to the same Ethernet network.
The PLC can instead need to be accessed directly by specifying its IP address.
This distinction matters with industrial software.
“The discovery tool can’t see the PLC”
does not necessarily mean:
“The VPN cannot reach the PLC.”
Try direct IP connectivity before redesigning the VPN.
What Is Teltonika RMS VPN?
At this point you might reasonably wonder why you would build all of this yourself.
That is where Teltonika RMS VPN comes in.
RMS stands for Remote Management System.
RMS provides a cloud-based platform for monitoring, configuring and remotely accessing supported Teltonika equipment.
RMS VPN extends that idea to network connectivity.
Instead of operating your own OpenVPN server, certificates and associated infrastructure, you can create an RMS VPN environment and connect authorised users and Teltonika devices to it.
The basic architecture becomes:
Engineering Laptop
↓
RMS VPN
↓
Teltonika Router
↓
PLC / HMI / Camera / Controller
The engineer can then access the remote equipment through the VPN.
Importantly, RMS VPN is not limited to accessing the router’s own WebUI.
Routes can be created to equipment connected behind the router.
This is what makes it particularly useful for industrial support.
RMS VPN Hub
An RMS VPN Hub creates a central VPN environment for multiple devices and users.
Imagine a machine builder has installations at 50 customer sites.
Each site contains:
Teltonika router → PLC → HMI
Those routers can be added to an RMS VPN Hub.
Routes can then be created to the equipment behind them.
Authorised engineers can connect to the Hub and reach the appropriate equipment.
Teltonika’s documentation specifically describes RMS VPN being used for remote access to PLCs and HMIs in manufacturing environments.
The documentation also shows LAN-to-LAN configurations where equipment behind two different Teltonika routers can communicate through the VPN Hub.
That starts to turn RMS VPN from a remote-support tool into actual network infrastructure.
OpenVPN Is Still Visible Inside RMS VPN
There is an interesting crossover here.
RMS VPN hides much of the complexity of creating and managing the VPN infrastructure, but OpenVPN hasn’t disappeared.
RMS allows an .ovpn configuration to be downloaded for a VPN Hub.
That configuration can then be imported into compatible OpenVPN client software.
So an engineer can connect using:
Teltonika RMS VPN App
or potentially:
OpenVPN client + downloaded RMS .ovpn configuration
This is why you will sometimes see OpenVPN interfaces and terminology when troubleshooting RMS VPN connections.
RMS is managing the service, but underneath it you are still dealing with familiar VPN networking concepts such as clients, routes, interfaces and firewall zones.
RMS VPN Quick Connect
Teltonika also provides RMS Quick Connect.
Quick Connect sits somewhere between conventional RMS Remote Access and a full RMS VPN Hub.
It allows a VPN network to be created quickly for access to equipment behind a Teltonika router.
Teltonika describes one of its advantages over ordinary Remote Access as the ability to add third-party devices using .ovpn files, while being quicker to configure than a full VPN Hub.
That makes it particularly interesting for temporary engineering access.
For example:
Engineer needs PLC access for today’s maintenance visit
rather than:
Company wants a permanent VPN architecture connecting 200 industrial sites.
Those are different requirements and don’t necessarily need the same solution.
OpenVPN vs RMS VPN: Which Should You Use?
There isn’t a universal answer.
It depends on who owns the infrastructure and what you are trying to achieve.
Use Your Own OpenVPN Infrastructure When:
The organisation already operates OpenVPN.
The customer’s IT department controls VPN access.
You have mixed router manufacturers.
You need complete control over authentication and routing.
You want infrastructure independent of Teltonika RMS.
You are building a permanent site-to-site architecture.
You already have the expertise to operate and secure the VPN service.
Consider RMS VPN When:
You primarily use Teltonika routers.
You want straightforward engineer-to-device remote access.
You don’t want to operate VPN servers yourself.
You need access to PLCs, HMIs, cameras and other devices behind remote routers.
You want central management of multiple sites.
You want to get engineers connected quickly.
Consider RMS Quick Connect When:
The requirement is temporary or occasional.
You need straightforward access to a particular remote endpoint.
You don’t need a permanently running full VPN Hub.
What About WireGuard?
OpenVPN isn’t Teltonika’s only VPN option.
RutOS also supports other technologies on applicable devices, including WireGuard, IPsec and additional VPN/networking services.
WireGuard has become particularly popular because of its relatively simple architecture and modern cryptography.
For a completely new privately controlled VPN deployment, it deserves consideration.
But OpenVPN still has a major advantage:
it is everywhere.
Corporate networks already use it.
Cloud VPN services support it.
Linux supports it.
Windows and macOS clients are readily available.
Network administrators understand it.
And there is an enormous installed base.
If a customer hands you an .ovpn file and says:
“Connect your router to this.”
the fact that the Teltonika supports OpenVPN is extremely useful.
OpenVPN vs RMS Remote Access
It is also worth distinguishing RMS VPN from ordinary RMS Remote Access.
If you simply need to open the Teltonika WebUI remotely, or reach a supported web interface on a device behind it, RMS Remote Access may already solve the problem.
You don’t necessarily need a full VPN.
A VPN becomes more useful when the engineer’s computer needs genuine IP connectivity to the remote equipment.
For example:
Browser → remote web interface
may be adequately handled by remote access.
But:
TIA Portal → Siemens PLC
or:
Engineering software → industrial controller
may require actual network-level connectivity.
Choose the simplest tool that solves the requirement.
Security: A VPN Is Not Permission to Ignore the Firewall
A VPN encrypts communication.
It does not automatically make everything behind it safe.
Avoid creating:
VPN user → unrestricted access to entire industrial LAN
unless that is genuinely required.
Consider:
- which users need access
- which sites they should reach
- which devices they should reach
- which ports/services are required
- how credentials and certificates are stored
- how access is revoked
- whether VPN logs are monitored
- how router firmware is maintained.
An external maintenance contractor who needs TCP access to one PLC doesn’t necessarily need access to every camera, HMI and controller on the same network.
Remote access should be designed around the principle of giving people the connectivity they actually require.
Designing OpenVPN into an IoT Deployment
The best time to think about remote access is before the equipment leaves the workshop.
For every remote site, document:
Router LAN address
Example:
192.168.40.1
Remote device addresses
PLC — 192.168.40.10
HMI — 192.168.40.20
Camera — 192.168.40.30
Default gateway
Usually the Teltonika where appropriate.
VPN network
Ensure it doesn’t overlap with LAN networks.
Who needs access?
Engineering, support, customer IT, third-party contractor?
What access do they need?
Entire subnet or specific endpoints?
How will the router reach the Internet?
Fixed Ethernet, 4G, 5G, multi-network SIM?
Who owns the VPN infrastructure?
Your organisation, customer IT, Teltonika RMS or another provider?
Do that before deploying 500 routers and life becomes considerably easier.
Useful Teltonika OpenVPN Configuration Guides
This article is intended to explain the architecture rather than reproduce Teltonika’s configuration documentation.
For the actual RutOS settings, the Teltonika Networks Wiki should be your starting point.
Useful Teltonika resources include:
OpenVPN configuration
The VPN section of the Wiki for your specific router provides the available OpenVPN client and server settings. Always use the documentation corresponding to your router and RutOS version.
Uploading an OpenVPN .ovpn file
Teltonika provides a dedicated configuration tutorial for importing existing OpenVPN configuration files into RutOS.
OpenVPN Access Server
There is a worked Teltonika example showing how to create an OpenVPN Access Server and connect a Teltonika router as a client.
Teltonika and MikroTik OpenVPN
Teltonika also provides a configuration example showing an OpenVPN tunnel between Teltonika and MikroTik equipment.
RMS VPN Hubs
The RMS Wiki explains how to create a VPN Hub, add Teltonika devices and users, configure routes, enable LAN forwarding and download an .ovpn configuration.
RMS Quick Connect
The Quick Connect documentation explains the faster temporary/endpoint-oriented RMS VPN option.
Common Questions
Can I use OpenVPN with a Teltonika 4G or 5G router?
Yes. This is one of its common industrial applications.
If the Teltonika acts as an OpenVPN client, it can normally establish the outbound VPN across a standard Internet connection, including cellular services operating behind CGNAT.
Running the Teltonika as an Internet-accessible OpenVPN server may require an appropriate publicly reachable IP service.
Do I need a static IP SIM?
Not necessarily.
An OpenVPN client can initiate a connection through ordinary Internet connectivity.
A static public IP becomes more relevant when something on the Internet needs to initiate a connection directly towards the router.
Can OpenVPN access a PLC behind the Teltonika?
Yes, provided routing, firewall forwarding and the return path are configured correctly.
The PLC’s default gateway is particularly important. Masquerading can also help where the PLC cannot route traffic back to the VPN network.
Why can I access my Teltonika but not the PLC?
This is one of the most common problems.
If the router itself is reachable, the VPN is probably functioning.
Check:
- route to the PLC network
- LAN forwarding
- Teltonika firewall
- PLC subnet mask
- PLC default gateway
- masquerading/NAT
- overlapping subnets.
Why can’t TIA Portal discover my Siemens PLC?
Automatic discovery may rely on local-network behaviour that doesn’t traverse a routed Layer-3 VPN.
If IP connectivity exists, try connecting directly to the PLC’s known IP address.
Can I use OpenVPN Connect with RMS VPN?
Yes. Teltonika’s RMS VPN Hub documentation allows an .ovpn configuration to be downloaded and imported into an OpenVPN client. Teltonika also provides its own RMS VPN application.
Is RMS VPN the same as configuring OpenVPN on the router?
No.
A conventional OpenVPN client/server configuration and an RMS VPN Hub are different architectures.
RMS provides and manages the VPN environment for you. A normal RutOS OpenVPN client can instead connect the router to VPN infrastructure operated by you or another organisation.
The Important Question Isn’t “Does It Support OpenVPN?”
Most modern Teltonika industrial routers support several VPN technologies.
That is the easy part.
The useful questions are:
What device are you trying to reach?
Where is the person or system connecting from?
Which end should initiate the VPN?
Does either side need a public IP address?
Who controls the VPN server?
Which network sits behind the Teltonika?
Does the end device have the correct gateway?
Should the remote user reach one device or an entire network?
Do you want to operate the VPN infrastructure yourself?
Once those questions are answered, choosing between an OpenVPN client, OpenVPN server, site-to-site VPN or RMS VPN becomes much easier.
And when a Teltonika says:
OpenVPN — Connected
but your PLC remains stubbornly unreachable, don’t immediately blame the VPN.
Follow the packet.
Laptop → VPN → router → firewall → LAN → PLC.
Then follow the reply all the way back.
More often than not, that’s where you’ll find the problem.