Несколько раз за последнее время услышал что нельзя поднять site-to-site туннели IPSec в route-based режиме с одной стороны с policy-based режиме с другой. Если хочется, то конечно можно. Выбранный режим это не более чем локальный способ отправить нужный вам трафик в туннель, а на уровне IKEv2 всё равно придётся согласовать Traffic Selectors, чтобы сформировать необходимые для работы IPSec таблицы политик и состояний. И вся проблема не в протоколе, а в реализации соответствующего режима.

Для policy-based значения TS задаются в явном виде, как например в Juniper или Strongswan, или в Сisco access-list который привязывается к crypto-map. На основе этих значений формируются и политики, здесь уже неявно, которые заворачивают трафик в туннель. При этом обеспечить прохождение трафика через нужный интерфейс с политиками всё равно придётся маршрутизацией.
А для route-based нет необходимости явно задавать значения. Про таблицу маршрутизации IPSec мало что знает, поэтому на основе ваших маршрутов, которые заворачивают трафик в VTI интерфейс никакие согласования не выполняет. Вместо этого, по умолчанию используется TS 0.0.0.0/0 - 0.0.0.0/0, посмотрите свои SA в режиме route-based, чтобы в этом убедиться. Таким образом, если настроить такое же значение со стороны policy-based, то всё должно заработать между маршрутизаторами с разными режимами управлением трафика IPSec. Как минимум один такой туннель вы точно сможете построить, в ситуации когда уж совсем не удалось договориться. Второй подобный туннель с policy-based стороны уже может упереться в особенности реализации, потому что одинаковый 0.0.0.0/0 для другого туннеля может иметь неоднозначное значение в политиках, ловил такое на ASA - в двух разных IPSec, но с одинаковыми TS внутри, один из них не поднимется. Наверное, ситуация имеет типовое решение, или обновление, но тогда я просто подробил сеть в одном из туннелей на две половинки, потому что имел доступ к обоим концам туннеля.

Лучшее же решение, даже если вы используете route-based режим с обоих сторон - это явно определить traffic selectors. Это можно сделать и в Strongswan, и в Juniper, и в Cisco IOS опцией Multi-SA. Помимо возможности поднимать туннели с любой стороной хоть policy-based хоть route-based ещё и дополнительная защита если упустили лишний трафик в туннель, он туда не пролезет, только дропнуть его не забыть. Конечно, реализация этого может быть не везде, насчёт уже упоминаемой ASA совсем не уверен, да и версии софта должны быть актуальные, но способ с TS 0.0.0.0/0-0.0.0.0/0 один раз сработает всегда.