RadSec Issues After RouterOS 7.15 Upgrade

RadSec Issues After RouterOS 7.15 Upgrade

Overview

RouterOS 7.15 introduced a regression in RadSec (RADIUS over TLS, RFC 6614) that causes RADIUS replies to be silently discarded. The RADIUS server sends a valid Access-Accept, Access-Challenge, or Access-Reject — the packet arrives at the router and is visible in Wireshark — but RouterOS reports a timeout and authentication fails.

This bug is present in all RouterOS releases from 7.15 through at least 7.18 (as of early 2026) and affects all services that use RadSec: dot1x, Hotspot, PPP, VPN, and wireless authentication.

Root cause: RouterOS 7.15 added a require-message-auth option that enforces the presence of a Message-Authenticator attribute in RADIUS replies. A related bug causes RouterOS to drop RadSec replies even when a valid Message-Authenticator is present — meaning the reply passes the server’s TLS layer and arrives at the router, but is then discarded internally.

Setting require-message-auth=no resolves the issue only if the RADIUS server does not include Message-Authenticator in its replies. On most modern FreeRADIUS deployments the server always includes it, so require-message-auth=no does not help.

Stable workarounds:

• Downgrade to RouterOS 7.14.3
• Fall back to UDP RADIUS (port 1812/1813) while the bug is unresolved

Prerequisites

• RouterOS 7.15 or later (regression present from 7.15 through 7.18+)
• A working RadSec configuration that functioned correctly on 7.14.3 or earlier
• Access to the RADIUS server logs to confirm replies are being sent
• Wireshark or packet capture capability on the router to confirm packet arrival

Configuration

A correct RadSec server entry for dot1x (as it worked on 7.14.3):

/radius add \
    address=192.168.0.1 \
    certificate=radius_client \
    protocol=radsec \
    require-message-auth=no \
    service=wireless,dot1x \
    timeout=10s

Key parameters relevant to this regression:

Parameter	Notes
protocol=radsec	Switches transport from UDP to TLS/TCP (port 2083)
require-message-auth	Added in 7.15. Set to no to disable enforcement. Mitigates the issue only when the RADIUS server does not include Message-Authenticator in replies.
certificate	Client certificate name from /certificate; required when the RADIUS server enforces mutual TLS
timeout	Default 300 ms is too short for TLS handshake; use 3s–10s

Port: RadSec uses TCP 2083. Ensure outbound TCP 2083 is permitted in /ip firewall filter rules and that the RADIUS server is listening on this port.

Verification

Use these commands to confirm that the problem is the 7.15 regression and not a configuration or network issue:

# Check system time — TLS certificate validation requires accurate time
/system clock print
/system ntp client print

# Review the RADIUS entry
/radius print detail

# Enable radius and account debug logging, then trigger an auth attempt
/system logging add topics=radius,debug action=memory
/system logging add topics=account,debug action=memory

# Watch logs during an auth attempt
/log print follow where message~"radsec|radius|tls|timeout"

Expected symptom of the 7.15 regression:

radius,debug new request xx:xx code=Access-Request service=dot1x ...
radius,debug sending xx:xx to 192.168.0.1:2083
radius,debug timeout for xx:xx

The RADIUS server log will show the reply was sent (e.g. Sent Access-Accept) at the same timestamp. The router received the packet (a simultaneous Wireshark capture will show it arriving) but discarded it internally.

# Confirm outbound TCP 2083 is not blocked
/ip firewall filter print where dst-port=2083
/ip firewall connection print where dst-port=2083

# Check certificate trust if also troubleshooting TLS handshake failures
/certificate print detail where trusted=yes

Troubleshooting

Step 1 — Confirm the RADIUS server is sending replies

Check the RADIUS server log during an authentication attempt. If the server log shows Sent Access-Accept (or Sent Access-Challenge) but RouterOS shows a timeout, the bug is the 7.15 regression, not a server or network problem.

If the server log shows no reply, the problem is upstream (routing, firewall, or RADIUS policy) and unrelated to the 7.15 regression.

Step 2 — Try require-message-auth=no

/radius set [find where address="192.168.0.1"] require-message-auth=no

Re-trigger an authentication attempt. This resolves the issue only if your RADIUS server does not include Message-Authenticator in replies. FreeRADIUS 3.x and later always includes it by default, so this may not help.

Step 3 — Fall back to UDP RADIUS to restore service

While the bug is unresolved, switch to classic RADIUS UDP so authentication continues:

/radius set [find where address="192.168.0.1"] protocol=udp

If UDP authentication succeeds, this confirms the issue is the RadSec regression and not a shared-secret or policy problem. RouterOS automatically uses the default UDP RADIUS ports when you switch the entry to protocol=udp, so you do not need to set a separate port value here. Revert to protocol=radsec once a fixed RouterOS version is available.

Security note: UDP RADIUS sends the RADIUS shared secret over an unencrypted transport. If the RADIUS server is not on a trusted local network, protect the traffic with an IPsec tunnel or restrict the path to a management VLAN.

Step 4 — Downgrade to RouterOS 7.14.3

If falling back to UDP is not acceptable, downgrade the RouterOS package set to 7.14.3:

# Check current version
/system package print

# Check for available updates (may not list 7.14.3 directly; use manual download)
/system package update check-for-updates

Download the 7.14.3 .npk files for your hardware architecture from the MikroTik download page, upload them to the router, and reboot:

# After uploading .npk files via FTP or Winbox Files
/system reboot

RouterOS downgrades by installing the uploaded package files on next boot. Confirm the version after reboot:

/system resource print

Step 5 — Open a support ticket

MikroTik has confirmed awareness of this bug (support tickets SUP-155235 and SUP-168690 were filed by community members). Filing additional tickets increases priority:

https://help.mikrotik.com/servicedesk/customer/portal/1

Include your RouterOS version, hardware model, and a description of the symptom (replies visible in RADIUS server log and Wireshark but router reports timeout).

Unrelated issues that share the same symptom

Some operators reporting timeout errors after 7.15 had unrelated configuration problems:

• Missing Message-Authenticator enforcement on Windows NPS: Windows NPS may not include Message-Authenticator in replies by default. With require-message-auth=yes (the 7.15 default), NPS replies are dropped. Set require-message-auth=no or configure NPS to include the attribute.
• Certificate trust not set: If the CA certificate in /certificate has trusted=no, the TLS handshake fails before any RADIUS exchange. Set trusted=yes on the CA.
• Clock skew: If the system clock is more than a few minutes off, TLS certificate validation fails. Verify NTP is working with /system ntp client print.

See Also

• RADIUS Client — /radius configuration, service-specific AAA, and standard RADIUS troubleshooting
• dot1x — 802.1X port authentication configuration
• RADIUS Accounting and CoA — Change of Authorization and Disconnect Messages