Маршрутизация правилами

[panperm]

Добрый день!
Помогите, пожалуйста ... у меня проблема в настройке маршрутизации с помощью правил (Policy Routing).
Версия pfSense 2.4.4 p2

1. Между PC1 - PC2 должна быть отказоустойчивая связь
   ping идет, но трассировка не работает.

с PC1

c PC2

Если сбросить стейты, то может ситуация поменяться, на PC1 не будет работать трассировка, а на PC2 все ок.

Что неправильно настроил?

pfSense1

pfSense2

В Static Routes нигде ничего нет.

2. Между PC1 - PC3 должна быть связь. Нужно ли применять Floating rules для этого? Если да, то на каких интерфейсах?

[vladimirlind]

1. Между PC1 - PC2 ведь есть связность, судя по icmp. Трассировка не видит все промежуточные хопы? А может, GIF скрывает их. 10.150.15.162 - это адрес gif интерфейса?

2. А как связываете PC1 с PC3? Тоже policy-routing через gre? Или статические маршруты на gre? Чтобы трафик ходил через gre - надо назначить gre интерфейс и создать разрешающие правила на gre интерфейсе. Floating правила не нужны.

[panperm]

Спасибо за ответ!

1. Связность по icmp есть, но эта нестабильность с трассировкой ... не должно быть так.
   Трассировка при policy routing "съедает" адреса pfSense 172.16.74.222 и 172.31.74.25, это нормально.
   Адреса GIF туннеля
   pfSense-1 10.150.15.161
   pfSense-2 10.150.15.162

Вот сейчас сбросил стейты и трассировка стала нормальной.

PC1

PC2

Сбросил стейты и снова началось .....

2. Связываю gre туннель между pfSense-1 и Mikrotik. Через Static Route проблем нет. Планирую связать через Policy Routing, вот и спрашиваю как должно быть.
   Начну делать когда по п.1 все станет стабильно и понятна будет методика.

[vladimirlind]

1. Не обращал внимания на трассировку при полиси-рутинге, но да - хоп LAN интерфейсов скрыт из-за него, скорее всего - так как TTL в пакете обычно уменьшается при выборе системой маршрута , а в полиси-рутинге pf (модуль стейтфул фаервола) выполняет работу вместо таблицы маршрутов. Если сбрасывать стейты фаервола, то по идее полиси-рутинг глушится - на время - так как он завязан на правила фаервола. И возможно, трассировка идет по маршруту в таблице (если он есть). Мне кажется, полиси-рутинг через два gif между pfsense 1 и 2 правильно настроен и работает.

2. Policy-routing вполне будет работать. GRE вроде умеет reply-to, так что обратный трафик должен возвращатся куда надо.

[werter]

@panperm
Нескромный вопрос.
Чем обусловлен выбор GIF в кач-ве туннеля? Тот же Openvpn прекрасно умеет failover , если явно объявить ovpn-интерфейсы и создать из них group. А надо, так и OSPF к этому делу прикрутить. И GIF не умеет шифрование.

Зы. Зачем правило с RFC1918? Какова его роль? Получаетеся, что пф отправляет весь трафик для серых сетей (кроме 172.16.74|31.0/24) в Default GW. И тот, к-ый предназначен для сети за МТ тоже. И при этом у вас для сети за МТ имеется на пф1 static route. Странно как-то.

Зы2. Можно скрин таблицы марш-ции пф-ов при всех поднятых туннелях?

[panperm]

Немного изменил стенд, поэтому решил сделать новую тему.
https://forum.netgate.com/topic/143415/policy-based-routing-транзитный-трафик

[panperm]

@werter GIF для тестовой среды.
RFC1918 там был еще транзитный трафик, не относящийся к данной проблеме.
Считаю тоже, что все работает. Вопрос теперь 2 - транзитный трафик. Никак не получается.