Не срабатывает Policy Routing

ko

требуется маршрутизация между удаленной площадкой с сетью 9.9.0.0/24 и площадкой с сетью 192.168.100.0/22 через промежуточный pfSense в "облаке".

На площадке 192.168.100.0/22 два провайдера, поднято два IPSec+GRE туннеля, требуется балансировка и/или отказоустойчивость.

ko

@werter
у меня нет трафика из WAN кроме web-конфигуратора самого pfSense.
pfSense нужен только как vpn-концентратор.
я всё же могу Disable Outbound NAT ?

ko

из веб-интерфейса 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 * * * Превышен интервал ожидания для запроса.

werter

С одним шлюзом работает (без 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) с МТ.

Konstanti

@ko Здр
Есть у меня подозрение , что все это происходит из-за
того , что где-то кто-то не знает про сеть 9.9.0.0/24

В виртуальных интерфейсах PF не работает функция Reply-to. В следствие этого ( когда нет статического маршрута ) , ответный пакет отправляется в шлюз по умолчанию, а не через шлюз на который пришел первый пакет
и счетчики правил , которые Вы показали , косвенно это подтверждают . Судя по всему , это правила для ответного пакета . Но они и не будут работать, потому что по таблице состояний соединение уже установлено

ko

@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

Konstanti

@ko
Не знаю , что у Вас происходит
Но у меня tcp пакеты прекрасно бегают через канал GRE over IPSEC .

Помнится , я как-то долго ковырялся с этими туннелями и в результате создал вот такое Floating правило для GRE интерфейса

pass quick on { gre0 } inet from any to any tracker 1530287680 no state label "USER_RULE"

ko

@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 сек обмена:

Есть какие-либо идеи?

Konstanti

@ko
Здр
есть
если проблема именно в tcp , то возможен вариант неправильного расчета контрольных сумм tcp пакетов драйвером сетевого адаптера.

/System/Advanced/Networking

если не поможет ,используйте tcpdump для изучения трафика . Посмотрите журналы PF , нет ли заблокированных пакетов

ko

@Konstanti said in Не срабатывает Policy Routing:

если проблема именно в tcp , то возможен вариант неправильного расчета контрольных сумм tcp пакетов драйвером сетевого адаптера.

жаль, но не помогло

Konstanti

@ko
подключайте tcpdump и смотрите где затык. я бы лично на pf не грешил

werter

Добрый
@ko
Покажите:

таблицу маршрутов на пф при всех поднятых туннелях;
трасер из одной проблемной сети в др проблемную сеть;
правила fw НА ВСЕХ интефрейсах + floating rules.

ko

@werter

werter

@ko said in Не срабатывает Policy Routing:

требуется маршрутизация между удаленной площадкой с сетью 9.9.0.0/24 и площадкой с сетью 192.168.100.0/22 через промежуточный pfSense в "облаке".

1604403525926-9b65c21a-7513-41f1-8b22-3daaddb18a30-image.png

Так у вас трасер прошел. Связь есть.

И не надо Disable Outbond NAT - надо Hybrid Outbond NAT (или не трогайте вы его вообще - поставьте Auto). Иначе у вас люди из локальной сети пф-а в инет не попадут.