Имеются две виртуальные машины в VirtualBox. На одной установлена Mikrotik RouterOS, включены два сетевых адаптера. Внешний и внутренний, соответственно. На второй - Win10 с одним сетевым адаптером. Mikrotik получает внешний адрес (192.168.0.8) на внешнем интерфейсе. На внутреннем интерфейсе (10.50.0.1) настроен DHCP-сервер. Win10 получает адрес (10.50.0.200) от DHCP-сервера Mikrotik. Успешно выходит в инет. С физической машины успешно подключаюсь к Mikrotik через веб-интерфейс на 80-й порт и через WinBox.
На Win10 расшарена папка - доступ для всех, отключена парольная защита.
На Mikrotik пробрасываю порт:
Chain: dstnat
Dst. Address: 192.168.0.8
Protocol: 6 (tcp)
Dst. Port: 445
Action: dst-nat
To Addresses: 10.50.0.200
To Ports: 445

Физическая машина лежит в той же подсети, что и внешняя сетевуха Mikrotik, и имеет адрес 192.168.0.2
С физической машины Telnet'ом к порту подключиться не могу:
PS C:\Windows\system32> telnet 192.168.0.8 445
Подключение к 192.168.0.8...Не удалось открыть подключение к этому узлу, на порт 445: Сбой подключения

Через проводник к шаре виртуалки тоже подключиться не могу.

В логах Микротика следующее:
dstnat: in:ether1 out:(unknown 0), src-mac 70:4*:**:**:**:**, proto TCP (SYN), 192.168.0.2:58894->192.168.0.8:445, len 52

Понимаю, что ему не нравится внутренний интерфейс. Но не понимаю, чем именно. У кого-нибудь есть идеи? Уже голову сломал над этим.

Попробуй
Action: net-map

У меня так пор пробрасывается.

Ещё:

Для начала уберём
Dst. Address

И добавим:
In. interface (пропишем входящий интерфейс микротика, тот, что "по умолчанию" имеет имя "ether1-gateway")

(1) (2) Пробовал. Безрезультатно. В логах то же самое.

Брендмауэр посмотри

(4) Это самое очевидное и было проверено в первую очередь. Но там всё в порядке - с Микротика успешно цепляюсь на 445-й порт.

(4) В логах Микротика видно, что соединение не устанавливается.

(0) порты: 135,137,139,445, tcp + UDP
Попробуй. И микротиковский файрвол проверь, заблочь временно все останавливающие правила.

(7) +1 если есть блокирующие правила, то перед ними надо разрешить forward до 10.50.0.200.
И ещё.. win10 знает правильный маршрут до 192.168.0.2?

(7) Для открытия виндовой шары достаточно пробросить 445 TCP. Проверено на другой системе. К тому же, соединение на 445-й порт, который я открыл и пробросил, не устанавливается. При этом с Микротика устанавливается.
Никаких других правил нет. Только маскарадинг и проброс порта.

(8) А зачем Win10 знать этот маршрут, если запрос приходит с 192.168.0.2? Достаточно стандартных маршрутов.

(9) По пробросу все правильно, достаточно 445.
А вот дальше вопросы:
1. У Win10 шлюзом стоит микротик?
2. Счетчик пакетов у проброса тикает при попытке подключения?

привет, это мой первыый коммент, не судите строго.
я не уверен, что это тот же случай, но проброс портов на железных Микротиках (с софтовыми не работал) иногда требует специального описания маскарада для ответных пакетов. признаком такой ситуации как раз является состояние соединения "syn sent". для решения требуется создать еще одно правило маскарада
add action=masquerade chain=srcnat dst-address=10.50.0.200 dst-port=445 protocol=tcp

(10)
1. Да.
2. Да.

(11) Это чертовски гениально! Огромное вам спасибо! =)

(13) ты ж говорил у тебя уже есть маскарадное правило? или оно исключало 445 порт?

(14) тут есть одна странность. обычно достаточно входящего маскарада dst-nat, но в случаях соединений зависающих в состоянии "syn sent" необходимо второе правило src-nat исходящего маскарада. в каких случаях это требуется я так и не смог понять. почти всегда оно требуется чтобы получить доступ к Микротику, находящемуся за натом другого Микротика.

(15) dstnat это правило для входящих пакетов. тут маскарадинг редко используется. в (7) под маскарадингом он имел ввиду исходящий (srcnat) маскарадинг, я так полагаю. поэтому не очень понимаю как еще один маскарадинг для srcnat ему помог. единственный вариант - что 445 порт из его предыдущего правила был исклюен (не был включен)

*не в (7), а в (9)

virtualbox - настройки - сеть - проблос портов