Исходящий трафик с портами 137, 138, 139, 445.



  • Прошу помощи.
    Задача:
    Есть два офиса на удаленном расстоянии друг от друга офис1 и офис2.
    В обоих офисах установлены последние версии pfSense 2.4.4.
    В офисе1 настроен проброс портов 137, 138, 139, 445 (для сетевых папок Windows) на внутренний адрес.
    Из офиса2 из под pfSense не могу достучаться через \xxx.xxx.xxx.xxx до компьютера с сетевыми папками офиса1.
    Из других мест, где нет pfSense сразу появляется окно авторизации на компьютере офис1.
    Пробовал настроить Outbound NAT на pfSense офис2 на каждый порт из этих 4х, но все равно не работает.
    Подскажите, пожалуйста, где копать или что можно еще сделать.



  • @sert-sert добрый день
    Офисы соединены туннелем? Если да, то каким?
    Если нет, то нужно посмотреть настройки правил LAN интерфейса офиса 2. Возможно, запрещён выход наружу по этим портам



  • Туннелей нет.
    Firewall/Rules/LAN сейчас самое верхнее правило:
    IPv4 * * * * * *



  • @sert-sert Тогда я бы на Вашем месте , для начала, включил tcpdump на WAN интерфейсе офиса 1 и смотрел бы приходят ли пакетики от офиса 2 на эти порты ?
    И от этого уже плясал бы
    И соответственно на WAN интерфейсе офиса 2 ( уходят ли пакетики )



  • Пакеты из под pfSense офис2 не приходят на pfSense офис1, в tcpdump пусто.
    Попробовал с телефона раздать Wi-Fi на ноутбук и с ноутбука сразу появляется окно авторизации, в tcpdump тоже отображается.
    Еще попробовал tcpdump LAN интерфейса в офис2 снять, там тоже нет пакетов с этими портами и внешним ip офис1



  • на WAN интерфейсе офис2 тоже нет этих пакетов, насколько я вижу



  • @sert-sert гейтвей на хостах верно настроен? Офис 2. Проверьте все настройки DHCP, если у Вас адреса присваивается автоматически. Гейтвей, маска подсети и тд и тп. И настройки LAN интерфейса тоже



  • В офис1 и офис2 гейтвеи pfSense. Для чистоты эксперимента задал статически, ничего не поменялось. Отовсюду есть соединение, из под pfSense все еще нет.



  • @sert-sert чудес не бывает, покажите пож скрин правил LAN, какой ip у lan офис 2,какая маска подсети и настройки ip любого хоста из lan офис 2



  • 0_1539603490605_f78b3c78e313b69ddd313a4cb85df713.png

    192.168.100.1 - ip адрес LAN офис2
    255.255.255.0 - маска

    0_1539603716690_53cc39ecdf5a477821d34844775110ad.png



  • @sert-sert Сейчас подумаю
    Мысли вслух , вот в настройках правил LAN после разрешить все ( оно второе активное ) , все остальное не нужно .
    И еще 1 уточняющий вопрос - я правильно понял , что если запустить tcpdump на LAN интерфейсе , то нет пакетов на нужные порты ?? (например , с хоста 192.168.100.14 ) - а пинги идут с 100.14 на 100.1 ?
    И еще вопрос - прокси нет ?



  • 0_1539605963974_f68ddc7be113afb4b2c7fac6d93d316c.png
    пинги свободно идут, интернет работает.
    tcpdump на LAN интерфейсе запускаю (потом пробую зайти на внешний ip из проводника Windows на Ip адрес офис1) и вижу пакеты от 100.14, но тех пакетов, которые адресованы на внешний адрес офис1 с портами 137-139 + 445 - там нет.
    Прокси прозрачный



  • @sert-sert Т е пакеты на внешний адрес офис 1 есть но с другими портами?



  • Нет. пакетов на внешний адрес офис1 вообще нет



  • @sert-sert а обращаетесь по ip или доменному имени?,тут получается или виндоуз дурит или днс сервер



  • по ip



  • @sert-sert чтобы быть абсолютно уверенным что дело не в PF, я бы на Wan офис 1 открыл icmp, и проверил бы пинг от 100.14 офис 2. Если пинги идут, то тут явно проблема не в PF
    Мб на этом хосту антивирус какой-нибудь стоит ? И блокирует трафик



  • Пинги свободно шли. Антивирусов нет. Кажется дело в провайдере, хотя ТП официально заявила что ничего не блокируется.



  • @sert-sert said in Исходящий трафик с портами 137, 138, 139, 445.:

    .

    Доброго дня
    Если бы дело было в провайдере, на LAN/WAN интерфейсе офиса 2 были бы исходящие пакеты, а их нет
    Если пинги идут , значит , опять же связь между офисами есть
    А если попробовать
    вот так "\ \XXX.XXX.XXX.XXX\имя_папки" ?
    и тоже , для самоуспокоения
    если набрать ipconfig /all
    что про netbios пишет ?
    в инете пишут , что мб сбой драйвера сетевой карты компа



  • Доброго.

    @Sert-Sert
    Не любите себе организм.
    Удаляйте пробросы портов. Верните как было.
    Если офисы на разных провайдерах - поднимите туннель между офисами. И гоняйте в нем нужный вам трафик.

    P.s.Никогда не открывайте сетевые шары в Инет. Если не хотите попаболи.



  • Здравствуйте. Я уже отошел от этой идеи, заранее знал что идея плохая, но нужно было сделать как можно проще на короткий период времени. Проще не получилось, но и задача немного поменялась. Сейчас настроил через VPN.
    Не подкинете, случайно, годную свежую ссылку на полный мануал по настройке туннеля pf - pf?





  • На странице OpenVPN - NAT написано что он не подходит для сетевых папок.

    Note

    Utilizing NAT will work for many protocols but some that are commonly desirable across VPN connections, primarily SMB/CIFS file sharing between Windows hosts, will not function in combination with NAT. If a protocol is used that is not capable of functioning with NAT, this is not a viable solution.



  • Кстати, по поводу открытых наружу портов SMB:

    https://habr.com/company/jetinfosystems/blog/426463

    Аналогичный эффект будет при клике на нехорошем сайте на картинку с
    URL вида
    \\HOST\kotik.jpg

    Паранойя, возможно. Но резон подумать - есть.



  • @pigbrother
    С языка сняли )
    Зы. Ссылку поправьте. Из почты. Сам подписан на новости с хабра )

    Зы2. Новость по ссылке как раз для тех, кто все еще кипятит использует правило на ЛАН, к-ое разрешает всем всё и по всем протоколам.
    Повторюсь, что на данный момент для 90% потребностей пол-лей хватает только 80\443 TCP.
    Плюс DNS и NTP принудительно завернуты на лок. адрес pf.



  • @sert-sert said in Исходящий трафик с портами 137, 138, 139, 445.:

    На странице OpenVPN - NAT написано что он не подходит для сетевых папок.

    Note

    Utilizing NAT will work for many protocols but some that are commonly desirable across VPN connections, primarily SMB/CIFS file sharing between Windows hosts, will not function in combination with NAT. If a protocol is used that is not capable of functioning with NAT, this is not a viable solution.

    Пробовали? У меня работает. Правда nat мне в туннеле не требуется - в филиалах, как и положено, сети с разной адресацией.

    Зы. В настройках впн есть пункт Enable NetBios или как-то так. Попробуйте.
    Зы2. И почему Исходящий трафик с портами 137, 138, 139, 44 ? Исходящий будет с любого в диапазоне 1024-65535, а вот обращаться будете к удаленному ресурсу именно по тем портам, к-ые вам нужны.



  • @werter said in Исходящий трафик с портами 137, 138, 139, 445.:

    Пробовали? У меня работает. Правда nat мне в туннеле не требуется - в филиалах, как и положено, сети с разной адресацией.

    Тоже работает. И тоже без NAT.

    @werter said in Исходящий трафик с портами 137, 138, 139, 445.:

    В настройках впн есть пункт Enable NetBios или как-то так. Попробуйте.

    У меня работает, что с Enable NetBios , что без него.