Site-to-Site IPSec
-
Доброго времени суток.
Ситуация типичная - центральный офис (192.168.0.0/24) и удаленный (192.168.4.0/24).
Поднял site-to-site ipsec, но возникла одна проблема: из сети 192.168.4.0 шлюз сети 192.168.0.0 и любой узел из этой сети пингуются, а если пробовать пинговать какой-то узел сети 192.168.4.0 из сети 192.168.0.0, то пингуется только шлюз, но узлы нет (так же не открываются шары и т.д.), однако радмин подключается как миленький. В чем может может быть проблема? -
Смотреть какие протоколы разрешены.
-
У меня проблема очень похожая, с одной стороны другая пингуется, а с другой стороны первая - балалайка (. Правила для интерфейса ipsec все any to any to any (ради теста)
-
У меня все также. На интерфейсе IPsec указывал и any any и адрес удаленной сети. Не работает никак.
-
единственное что попробую это перенастроить второй шлюз наново, может протолкнет его там что-то )
-
@roy:
единственное что попробую это перенастроить второй шлюз наново, может протолкнет его там что-то )
отпишись сюда о результатах, будь добр.
-
и чего? ни у кого никаких результатов?
с теми-же граблями столкнулся. пересмотрел все правила, удалил и заново поднял ipsec с обеих сторон, с одной стороны даже переинсталил сенс - результата никакого.
Пожалуйста, кто найдет решение - расскажите как удалось, может у всех нас, собравшихся в этой теме аналогичные проблемы!? -
Я у себя поборол.
Проблема возникла после обновления сенса, а заключалась она банально в правилах фаервола.
А теперь по порядку.
Как говорилось раньше - есть два пфсенса, между ними ipsec туннель.
Сам ipsec цепляется и работает нормально, а вот трафик из сети А в сеть Б проходит, а из сети Б в А нет.
Со стороны сети Б 2 канала - основной и резервный.
На шлюзе Б (в эту сеть попасть можно, из нее - нет) В правилах фаервола, закладке LAN было прописано вручную лишь одно правило (на скриншоте корявой рукой подписано как 1) и, как ни странно, все работало.
После того как проблема появилась было добавлено еще одно правило (2 на скриншоте) и проблема исчезла.
Выдохнул с облегчением и теперь сижу и анализирую - нужно ли это правило 1 в принципе и пытаюсь вспомнить зачем я его прописал именно так при первоначальной настройке гейта
-
нет-нет, я за веткой наблюдаю, отпишусь позже - времени нету…. я перенастроил все наново, ipsec поднимается а трафика уже нету ни туда ни сюда )))
хотя правила на ipsec интерфейсе что на одном pfsense что на другом pfsense говорят про доступ к локальной сети по tcp, udp, icmp... -
@roy:
нет-нет, я за веткой наблюдаю, отпишусь позже - времени нету…. я перенастроил все наново, ipsec поднимается а трафика уже нету ни туда ни сюда )))
хотя правила на ipsec интерфейсе что на одном pfsense что на другом pfsense говорят про доступ к локальной сети по tcp, udp, icmp...Правила не айписека а LANa я так понял что из-за того что в правиле был жестко указан шлюз, то все что приходит в лан не через указанный гейт он дропал.
-
это понятно, я имел ввиду что для того что бы трафик с ipsec шел в локалку у меня на Firewall: Rules –> ipsec - есть для этого более чем все, а он зараза не ходитЪ ((
-
у меня настройка LANa уже вот такая с обоих сторон, но все равно пинга нет. Единственное чего я не могу понять, почему работает Radmin в эту сеть, а пинг нет. У меня это в голове как-то не укладывается.
-
у меня настройка LANa уже вот такая с обоих сторон, но все равно пинга нет. Единственное чего я не могу понять, почему работает Radmin в эту сеть, а пинг нет. У меня это в голове как-то не укладывается.
Коллега, насколько я вижу второе по счету правило это стандартное разрешение всего трафика, инициализированного из локальной подсети, если отбросить все туннели и пр. то в идеале в локалку через wan с таким набором правил вы не пробьетесь (пинг в том числе), если нет никакого порт-форварда. Но не исключено что, например, настройки на интерфейсе ipsec как-то влияют на то что пинга нет а другой трафик проходит… вы явно заблокируйте порт radmin"a на каждом интерфейсе поочередно и увидите на каком из них сработало правило. а вообще покажите ipsec.
п.с. дело в том, что я давно пользуюсь pf'ом на freeBSD и никогда не было такого что бы трафик требовал нескольких подтверждений, например, разрешить такой-то трафф. с ipsec на lan надо прописывать правила как на одном так и на другом интерфейсе... а тут многие пишут что такое на pfsense бывает. У меня такого на pptp не было - разрешил icmp-req от pptp клиентов до лан интерфейса - пинг только лан адреса и все. разрешил только пару tcp и udp между pptp клиентами - заработали файл-шары.
А с этим ipsec что-то мутно все.
-
п.с. дело в том, что я давно пользуюсь pf'ом на freeBSD и никогда не было такого что бы трафик требовал нескольких подтверждений, например, разрешить такой-то трафф. с ipsec на lan надо прописывать правила как на одном так и на другом интерфейсе… а тут многие пишут что такое на pfsense бывает. У меня такого на pptp не было - разрешил icmp-req от pptp клиентов до лан интерфейса - пинг только лан адреса и все. разрешил только пару tcp и udp между pptp клиентами - заработали файл-шары.
Есть несколько общих моментов для всей системы pfSense:
- все исходящие пакеты из pfSense разрешены на любом интерфейсе, внутренняя часть pfSense считается Trusted Zone
- соответственно на интерфейсах правила рулят входящим потоком пакетов ( Floating rules не трогаем )
- по умолчанию пакеты идут дефолтными маршрутами, если не определено иное статическими маршрутами или policy-based-routing правилами
- Policy-based-routing правила имеют приоритет над статическими маршрутами.
Кроме того для успешной работы разного рода VPN требуется, чтобы конечный (целевой хост) должен иметь представление куда отсылать ответный пакет. Бывает такое:
- на той стороне не настроен обратный маршрут (иногда NAT-ят пакеты для "исправления")
- если туннель между роутерами, то роутеры должны быть шлюзами по умолчанию на хостах сети ( так-же "исправляют" NAT-ом - умышленно или нет зависит от ситуации )
В качестве траблов бывают конфликтующие правила разных доп.пакетов. В любом случае есть дамп правил в /tmp и tcpdump.
зы: Это конечно не все, но бывает достаточно часто.
-
Я свою проблему решил. Коллеги, которые настраивали компы в филиале, криво настроили виндовые фаерволы (Win7) на конечных машинах, Radmin, естественно, был в исключениях. Надеюсь, кому-то поможет.
-
Коллеги.
Решил несколько своих точек объединить через ipsec-тоннели. До этого с ipsec`ом не работал. На тесты поставил себе два пифа 2.0.3. Всё настроил - статус ipsec позеленел. Пытаюсь пинговать шлюзы через тоннель - ответа нет. Про компы за этими шлюзами вообще молчу.
Запустил с первого шлюза трассировку до локального адреса второго пифа, так пакеты пошли через nat. Смотрю таблицу маршрутизации, а там никаких упоминаний про удалённые сети. Прописал нужные маршруты через командную строку - всё зашуршало. В настройках второго этапа установления тоннеля удалённые сети прописаны на обоих гейтах.
И вот вопросы.
1. При поднятии ipsec-тоннеля должен ли пиф в таблицу маршрутизации заносить маршруты до удалённых сетей? Во всех руководствах по настройке ipsec на pfsense (официальное руководство и самопальные хавтушки) этот момент не отражён.
2. Если ответ на первый вопрос утвердительный, то как решить возникшую проблему? Ибо можно конечно и скрипт наваять прописывающий маршруты, но не кошерно это как-то. -
Я совсем не понимаю Вас, когда Вы говорите "Второй этап установления тоннеля". Это что за такой этап? И можно по конкретней, что и где нужно прописать?
-
Это что за такой этап? И можно по конкретней
Гугл ответит вам конкретней не куда, осталось только спросить.
-
Я совсем не понимаю Вас, когда Вы говорите "Второй этап установления тоннеля". Это что за такой этап?
Объясняю на пальцах. Встречаются два полиглота со знанием нескольких языков. На первом этапе они выясняют, на каком языке они будут общаться (аналог обмена ключами). А на втором этапе они собственно уже разговаривают, то есть зашифровывают свои мысли через устную речь.
И можно по конкретней, что и где нужно прописать?
Нигде ничего не нужно прописывать, ибо SPD для шифруемого трафика выступает в роли маршрутизатора и списка доступа. То есть после установления тоннеля никаких дополнительных записей в таблице маршрутизации появляться не должно.
Если что-то не работает, то поменяйте алгоритмы аутентификации и шифрования. Проверьте в сто пятый раз все настройки. Корень своей проблемы я не идентифицировал, но подозреваю кривое создание виртуалке под ксеном. Ибо пересоздав обе машины, всё заработало с полпинка.
И ещё имейте в виду вот что. Пингование противоположного конца тоннеля с маршрутизатора никаких результатов не даст. Пинговать надо только с какой-нибудь машины из локальной сети. -
"Второй этап установления тоннеля".
Вероятнее всего вам говорят об єтом
Рисунок под надписью: "Вид после сохранения. Продолжаем."
http://www.thin.kiev.ua/router-os/50-pfsense/705-ipsec-denovo-pfsense.html