Не срабатывает Policy Routing
-
@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). Иначе у вас люди из локальной сети пф-а в инет не попадут.
