Не срабатывает Policy Routing
-
Добрый.
@ko
Схему сети с адресацией, пжлста.Скрин 1. Выкл нижнее правило - оставьте только верхнее.
Скрин NAT. Не надо его полностью откл. Выберите hybrid и добавьте правило с NO NAT (может и не понадобится явно NO NAT делать - пф по-дефолту делает NAT только для Any network -> WAN ). Оно будет отрабатывать 1-м.
Не надо делать up. Здесь такое не приветствуются. Захотят люди - помогут.
-
требуется маршрутизация между удаленной площадкой с сетью 9.9.0.0/24 и площадкой с сетью 192.168.100.0/22 через промежуточный pfSense в "облаке".
На площадке 192.168.100.0/22 два провайдера, поднято два IPSec+GRE туннеля, требуется балансировка и/или отказоустойчивость.
-
@werter
у меня нет трафика из WAN кроме web-конфигуратора самого pfSense.
pfSense нужен только как vpn-концентратор.
я всё же могу Disable Outbound NAT ? -
из веб-интерфейса pfSense трассировка:
до 192.168.102.130
1 10.0.3.2 113.354 ms 113.283 ms 113.126 ms
2 192.168.102.130 113.694 ms 113.504 ms 113.331 msдо 9.9.0.47
1 10.0.2.2 103.427 ms 99.744 ms 102.205 ms
2 9.9.0.47 103.612 ms 99.910 ms 100.456 msА вот трассровка с 192.168.102.130 до 9.9.0.47
Трассировка маршрута к 9.9.0.47
1 7 ms 1 ms 1 ms 192.168.100.1
2 114 ms 118 ms 115 ms 10.0.3.1
3 * * * Превышен интервал ожидания для запроса. -
С одним шлюзом работает (без gw_group) ? Попробуйте с одним сперва настроить.
МТ из сети .100. знает про сеть 9.9.0 ? Роут есть до нее через GRE? Там два роута должно быть через оба линка. Возможно, что на этом же МТ должен быть роут и до овпн-сети 10.0.2.х (не уверен).
Зы. Скр .1.
Создайте 2 правила:- В src ЯВНО укажите 192.168.100.0/22, dst - 9.9.0.0/24 и ПРАВИЛЬНЫЙ gw
- И обратное с ПРАВИЛЬНЫМ gw (не уверен)
Зы2. Я бы попробовал ovpn для всех. И для сети .100.x настроил бы OSPF из 2-ух овпн-линков (пакет frr) с МТ.
-
@ko Здр
Есть у меня подозрение , что все это происходит из-за
того , что где-то кто-то не знает про сеть 9.9.0.0/24В виртуальных интерфейсах PF не работает функция Reply-to. В следствие этого ( когда нет статического маршрута ) , ответный пакет отправляется в шлюз по умолчанию, а не через шлюз на который пришел первый пакет
и счетчики правил , которые Вы показали , косвенно это подтверждают . Судя по всему , это правила для ответного пакета . Но они и не будут работать, потому что по таблице состояний соединение уже установлено -
@Konstanti said in Не срабатывает Policy Routing:
В виртуальных интерфейсах PF не работает функция Reply-to. В следствие этого ( когда нет статического маршрута ) , то ответный пакет отправляется в шлюз по умолчанию, а не через шлюз на который пришел первый пакет
и счетчики правил , которые Вы показали , косвенно это подтверждают . Судя по всему , это правила для ответного пакета . Но они и не будут работать, потому что по таблице состояний соединение уже установленоочень похоже на правду, спасибо!
теперь новая беда: если отказываюсь от одного канала до 192.168.100.0/22 и прописываю статический маршрут в эту сеть через один GRE+Ipsec то ICMP пакеты прекрасно ходят в обе стороны между 9.9.0.0/24 и 192.168.100.0/22, а вот TCP-соединения не устанавливаются. очень похоже на баг https://redmine.pfsense.org/issues/4479по все видимости остаётся только уходить на OpenVPN
-
@ko
Не знаю , что у Вас происходит
Но у меня tcp пакеты прекрасно бегают через канал GRE over IPSEC .
Помнится , я как-то долго ковырялся с этими туннелями и в результате создал вот такое Floating правило для GRE интерфейса
pass quick on { gre0 } inet from any to any tracker 1530287680 no state label "USER_RULE"
-
@Konstanti said in Не срабатывает Policy Routing:
@ko
Не знаю , что у Вас происходит
Но у меня tcp пакеты прекрасно бегают через канал GRE over IPSEC .
подскажите, у вас есть на одном pfsense несколько gre? между этими gre нормально tcp-пакеты бегают?Помнится , я как-то долго ковырялся с этими туннелями и в результате создал вот такое Floating правило для GRE интерфейса
pass quick on { gre0 } inet from any to any tracker 1530287680 no state label "USER_RULE"
я отключил IPSec, оставил голый GRE, указал явно статические маршруты в каждую подсеть, добавил floating rule как вы посоветовали с "no state" "any tcp flag", поставил на всех GRE интерфейсах MTU 1280, MSS 1240, в итоге:
icmp ping проходит между любыми узлами - ОК
udp iperf проходит между любыми узлами - ОК
tcp iperf с gre-интерфейсов pfsense до любой площадки - ОК
tcp iperf между площадками через pfsense - не проходит в одну сторону, причём спотыкается после 1 сек обмена:
Есть какие-либо идеи?
-
@ko
Здр
есть
если проблема именно в tcp , то возможен вариант неправильного расчета контрольных сумм tcp пакетов драйвером сетевого адаптера./System/Advanced/Networking
если не поможет ,используйте tcpdump для изучения трафика . Посмотрите журналы PF , нет ли заблокированных пакетов
-
@Konstanti said in Не срабатывает Policy Routing:
если проблема именно в tcp , то возможен вариант неправильного расчета контрольных сумм tcp пакетов драйвером сетевого адаптера.
жаль, но не помогло
-
@ko
подключайте tcpdump и смотрите где затык. я бы лично на pf не грешил -
Добрый
@ko
Покажите:- таблицу маршрутов на пф при всех поднятых туннелях;
- трасер из одной проблемной сети в др проблемную сеть;
- правила fw НА ВСЕХ интефрейсах + floating rules.
-
-
@ko said in Не срабатывает Policy Routing:
требуется маршрутизация между удаленной площадкой с сетью 9.9.0.0/24 и площадкой с сетью 192.168.100.0/22 через промежуточный pfSense в "облаке".
Так у вас трасер прошел. Связь есть.
И не надо Disable Outbond NAT - надо Hybrid Outbond NAT (или не трогайте вы его вообще - поставьте Auto). Иначе у вас люди из локальной сети пф-а в инет не попадут.
