Не первый день бьюсь с проблемой, прошу помочь.
Имеется структура:
Клиент Windows 10 -- Роутер ASUS -- Mikrotik E50UG (hEX refresh) ROS 7.15.3 -- INTERNET (PPPoE) -- IKEv2 server
Изначально в структуре микротика не было, асус выпускал клиентов в интернет и выполнял NAT для внутренней сети. Все работало корректно, ike2 подключение у клиента работало.
Затем был установлен микрот как дополнительный маршрутизатор (зачем - отдельная песня), настроен NAT для доступа во внешний интернет, а на WAN интерфейсе асуса был настроен статический IP из внутренней подсети микрота. Интернет подключен в порт Ether1, из порта ether2 идет кабель в WAN Asus.
Таким образом, трафик от клиентов в интернет теперь проходит 2 NAT.
Однако, IKE2 у клиента подключаться перестало - в логах Windows пишется "Пользователь ХХХ установил удаленное подключение (*** ike2), которое завершилось сбоем. Возвращен код ошибки 809", а само подключение пишет "Не удалось установить связь т.к. удаленный сервер не отвечает".
Сниффинг трафика на клиенте Windows показывает, что на первоначальный запрос по UDP 500 клиенту приходит ответ от сервера, а затем на последующий запрос на UDP 4500 ответ уже не доходит.
Опытным путем выяснил, что при запущенном Torch или Packet Sniffer на микротике на PPPoE интерфейсе, ответ от сервера благополучно долетает по порту UDP 4500 и соединение устанавливается.
На скриншотах закрашен красным внешний IP сервера IKEv2.
Конфиг IP/Firewall
Код: Выделить всё
/ip firewall filter
add action=accept chain=forward src-address=*IKE2SERVER_IP*
add action=accept chain=input comment="Local MGMT accept" in-interface=LAN-Bridge-internal
add action=accept chain=input comment="Local ASUS accept" in-interface=ether2
add action=accept chain=input comment="Established and related INPUT accept" connection-state=established,related
add action=drop chain=input comment="All input drop (all from WAN)" in-interface-list=WAN
add action=accept chain=forward comment="Established and related accept" connection-state=established,related
add action=drop chain=forward comment="Drop invalid" connection-state=invalid
/ip firewall nat
add action=src-nat chain=srcnat comment="Main NAT" out-interface=Provider-PPPoE to-addresses=*External_IP*
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=\
Provider-PPPoE passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1300-65535
add action=change-mss chain=forward in-interface=Provider-PPPoE new-mss=\
clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1300-65535
В интернетах и в официальном мануале Mikrotik пишут, что использование fasttrack может привести к подобным проблемам. К слову, уже пробовал по-всякому его добавить для указанных соединений на *IKE2SERVER_IP* - эффекта нет.
Также, находил рекомендацию отключить Detect Internet - было выключено по умолчанию.
Отключение запрещающих правил файрвола не помогает.
Добавление accept правил для dst-address=*IKE2SERVER_IP* в RAW - prerouting не помогает.
Наткнулся на статью про фрагментацию пакетов IKE2:
https://directaccess.richardhicks.com/2 ... mentation/
Действительно, в пакетах от сервера отсутствует флаг IKEV2_FRAGMENTATION_SUPPORTED и можно было бы попросить админа сервера это настроить (когда выйдет из отпуска). Но ведь при запущенном Torch пакет доходит! Значит, сервер его отправляет, а проблема именно на стороне микрота.
PPPoE MTU 1492, Ether2 MTU 1500.
Микротик изначально был сброшен с параметром No default configuration.
Проблема проявляется на всех прошивках от заводской (7.15.3) до актуальной (7.18.2)
Все выглядит так, будто микрот дропает ответ от IKEv2 сервера при прохождении PPPoE интерфейса, но это происходит не по причине блокировки правилами, а чисто механически - по причине фрагментации пакета, не соответствия MTU, или по ошибке в работе самого протокола... До конца не понимаю.
ПОМОГИТЕ
