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-clientN> 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. In RouterOS v7 these are named <ovpn-client1>, <ovpn-client2>, and so on (angle brackets included). 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-clientN> dynamic interface representing the session (RouterOS v7 naming)

Bridged vs Routed Mode

RouterOS OpenVPN supports two tunnel modes, selected with the mode property on the server.

Routed Mode (mode=ip)

The default and recommended mode. Each connected client receives an IP address from the PPP pool and the tunnel operates at Layer 3. The server and client exchange IP packets only — no Layer 2 frames or broadcast traffic cross the tunnel. This is the correct choice for:

• Road-warrior remote access (laptops, mobile devices connecting to the office)
• Site-to-site VPN between subnets on different routers
• Any deployment where clients need IP connectivity to a remote subnet

In routed mode, hosts on the remote LAN must have a return route pointing to the VPN server’s tunnel IP, or the server must NAT/masquerade VPN client traffic.

Bridged Mode (mode=ethernet)

Ethernet mode creates a Layer 2 tunnel — the OpenVPN interface carries Ethernet frames and can be added to a bridge. This extends a broadcast domain across the VPN, allowing clients to appear as if they are on the same physical network segment. Use cases include:

• Applications that rely on broadcast discovery (network printing, SMB browsing, ARP-dependent protocols)
• Environments where clients must have IP addresses in the same subnet as the remote LAN without additional routing configuration

Caution

RouterOS OpenVPN Ethernet mode (mode=ethernet) has significant limitations. Full Layer 2 bridging is not reliably supported in all RouterOS versions and the behaviour may differ from standard OpenVPN TAP mode. For most use cases where Layer 2 extension is needed, EoIP (Ethernet over IP) over an IPsec or WireGuard tunnel is more robust and better supported.

Ethernet mode server configuration:

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

Add the resulting <ovpn-clientN> interfaces to a bridge to extend the Layer 2 domain:

/interface bridge add name=br-lan
/interface bridge port add interface="<ovpn-client1>" bridge=br-lan
/interface bridge port add interface=ether2 bridge=br-lan

Choosing Between Modes

Consideration	Routed (mode=ip)	Bridged (mode=ethernet)
Layer	L3 (IP)	L2 (Ethernet)
Broadcast traffic	No	Yes
Routing required	Yes (static routes or NAT)	No (same subnet)
RouterOS support	Full, stable	Limited, use with caution
Recommended for	All standard VPN use	Legacy broadcast apps only

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 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

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 \
    verify-server-certificate=yes \
    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 dynamic OpenVPN server interfaces. In RouterOS v7, connected clients appear as dynamic interfaces named <ovpn-clientN>. Add them by their assigned name after they connect:

/interface list add name=ovpn
/interface list member add interface="<ovpn-client1>" 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"

Deployment Examples

Road-Warrior (Remote Access)

A road-warrior setup allows individual remote users (laptops, phones) to connect to the office network over OpenVPN. The server assigns each user a tunnel IP from a pool and can push routes and DNS settings.

Topology:

Remote user (10.99.0.10) ──── OpenVPN ────→ Office server (10.99.0.1)
                                                     │
                                             Office LAN 192.168.10.0/24

Server (office router):

# IP pool for VPN users
/ip pool add name=ovpn-pool ranges=10.99.0.10-10.99.0.200

# PPP profile — push DNS and LAN routes to clients
/ppp profile add name=ovpn-rw-profile \
    local-address=10.99.0.1 \
    remote-address=ovpn-pool \
    dns-server=192.168.10.1 \
    use-compression=no \
    use-encryption=required

# Create one PPP secret per user
/ppp secret add name=alice password=AliceStrongPass service=ovpn profile=ovpn-rw-profile
/ppp secret add name=bob   password=BobStrongPass   service=ovpn profile=ovpn-rw-profile

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

Split-tunnel — clients reach the office LAN through the VPN but use their local internet connection for all other traffic:

# Push only the office LAN route to clients (use legacy netmask notation)
/interface ovpn-server server set \
    push-routes="192.168.10.0 255.255.255.0"

Full-tunnel — all client internet traffic is routed through the office. RouterOS does not have a redirect-gateway server property; configure full-tunnel on the client side with add-default-route=yes, or push a 0.0.0.0/0 route via push-routes:

# Push a default route to clients via push-routes
/interface ovpn-server server set \
    push-routes="0.0.0.0 0.0.0.0"

# NAT so VPN clients can reach the internet via the office WAN
/ip firewall nat add chain=srcnat out-interface-list=WAN \
    src-address=10.99.0.0/24 action=masquerade \
    comment="VPN clients internet access"

Firewall rules (server):

/ip firewall filter
add chain=input protocol=udp dst-port=1194 action=accept comment="OpenVPN road-warrior"
add chain=forward in-interface-list=ovpn action=accept comment="VPN client to LAN"
add chain=forward out-interface-list=ovpn action=accept comment="LAN to VPN client"

RouterOS remote client (user laptop/router):

/interface ovpn-client add \
    name=ovpn-to-office \
    connect-to=vpn.office.example.com \
    port=1194 \
    protocol=udp \
    user=alice \
    password=AliceStrongPass \
    certificate=alice \
    verify-server-certificate=yes \
    cipher=aes256-cbc \
    auth=sha256 \
    add-default-route=no \
    disabled=no

For full-tunnel, set add-default-route=yes on the client, or use the server’s push-routes to push a default route (0.0.0.0 0.0.0.0).

---

Site-to-Site

A site-to-site setup connects two office networks permanently. One router acts as the OpenVPN server, the other as a client. Both LANs can then route traffic to each other through the tunnel.

Topology:

HQ LAN 192.168.10.0/24              Branch LAN 192.168.20.0/24
        │                                        │
  Router A (server) ──── OpenVPN ────→ Router B (client)
  WAN: 203.0.113.10              Tunnel: 10.8.1.1 ↔ 10.8.1.2

Router A — HQ (Server):

# Dedicated pool and profile for the branch tunnel
/ip pool add name=ovpn-s2s-pool ranges=10.8.1.2-10.8.1.2

/ppp profile add name=ovpn-s2s-profile \
    local-address=10.8.1.1 \
    remote-address=ovpn-s2s-pool \
    use-compression=no \
    use-encryption=required

/ppp secret add name=branch1 password=BranchStrongPass \
    service=ovpn profile=ovpn-s2s-profile

# Enable server (can share port/instance with road-warrior setup)
/interface ovpn-server server set \
    enabled=yes \
    port=1194 \
    protocol=udp \
    mode=ip \
    certificate=server \
    require-client-certificate=yes \
    auth=sha256 \
    cipher=aes256-cbc

# Route to Branch LAN via the branch tunnel IP
/ip route add dst-address=192.168.20.0/24 gateway=10.8.1.2

# Firewall: allow inter-site forwarding
/ip firewall filter
add chain=input  protocol=udp dst-port=1194 action=accept comment="OpenVPN site-to-site"
add chain=forward src-address=192.168.10.0/24 dst-address=192.168.20.0/24 action=accept comment="HQ to Branch"
add chain=forward src-address=192.168.20.0/24 dst-address=192.168.10.0/24 action=accept comment="Branch to HQ"

# NAT bypass: do NOT masquerade inter-site traffic
/ip firewall nat add chain=srcnat \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    action=accept comment="No NAT HQ to Branch" place-before=0

Router B — Branch (Client):

# Import certificates first (CA + branch client cert/key)
/certificate import file-name=cert_export_ca.crt passphrase=""
/certificate import file-name=cert_export_branch1.crt passphrase=""
/certificate import file-name=cert_export_branch1.key passphrase="export-password"

# Create the OpenVPN client interface
/interface ovpn-client add \
    name=ovpn-to-hq \
    connect-to=203.0.113.10 \
    port=1194 \
    protocol=udp \
    user=branch1 \
    password=BranchStrongPass \
    certificate=branch1 \
    verify-server-certificate=yes \
    cipher=aes256-cbc \
    auth=sha256 \
    add-default-route=no \
    disabled=no

# Route to HQ LAN via the server tunnel IP
/ip route add dst-address=192.168.10.0/24 gateway=10.8.1.1

# Firewall: allow inter-site forwarding
/ip firewall filter
add chain=forward src-address=192.168.20.0/24 dst-address=192.168.10.0/24 action=accept comment="Branch to HQ"
add chain=forward src-address=192.168.10.0/24 dst-address=192.168.20.0/24 action=accept comment="HQ to Branch"

# NAT bypass: do NOT masquerade inter-site traffic
/ip firewall nat add chain=srcnat \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    action=accept comment="No NAT Branch to HQ" place-before=0

Verify the tunnel:

# On Router A
/ppp active print
/ip route print where dst-address=192.168.20.0/24

# On Router B
/interface ovpn-client print detail
/ip route print where dst-address=192.168.10.0/24

# Ping across sites
/ping 192.168.20.1 src-address=192.168.10.1 count=5

Tip

When two sites share a single OpenVPN server instance, use one PPP secret per branch with a dedicated pool range per branch. This allows per-branch routing through the specific <ovpn-clientN> interface that corresponds to each branch’s session.

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	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
push-routes	Comma-separated list of routes to push to clients. Uses legacy netmask notation: network netmask [gateway] [metric] (e.g. 192.168.10.0 255.255.255.0)	-

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
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. Set with [find] selector: /interface ovpn-client set [find name=ovpn-to-hq] route-nopull=yes	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-client1> in RouterOS v7)
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 a dynamic <ovpn-clientN> 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 the dynamic <ovpn-clientN> interfaces (use an interface list). 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 the server to keep NAT state alive. The keepalive-timeout setting applies to the server (/interface ovpn-server server set keepalive-timeout=30); RouterOS v7 ovpn-client interfaces do not expose a separate keepalive-timeout property.

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 the server (/interface ovpn-server server); it is not available on ovpn-client interfaces — clients must use aes128-cbc or aes256-cbc

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