+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблемы с Radsec после обновления до версии 7.15

Проблемы с Radsec после обновления до версии 7.15, RouterOS

JulienPicalausa

Guest

02.06.2024 18:46:00

Всем привет. Я новичок на этих форумах и постараюсь не выглядеть идиотом. Зарегистрировался здесь после того, как столкнулся с проблемой после обновления до 7.15. Раньше мне удалось настроить рабочую dot1x с freeradius. У меня несколько коммутаторов Mikrotik, которые подключаются к нему по radsec. Сегодня обновил один из этих коммутаторов, CRS312-4C+8XG, до 7.15, и что-то сломалось в коммуникации. TLS рукопожатие проходит как обычно, потом отправляется и принимается первый Access-Request от freeradius. Но независимо от того, какой ответ приходит обратно, коммутатор, похоже, его не видит. Временно исправил это, перейдя на незащищённое соединение. Поскольку не видел, чтобы кто-то жаловался на похожую проблему, решил написать, вдруг это коснётся и других.

Некоторые важные кусочки моей конфигурации:

# 2024-06-02 20:37:52 by RouterOS 7.15
# software id = H9BC-RUMQ
#
# model = CRS312-4C+8XG

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

/interface dot1x server
add auth-types=dot1x,mac-auth interface=dot1x radius-mac-format=XX-XX-XX-XX-XX-XX

/interface list
add name=dot1x

/interface list member
add interface=ether4 list=dot1x
add interface=ether5 list=dot1x
add interface=ether6 list=dot1x
add interface=ether7 list=dot1x
add interface=ether3 list=dot1x
add interface=ether2 list=dot1x
add interface=combo1 list=dot1x
add interface=combo2 list=dot1x
add interface=combo3 list=dot1x
add interface=combo4 list=dot1x
add interface=ether8 list=dot1x

Некоторые важные фрагменты лога:

17:12:10 dot1x,packet s ether3 rx EAPOL-Start
17:12:10 dot1x,packet s ether3 tx EAPOL-Packet EAP-Request id:0 method:IDENTITY
17:12:10 radius,debug new request 82:09 code=Access-Request service=dot1x called-id=12-34-56-78-90-AB
17:12:10 radius,debug sending 82:09 to 192.168.0.1:2083
17:12:10 radius,debug,packet sending Access-Request with id 2 to 192.168.0.1:2083
17:12:10 radius,debug,packet Signature = *************
17:12:10 radius,debug,packet Framed-MTU = 1400
17:12:10 radius,debug,packet NAS-Port-Type = 15
17:12:10 radius,debug,packet Called-Station-Id = "12-34-56-78-90-AB"
17:12:10 radius,debug,packet Calling-Station-Id = "FE-DC-BA-09-87-65"
17:12:10 radius,debug,packet Service-Type = 2
17:12:10 radius,debug,packet EAP-Message = 0x0200000a017661726469
17:12:10 radius,debug,packet User-Name = "host"
17:12:10 radius,debug,packet Acct-Session-Id = "86300003"
17:12:10 radius,debug,packet NAS-Port-Id = "ether3"
17:12:10 radius,debug,packet Unknown-Attribute(type=102) = 0x00
17:12:10 radius,debug,packet NAS-Identifier = "nas"
17:12:10 radius,debug,packet NAS-IP-Address = 192.168.0.2
17:12:10 radius,debug,packet Message-Authenticator = ************
17:12:10 dot1x,packet s ether3 rx EAPOL-Packet EAP-Response id:0 method:IDENTITY
17:12:20 radius,debug timeout for 82:09

Конфигурация и логи были немного сокращены.

MartinW

Guest

17.06.2024 20:46:00

В моём случае это оказалось ошибкой пользователя (с моей стороны). Я не заметил этих строк в примечаниях к релизу: ) radius - добавлена опция «require-message-auth», требующая «Message-Authenticator» в полученных сообщениях Access-Accept/Challenge/Reject; ) radius - включать «Message-Authenticator» во всех RADIUS-сообщениях, кроме учёта для всех сервисов; …установка «require-message-auth = no» решила проблему (для меня). Понимаю, что это не та же самая проблема, с которой столкнулся автор топика (ведь он уже установил этот атрибут).

fuhry

Guest

06.07.2024 18:30:00

Могу подтвердить, что radsec в версии 7.15 абсолютно непригоден к использованию. Проблема возникает независимо от настройки «require-message-auth». RouterOS выдает тайм-аут RADIUS при включенном radsec, из-за чего складывается впечатление, что код, отвечающий за проверку наличия message authenticator, просто отклоняет все полученные ответы radsec. Пока что проблема решается возвратом к UDP с общими ключами, но это, конечно, куда менее безопасно. Пожалуйста, исправьте это!

JulienPicalausa Guest	#4 0 11.07.2024 08:56:00 Учитывая эту новую уязвимость Blast radius, было бы здорово, если бы radsec работал…

bluecrow76

Guest

12.07.2024 15:30:00

6 июня я отправил запрос в службу поддержки Mikrotik по этой проблеме (SUP-155235). Он до сих пор находится в статусе «Ожидание поддержки» и никаких комментариев не было. Довольно удивительно, что такая важная функция инфраструктуры и безопасности остаётся без внимания так долго, особенно учитывая, что после этого было выпущено две мелкие обновления.

sergdous

Guest

10.08.2024 18:35:00

Всем привет, я новичок на этом форуме, надеюсь, у вас всё хорошо. У меня была такая же проблема: сообщение «AUTH_FAILED». Моя конфигурация: CRS354-48G-4S+2Q+: 7.15.3 с сервером opvn, аутентификация через Radius на Windows Server 2022 с сервисом IAS, клиент Windows 10 с OpenVPN GUI v11.49.0.0.

Однажды, после обновления до 7.15.3, VPN-соединения перестали работать, на клиенте Windows в OpenVPN GUI появилось сообщение: «Неправильные данные для входа», в логе: «…AUTH_FAILED…». В логах Windows NPS сервера указано, что клиент авторизован. В статусе Mikrotik Radius сервера: Requests: 1, Accept: 1, Timeout: 4 !! Bad replies: 10 !! Все остальные показатели: 0.

Пошаговое понижение версии с 7.15.3 до 7.14.3 — и OpenVPN снова работает. В статусе Mikrotik Radius сервера стало: Requests: 2, Accept: 2, Timeout: 0, Bad replies: 0, остальные показатели: 0.

В чём может быть проблема? Заранее спасибо. Пока что никаких обновлений не делаю!

fuhry Guest	#7 0 12.11.2024 23:14:00 Для информации, могу подтвердить, что эта регрессия всё ещё присутствует в RouterOS 7.17-beta4. Я также создал заявку в службу поддержки, но по ней пока нет никакой реакции.

vlpl

Guest

20.01.2025 15:32:00

Я тоже на это наткнулся. Radius-сервер сообщает, что отправил Access-Challenge. Отладка: (0) Отправлен Access-Challenge Id 36 с 0.0.0.0:2083 на 172.18.0.1:63258, длина 80.
Отладка: (0) EAP-Message = 0x010200160410e403eeccdc5ea411ed46ab4e4735f02b
Отладка: (0) Message-Authenticator = 0x00000000000000000000000000000000
Отладка: (0) State = 0x895b9ee189599ab998a29c329d297855

Router OS в логах пишет, что соединение было прервано по таймауту, require-message-auth = no — не помогает. Логи ещё и сбивают с толку, говорят, что radsec-запрос идет на порт 8968. Пожалуйста, исправьте это.

aglabs

Guest

20.01.2025 17:46:00

Я тоже уже завёл запрос по этому поводу (жду ответа уже две недели). Со стороны Freeradius вижу, что первый Access-Challenge остаётся без ответа:
radiusd:60366:1736548197.362852:Fri Jan 10 14:29:57 2025: Fri Jan 10 14:29:57 2025 : Debug: (6) Sent Access-Challenge Id 16 from 0.0.0.0:2083 to 172.18.96.1:49559 length 64
radiusd:60366:1736548197.362875:Fri Jan 10 14:29:57 2025: Fri Jan 10 14:29:57 2025 : Debug: (6) EAP-Message = 0x010200061920
radiusd:60366:1736548197.362897:Fri Jan 10 14:29:57 2025: Fri Jan 10 14:29:57 2025 : Debug: (6) Message-Authenticator = 0x00000000000000000000000000000000
radiusd:60366:1736548197.362920:Fri Jan 10 14:29:57 2025: Fri Jan 10 14:29:57 2025 : Debug: (6) State = 0x05b269d605b070e56f176b1c6a5cb5cb

После того как на стороне Mikrotik срабатывает таймаут, eapol-сессия прерывается из-за этого таймаута. Если тестировать с Cisco/Meraki/Ubiquiti/Ruckus, radsec работает с текущей конфигурацией freeradius без проблем, как и ожидалось. Также я проверил — откат на radsec версии 7.14 снова решает проблему. Переключение параметра require-message-auth никакого эффекта не даёт.

checkwire

Guest

#10

03.02.2025 12:53:00

Проблемы с RADIUS в Mikrotik при использовании TekRADIUS. Моя конфигурация работала отлично больше десяти лет, но обновление выше версии 7.14.3 ломает всю реализацию. RADIUS-ответы, которые просто дают авторизацию, работают... Но RADIUS-ответы с FRAMED-IP-ADDRESS или ROUTE, прикреплёнными к имени пользователя, не проходят на сервере. Я выбрал «Require Message Auth: NO» — но это не решает проблему. К сожалению, не удалось получить захваты wireshark, так как это была рабочая сеть, и пришлось откатиться до 7.14.3. Пробовал 7.15 и 7.16.2, избегал 7.17 из-за проблем с winbox в этом релизе. Кто-нибудь сталкивался с такой проблемой и смог её решить?

moutzl Guest	#11 0 25.02.2025 13:51:00 Он всё ещё не работает, даже в версии 7.18.

Larsa Guest	#12 0 26.02.2025 07:33:00 Если вы ещё этого не сделали, отправьте отчёт об ошибке в службу поддержки Mikrotik (это всего лишь пользовательский форум).

johnsonsd

Guest

#13

31.03.2025 14:25:00

Так что Mikrotik что-то с этим делает? Прошел уже год, а версии 7.15+ (и 6.49.18+) так и не научились поддерживать radsec ни при включенном, ни при выключенном «Require Message Auth». Если radius-сервер отправляет message-authenticator в ответе, то, судя по пакетным захватам с Mikrotik, он действительно получает валидный ответ с валидным message-authenticator, но при этом Mikrotik всё равно считает, что время вышло. Сейчас предполагается, что установка «Require Message Auth: NO» может сработать только в том случае, если radius-сервер действительно не отправляет message-authenticator в ответе.

aglabs

Guest

#14

13.04.2025 01:28:00

Они в курсе проблемы, судя по ответу, который я получил в службе поддержки, но точной даты решения не назвали. Наверное, это не исправят, пока больше пользователей не начнут жаловаться — тогда это станет приоритетом.

myusuf5400 Guest	#15 0 18.05.2025 17:19:00 Ты можешь решить эту проблему?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры