OpenVPN

OpenVPN

OpenVPN provides a flexible, TLS-based VPN solution in RouterOS suitable for remote access and site-to-site connectivity. RouterOS implements OpenVPN as a PPP-based interface, with the server managing client address assignment through IP pools and PPP secrets. The protocol uses X.509 certificates for mutual authentication, making it well-suited for environments requiring strong identity verification.

RouterOS supports OpenVPN over both TCP and UDP transport, with a range of cipher and HMAC options to match security policy requirements. UDP transport (available since RouterOS v7.4) is the preferred choice for performance-sensitive deployments; TCP transport is useful when UDP is blocked by intermediate firewalls. Certificate management is handled entirely within RouterOS using the built-in /certificate subsystem, eliminating the need for an external CA.

Summary

The RouterOS OpenVPN implementation differs from the upstream OpenVPN community model in several ways. The server creates a dynamic ovpn-incomingN interface for each connected client, allowing per-client firewall rules and routing. Clients authenticate using both a certificate and a PPP username/password pair. Address assignment uses standard RouterOS IP pools and PPP profiles.

OpenVPN in RouterOS operates at Layer 3 (IP mode) by default. Each connected client receives an IP address from the pool defined in the PPP profile, and the server side of the tunnel is fixed at the local-address specified in the same profile.

Feature	Value
Default port	1194
Default transport	UDP (v7.4+), TCP (v6/older v7)
Authentication	Certificate + PPP credentials
Encryption	AES-128-CBC, AES-256-CBC, AES-256-GCM (v7+)
UDP transport available since	RouterOS v7.4
Sub-menu	/interface ovpn-server, /interface ovpn-client

How OpenVPN Works

TLS Authentication Model

OpenVPN uses TLS for the control channel, which carries key exchange and authentication. The data channel uses a symmetric cipher negotiated during the TLS handshake. In RouterOS, both server and client present X.509 certificates issued by a common CA. This provides mutual authentication — the server verifies the client certificate and the client verifies the server certificate against the same CA.

The RouterOS implementation uses a certificate plus PPP credentials model. After TLS handshake and certificate verification succeed, the client must also supply a valid PPP username and password. This two-factor approach means a compromised certificate alone is insufficient for access.

Interface and Address Model

When a client connects to the OpenVPN server, RouterOS creates a dynamic interface named ovpn-incoming1, ovpn-incoming2, and so on. These interfaces appear in /interface print and can be referenced in firewall rules and routing. The server-side IP address for each tunnel comes from the PPP profile’s local-address, while the client receives an address from the remote-address pool.

Server (10.8.0.1) ←──── TLS/PPP ────→ Client (10.8.0.2)
                    ovpn-incoming1

Packet Flow

1. Client initiates TCP (or UDP) connection to server on port 1194
2. TLS handshake: both sides present certificates, verify against CA
3. PPP negotiation: client supplies username and password
4. Server assigns IP from pool; client configures assigned address
5. Data traffic flows through the encrypted tunnel interface
6. Server creates ovpn-incomingN interface representing the session

Configuration

Certificate and PKI Setup

All certificates are managed in /certificate. Create a CA first, then sign server and client certificates from it. Each certificate requires a signing step that generates the private key on the router.

Create the Certificate Authority:

/certificate
add name=ca-template common-name="OpenVPN CA" days-valid=3650 \
    key-size=2048 key-usage=key-cert-sign,crl-sign
sign ca-template ca=ca-template name=ca

Create and sign the server certificate:

/certificate
add name=server-template common-name="ovpn-server" days-valid=3650 \
    key-size=2048 key-usage=digital-signature,key-encipherment,tls-server
sign server-template ca=ca name=server

Create and sign a client certificate:

/certificate
add name=client1-template common-name="client1" days-valid=3650 \
    key-size=2048 key-usage=digital-signature,key-encipherment,tls-client
sign client1-template ca=ca name=client1

Export certificates for distribution to clients:

/certificate export-certificate ca export-passphrase=""
/certificate export-certificate client1 export-passphrase="export-password"

Exported files appear in the router’s file system (cert_export_ca.crt, cert_export_client1.crt, cert_export_client1.key). Download them via WinBox Files or FTP.

Server Configuration

Create an IP pool for client addresses:

/ip pool add name=ovpn-pool ranges=10.8.0.2-10.8.0.254

Create a PPP profile for OpenVPN clients:

/ppp profile add name=ovpn-profile \
    local-address=10.8.0.1 \
    remote-address=ovpn-pool \
    dns-server=8.8.8.8 \
    use-compression=no \
    use-encryption=required

Add PPP secrets (one per client):

/ppp secret add name=client1 password=StrongPassword1 \
    profile=ovpn-profile service=ovpn

Enable the OpenVPN server:

/interface ovpn-server server set \
    enabled=yes \
    port=1194 \
    mode=ip \
    protocol=tcp \
    certificate=server \
    require-client-certificate=yes \
    auth=sha256 \
    cipher=aes256-cbc \
    max-mtu=1500

UDP Transport

UDP transport avoids the TCP-over-TCP problem inherent in running OpenVPN over TCP, improving throughput and reducing latency on lossy or high-latency links. UDP mode requires RouterOS v7.4 or later.

Enable UDP on the server:

/interface ovpn-server server set \
    enabled=yes \
    port=1194 \
    protocol=udp \
    certificate=server \
    require-client-certificate=yes \
    auth=sha256 \
    cipher=aes256-cbc \
    keepalive-timeout=30

Firewall rule for UDP (replace protocol=tcp with protocol=udp):

/ip firewall filter
add chain=input protocol=udp dst-port=1194 action=accept comment="OpenVPN UDP server"

MTU and MSS tuning for UDP paths:

UDP encapsulation adds overhead (IP + UDP + OpenVPN headers ≈ 50–60 bytes). With a 1500-byte upstream MTU the tunnel payload must be smaller to avoid fragmentation. Set tunnel MTU conservatively and clamp TCP MSS to prevent Black Hole routing issues:

/interface ovpn-server server set max-mtu=1420

/ip firewall mangle
add chain=forward action=change-mss new-mss=1380 protocol=tcp tcp-flags=syn \
    out-interface-list=ovpn tcp-mss=1381-65535 comment="Clamp MSS for OVPN UDP"
add chain=forward action=change-mss new-mss=1380 protocol=tcp tcp-flags=syn \
    in-interface-list=ovpn tcp-mss=1381-65535 comment="Clamp MSS return for OVPN UDP"

Start with max-mtu=1420 and reduce if fragmentation symptoms persist (test with ping size=1400 do-not-fragment).

NAT traversal:

UDP OpenVPN works through NAT, but stateful firewalls and NAT devices time out UDP sessions that are idle. The keepalive-timeout setting on the server (and client) controls how often keepalive packets are sent. Reduce it from the default 60 seconds to 30 seconds when clients sit behind aggressive NAT:

/interface ovpn-server server set keepalive-timeout=30
/interface ovpn-client set [find] keepalive-timeout=30

Client Configuration (RouterOS)

To connect a RouterOS device as an OpenVPN client, import the CA certificate and client certificate/key first, then create the client interface.

Import certificates on the client router:

/certificate import file-name=cert_export_ca.crt passphrase=""
/certificate import file-name=cert_export_client1.crt passphrase=""
/certificate import file-name=cert_export_client1.key passphrase="export-password"

Create the OpenVPN client interface:

/interface ovpn-client add \
    name=ovpn-to-hq \
    connect-to=vpn.example.com \
    port=1194 \
    protocol=udp \
    user=client1 \
    password=StrongPassword1 \
    certificate=client1 \
    ca-certificate=ca \
    cipher=aes256-cbc \
    auth=sha256 \
    add-default-route=no \
    disabled=no

Use protocol=tcp if the server runs on TCP or if UDP is blocked by the network path.

Set add-default-route=yes to route all client traffic through the tunnel. Leave it no for split-tunnel setups and add specific routes manually.

Add a route to the remote network:

/ip route add dst-address=192.168.1.0/24 gateway=ovpn-to-hq

Client Configuration (OpenVPN Client App)

For non-RouterOS clients (Windows, Linux, macOS, Android, iOS), generate a .ovpn configuration file. Place the exported CA cert, client cert, and client key into the file:

client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA256
cipher AES-256-CBC
; RouterOS does not support LZO compression or NCP (cipher negotiation)
; Do NOT add: comp-lzo or ncp-ciphers
ncp-disable
verb 3

<ca>
-----BEGIN CERTIFICATE-----
... (paste ca.crt contents) ...
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
... (paste client1.crt contents) ...
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
... (paste client1.key contents) ...
-----END PRIVATE KEY-----
</key>

Use proto tcp if the server is configured for TCP. RouterOS does not support comp-lzo (LZO compression) or NCP cipher negotiation — both must be explicitly disabled on the client side.

Firewall Rules

Allow incoming OpenVPN connections on the server and permit forwarded tunnel traffic. Add the rule matching your transport protocol:

/ip firewall filter
# For UDP transport (v7.4+, recommended)
add chain=input protocol=udp dst-port=1194 action=accept comment="OpenVPN UDP server"
# For TCP transport
add chain=input protocol=tcp dst-port=1194 action=accept comment="OpenVPN TCP server"
add chain=forward in-interface-list=ovpn action=accept comment="OpenVPN tunnel traffic"
add chain=forward out-interface-list=ovpn action=accept comment="OpenVPN return traffic"

Create an interface list to group all ovpn-incoming* interfaces:

/interface list add name=ovpn
/interface list member add interface=ovpn-incoming1 list=ovpn

For NAT masquerading so VPN clients can reach the internet:

/ip firewall nat add chain=srcnat out-interface=ether1 \
    src-address=10.8.0.0/24 action=masquerade \
    comment="Masquerade OpenVPN clients"

Properties

Server Properties

/interface ovpn-server server

Property	Description	Default
enabled	Enable the OpenVPN server	no
port	TCP/UDP port to listen on	1194
mode	Tunnel mode: ip (layer 3) or ethernet (layer 2)	ip
protocol	Transport protocol: tcp or udp	tcp
certificate	Server certificate name from /certificate	none
require-client-certificate	Verify client certificate against CA	no
auth	HMAC algorithm: md5, sha1, sha256, sha512, none	sha1
cipher	Data cipher: aes128-cbc, aes256-cbc, blowfish128	aes128-cbc
max-mtu	Maximum MTU for tunnel interfaces	1500
keepalive-timeout	Seconds before dropping an inactive session	60
default-profile	PPP profile applied to all clients	default
redirect-gateway	Push default route to clients	no

Client Properties

/interface ovpn-client

Property	Description	Default
name	Interface name	-
connect-to	Server hostname or IP address	-
port	Server port	1194
protocol	Transport: tcp or udp	tcp
user	PPP username	-
password	PPP password	-
certificate	Client certificate name	none
ca-certificate	CA certificate for server verification	none
cipher	Data cipher	aes128-cbc
auth	HMAC algorithm	sha1
add-default-route	Install a default route via tunnel	no
route-nopull	Ignore routes pushed by server	no
disabled	Interface disabled state	yes

Active Session Properties

/interface ovpn-server print shows dynamically created sessions:

Field	Description
name	Auto-assigned interface name (e.g., ovpn-incoming1)
user	PPP username of the connected client
remote-address	IP address assigned to the client
encoding	Active cipher and auth combination
uptime	Duration of the current session

Troubleshooting

Verify Server Status

/interface ovpn-server print

An active session shows an ovpn-incoming* interface. If no sessions appear after a client connects, check certificates and credentials.

Check Client Connection Status

/interface ovpn-client print detail

The status field shows the connection state. Common states:

Status	Meaning
connected	Tunnel established and active
connecting	Attempting to reach server
disconnected	Not connected, no active retry
error	Connection failed — check logs

Check Logs

/log print where topics~"ovpn"
/log print where topics~"ppp"

Common log messages:

Log Message	Cause
certificate verification failed	CA mismatch or expired certificate
could not verify peer certificate	Client certificate not signed by expected CA
login incorrect	Wrong PPP username or password
no encryption	Cipher mismatch between client and server
unknown service	PPP secret service field not set to ovpn

Common Issues

Client connects but cannot reach LAN hosts: Verify that chain=forward firewall rules accept traffic from ovpn-incoming* interfaces. Check that a route to the client subnet exists on LAN hosts, or that NAT masquerade is configured.

Certificate verification fails: Ensure the CA certificate used to sign the server certificate is the same CA imported on the client. Re-export and re-import certificates if in doubt. Verify certificate dates with /certificate print detail.

PPP authentication fails: Confirm the PPP secret service=ovpn is set. The default service=any also works but service=ppp does not match OpenVPN.

MTU-related packet drops: Lower max-mtu on the server and client. For UDP transport, start with 1420 and reduce by 20-byte increments until packet loss stops. For TCP transport, 1400 is a safe starting point. Apply MSS clamping via firewall mangle (change-mss to new-mss=1380) for TCP connections traversing the tunnel.

UDP tunnel drops after idle period: Intermediate NAT devices time out UDP sessions that are idle. Reduce keepalive-timeout to 30 seconds on both server and client to keep NAT state alive. If using RouterOS as the client, set keepalive-timeout=30 on the ovpn-client interface.

UDP mode not available: UDP transport requires RouterOS v7.4 or later. Check your version with /system resource print and upgrade if needed. On older RouterOS, use TCP (protocol=tcp) instead.

Client uses LZO compression or NCP: RouterOS does not support LZO compression or NCP cipher negotiation. Third-party clients (OpenVPN 2.4+) enable NCP by default. Add ncp-disable and remove comp-lzo from the client .ovpn file. Without this, the handshake succeeds but the tunnel carries no traffic.

Debugging

Enable verbose OpenVPN logging:

/system logging add topics=ovpn,ppp action=memory

Monitor active connections and their assigned addresses:

/ppp active print

Security Considerations

Certificate management:

• Set a short expiry (1–2 years) for client certificates and rotate them regularly
• Revoke certificates immediately when a user leaves or a device is lost
• Use unique certificates per client — do not share a single client certificate across devices
• RouterOS does not implement CRL checking automatically; revoke access by removing the PPP secret

Cipher and hash selection:

• Prefer aes256-cbc with sha256 for new deployments
• Avoid blowfish128 and md5 — both are considered weak
• RouterOS 7.x supports aes256-gcm on some builds; check /interface ovpn-server server for available ciphers

Access control:

• Restrict which source IPs can reach port 1194 with a firewall input rule if the server is not intended for public access
• Use strong, unique passwords for PPP secrets — certificate alone is not sufficient if require-client-certificate=no

Protocol considerations:

• TCP OpenVPN over TCP exhibits poor performance (TCP-over-TCP problem); prefer UDP transport (v7.4+) for all new deployments
• UDP mode requires firewall rules allowing UDP/1194 rather than TCP/1194
• RouterOS does not support LZO compression (comp-lzo) or NCP cipher negotiation — explicitly disable both on third-party clients

See Also

• WireGuard — Modern, higher-performance VPN alternative
• PPPoE — Layer 2 tunneling for ISP access
• Certificate Management — RouterOS PKI and certificate operations
• PPP Profiles and Secrets — PPP configuration reference