Кратко — это не «магия», а конфликт между DNAT/маршрутизацией/мangle/connection‑tracking. При пробросе 443 вы меняете путь пакетов и/или условия, по которым они помечаются и маршрутизируются, и в результате SSTP‑трафик либо попадает в неправильный интерфейс (в туннель), либо «застревает» в connection‑track/NAT. Ниже — где смотреть и типичные причины + что сделать.
Что проверить в первую очередь
- NAT (dst‑nat/masquerade)
- /ip firewall nat print — посмотрите правило проброса 443. Оно слишком широкое (any→tcp/443)? Правильно ли указан dst‑address и to‑addresses?
- Mangle (маркировка пакетов/соединений)
- /ip firewall mangle print — какие правила помечают трафик на 443? Совпадает ли критерий с тем трафиком, который вы хотите маркировать (исходящий SSTP, входящие на проброшенный сервер и т. д.)?
- Маршрутизация/mark routing
- /ip route rule/ /ip route get dst‑address=IP — куда отправляется пакет по маркировке? Убедитесь, что помеченный трафик не попадает в туннель, если он должен идти в WAN.
- Connection tracking / активные соединения
- /ip firewall connection print where dst‑port=443 — есть ли «старые» записи, которые мешают новым правилам?
- FastTrack
- Если включён — он может обходить mangle/mark routing. Попробуйте временно отключить FastTrack для теста.
- Firewall filter (INPUT/FORWARD)
- Правила фильтра не блокируют DNAT‑трафик.
- Логика hairpin (NAT loopback)
- Если обращаетесь к публичному IP изнутри сети, нужна hairpin NAT (src‑nat) или это может ломать связь.
- Отладка трафика
- /tool sniffer quick port=443 interface=<wan|sstp|lan>
- torch на соответствующих интерфейсах
- смотрите, уходит ли SYN/ответы наружу по нужному интерфейсу
Типичные причины и сценарии
1) Маркировка по порту 443 и политика маршрутизации
- mangle помечает весь трафик на порт 443 и отправляет его в SSTP‑туннель. После добавления dst‑nat пробрасывающего 443 часть трафика, которая должна попасть на внутренний сервер (или наружу), теперь тоже попадает в туннель — получается петля/ошибка маршрутизации.
- Решение: уточнить mangle (по src/dst IP, по connection‑mark), исключить из маркировки адреса сервера, не маркировать входящие DNAT‑потоки.
2) DNAT/маршрутизация конфликтует с локально сгенерированными соединениями
- DNAT в PREROUTING не действует на пакеты, сгенерированные самим роутером (OUTPUT), но комбинация с mangle/marks может изменить поведение. Проверьте, не приводит ли изменение dst адреса/порта к тому, что ответ уходит не на тот интерфейс.
- Решение: проверить /ip route get и правила mangle/output.
3) FastTrack/обход mangle
- FastTrack может ускорять потоки, но при этом пропускает mangle/mark routing, из‑за чего пометки не применяются как ожидается либо наоборот — пометки не доходят туда, где надо.
- Решение: временно отключить fasttrack или поставить исключения.
4) Hairpin NAT / SNAT
- Внутренние клиенты, обращающиеся к публичному IP, должны проходить через hairpin NAT; иначе пакеты дойдут, но ответы потеряются.
- Решение: настроить src‑nat для петлевых соединений (hairpin).
5) Connection‑tracking stale entries
- После изменения NAT/маргинов старые записи в conntrack могут оставить пакеты «в старом состоянии».
- Решение: удалить соответствующие записи /ip firewall connection remove или дождаться таймаута.
6) Масштаб/лимиты/фильтрация по соединениям
- Ограничения по количеству соединений или правило filter limiting может блокировать новые входящие потоки на 443.
- Решение: проверить счётчики и лимиты.
Практические шаги для диагностики
1. Отключите временно mangle‑правила, которые маршрутизируют 443, и проверьте, восстанавливается ли SSTP.
2. Отключите fasttrack и протестируйте.
3. Используйте torch/sniffer на WAN и на SSTP-интерфейсе, чтобы понять куда уходят/приходят пакеты.
4. Посмотрите /ip firewall connection print where dst‑port=443 и при необходимости удалите записи.
5. Выполните /ip route get dst‑address=<VPN‑server‑IP> чтобы увидеть, какой маршрут выбирается для конкретного адреса.
6. Уточните NAT правило: сделайте его максимально конкретным (по public‑IP и internal‑IP), чтобы не захватывать лишний трафик.
Резюме
Чаще всего причина — неверно сформулированные mangle/маршруты в сочетании с прямым DNAT на 443: часть трафика, предназначенного для сервера или исходящего к VPN‑серверу, помечается и уходит в туннель, или DNAT/conntrack оставляет ответы в неверном направлении. Сфокусируйтесь на mangle‑правилах (исключениях), проверке маршрута для целевых IP и очистке/мониторинге conntrack; используйте torch/sniffer для пошаговой трассировки пакета. Если пришлёте выводы nat/mangle/routing и пример IP (WAN, VPN‑server, to‑address), помогу указать точнее, какое правило менять.