Странный рутинг
-
Вот это уже интересно, нужно попробовать.
Гейт/сервер vpn естественно пингуется и с базовой машины и из pfSense. -
Пара мыслей. Маршруты нужно определять не через Firewall -> Rules, а через System -> Routing вкладка Routes.
Такие маршруты будут действительны только для самого pfSense. А станции в сети - по правилам FW Rules отдельно работают.
Я уже нарывался на такое, отписывался здесь в какой-то теме.
Эти маршруты будут действительны для всех, если иное не определено в Firewall -> Rules. Иными словами, если в правиле Firewall -> Rules gateway выставлен как default, то будет действовать таблица маршрутизации pfSense, включая то, что пользователь прописал в System -> Routing [Routes].
Если вы хотите чтобы для определенного трафика действовала дефолтная таблица маршрутов, то правило для этого трафика в Firewall -> Rules нужно поставить выше правил, для которых определен альтернативный gateway и под которые подпадает этот трафикю -
Прекрасный пример ответа "вообще", не читая вопроса. :)
В общем, только после того как прописал особое правило рутинга во "Floating rules", появился контакт к хостам подключенным через OpenVPN сервер (выделенный).
-
Мда, чудны дела твои…
Поторопился малость. Из машин за гейтом контакт с машинами в OpenVPN есть, а вот если попытаться из VPN подключиться к машине за pfSense, облом. Т.е. пакеты от источника до получателя доходят, тот отвечает, естественно на адреса отправителя, но на сервер VPN эти пакеты не попадают... Загадка. Подключение от машин, находящихся просто в одной сети с выходным интерфейсом pfSense, проходит без сучка и задоринки. Будем смотреть теперь физический интерфейс :) -
У вас cisco - это то, куда все сходится, и для всех она default gateway. Вот на ней я бы на вашем месте и прописал маршрут в 10.8.0.0/24 через 192.168.21.214, а если NAT на pfSense отключен, то и в сети 192.168.0.0/24, 192.168.1.0/24 через WAN IP pfSense. Да, трафик между машинами за pfSense и клиентской сетью OpenVPN ходил бы через cisco, но если он небольшой, то и нормально. Зато весь ручной роутинг в одном месте.
Еще у pfSense есть такой момент, что пакеты от локальных процессов всегда уходят через default gateway. Я к тому, что трассировка с самого pfSense - не показатель, нужно трассировать 10.8.0.0/24 с машины за pfSense. То, что вы прописали floating rule исправило только этот момент. По сути это правило для общения машин за pfSense с клиентской сетью OpenVPN не нужно, достаточно маршрута в System -> Routing -> Routes -
теоретически оно может и так, а практически правило в System -> Routing -> Routes эффекта не даёт, что без "плавающего правила", что с ним. NAT естественно включен, с одной стороны у pfSense сеть .21.0/24, с другой - .0.0/24.
Чуть позже: таки пришлось прописать правило во внутреннем рутере, который виланами рулит и является гейтом для всех. Странновато реализован рутинг в pfSense, при том что это вообще-то рутер по призванию.
-
это вообще-то рутер по призванию.
Нее. По призванию он как раз кусок роутера. А полноценный роутер из него как раз хотят все сделать. Ожидаемо безуспешно.
-
NAT естественно включен, с одной стороны у pfSense сеть .21.0/24, с другой - .0.0/24.
Да? И в чем взаимосвязь?
Странновато реализован рутинг в pfSense, при том что это вообще-то рутер по призванию.
Не надо делать глобальных выводов из вашей частной неудачи. Не то превратитесь в "обиженного", такого как постом выше. Вы очевидно недавно на pfSense, решили сделать все по наитию, не прочитав документацию. Где-то накосячили в конфигурации и не видите этого. Схему сети выкладывать не хотите, скриншоты очевидно тоже. Ну, вал_и_те теперь все на pfSense, это действительно проще чем признать, что чего-то не понимаете.
Ваша ситуация (асимметричный роутинг) яйца выеденного не стоит и элементарно решается. Будет схема, будут скрины, будем говорить. -
2 rubic
Не то превратитесь в "обиженного", такого как постом выше.
Это не обида, это констатация очевидного факта. Концепцию нужно менять. Она себя исчерпала уже в m0n0. Из куска маршрутизатора полноценный роутер не получиться, очевидно-же.
-
Специально для великого Рубика приведу невообразимо сложную схему
Из подписей и предидущих постов вроде должно быть ясно что и куда должно бегать. Единственное пояснение - pfSense и Hosts array - внутри ESXi 5.
NAT естественно включен, с одной стороны у pfSense сеть .21.0/24, с другой - .0.0/24.
Да? И в чем взаимосвязь?
Может великий подскажет способ общения компов, находящихся в разных сетях, в обе стороны, не применяя NAT. Нобелевскую не дадут, но на что-то поменьше можно рассчитывать.
-
Может великий подскажет способ общения компов, находящихся в разных сетях, в обе стороны, не применяя NAT. Нобелевскую не дадут, но на что-то поменьше можно рассчитывать.
У меня так две локальные сети и "общаются" (10.7.0.х и 10.7.1.х), хотя на внешних интерфейсах обеих - адреса 192.168.0.х. И в обеих сетях в логах на pf-ах я "вижу" статистику от узлов 10.7.0.х\10.7.1.х, а не от 192.168.х.х. Само собой в правилах NAT-а стоит "галка" на No NAT. Так уж у нас повелось и такие корпоративные требования и требования пров-ра, к-ый предоставляет канал для связи эти двух сетей.
Вопрос - ЧЯДНТ ?
-
Где вы нашли провайдера, который вам даёт левонетовские адреса?
Если у вас десятые сети прописаны как /8 или хотя бы как /16, то ничего удивительного. -
Где вы нашли провайдера, который вам даёт левонетовские адреса?
Если у вас десятые сети прописаны как /8 или хотя бы как /16, то ничего удивительного.Нам корпоративный канал пров предоставляет внутри своей сети (vlan-ом). И да , когда на WAN - Инет, то без NAT-а никуда.
Просто не стоит однозначно утверждать , что без трансляции адресов невозможно функционирование сетей.
Мой пример - как частный случай такой возможности. -
Где вы нашли провайдера, который вам даёт левонетовские адреса?
Если у вас десятые сети прописаны как /8 или хотя бы как /16, то ничего удивительного.Нам корпоративный канал пров предоставляет внутри своей сети (vlan-ом). И да , когда на WAN - Инет, то без NAT-а никуда.
Просто не стоит однозначно утверждать , что без трансляции адресов невозможно функционирование сетей.
Мой пример - как частный случай такой возможности.У нас провайдер с белым адресом канал выделяет, а маршрутизация с помощью BGP сделана без NATа. VLAN-ов нет, по крайней мере на нашей стороне.
Одно время на этом канале с успехом работал PFSense с пакетом BGP. -
Да, снимаю своё утверждение про NAT, как сказанное в запале. В данном случае NAT'ом изолирован зоопарк внутри вмварного сервера от корпоративной сети.
У нас провайдер с белым адресом канал выделяет, а маршрутизация с помощью BGP сделана без NATа. VLAN-ов нет, по крайней мере на нашей стороне.
Одно время на этом канале с успехом работал PFSense с пакетом BGP.Если у вас внутри сети - белые адреса (трансляция 1:1), то NAT естественно не нужен. Если левонет - обязан наличествовать, т.к. в И-нете левонет не живёт. BGP занимается маршрутизацией между автономными системами (в основном) и к преобразованию адресов никакого отношения не имеет.
-
Давайте для начала скриншоты
- System -> Routing -> Gateways, Routes и Groups (если не пусто)
- Firewall -> Rules по всем вкладкам
-
Ну что ж, обнажимся…
Остальные вкладки пустые
одна строка дублируется в скриншоте
Остальное пусто.
-
В System -> Routing -> Routes заведите маршрут:
10.8.0.0/24 GWvpn WANВ Firewall -> Rules -> Floating зайдите в редактор правила, поставьте галку "Disable this rule" и сохраните
В Firewall -> Rules -> WAN добавьте правило:
Proto Source Port Destination Port Gateway Pass ICMP * * * * *Пробуйте пинговать WAN IP pfSense с из сети 10.8.0.0/24
Пробуйте пинговать хост в сети 10.8.0.0/24 из сети 192.168.0.0/24 -
С этого всё начиналось, правда без ICMP, за ненадобностью. Коннект по TCP к внутреннему сайту не проходил, по причине не прохождения обратных пакетов, точнее, направление их на дефолтный гейт. Пакеты генерируемые внутренними хостами так же уходили туда. Сейчас ситуация следующая (для тех кому лень читать ранние посты):
пакеты от внутреннего хоста идут к хостам в VPN (по правилу в "плавающих") и получают ответы, пакеты от хостов из VPN доходят до внутренних хостов, ответные пакеты отправляются на дефолтный гейт.
На дефолтном гейте (киске 3825) заведено правило которое отправляет пакеты, адресованные в сеть VPN на сервер VPN, благодаря чему всё стало доступно (плюс некоторые побочные эффекты). -
Кажется у меня больше желания разобраться почему простой маршрут не работает, чем у вас. Понимаю, все кое-как наладилось и не хочется начинать с начала.
Если не трудно, прикрепите config.xml (Diagnostics -> Backup/Restore -> Download Configuration), я подниму его в виртуалке. pfSense у вас на "серых" адресах, пароль в конфиге в открытом виде не хранится. Думаю, бояться тут нечего.
