IPSec между Palo Alto и Strong Swan - трафик между IP-адресами конечной точки туннеля (используется для транспорта ESP) должен проходить через туннель
Есть Пали-Альто-Firwall (который я должен настроить) и промышленный контроллер (они называют его CP), который я не контролирую.
Скажем, у Palo Alto есть внешний IP 1.1.1.1, а у CP 2.2.2.2. Это IP-адреса, которые они используют для связи друг с другом, и эти IP-адреса можно увидеть на анализаторе, подключенном к внешнему интерфейсу PA.
IPSec Tunnel устанавливается, и если у CP есть второй интерфейс, все работает как ожидалось. Но некоторые из этих CP имеют только один интерфейс, только один IP, и этот IP должен быть доступен через туннель, но это не так.
Пинг 2.2.2.2 от PA и просмотр сниффера показывают, почему: PA отправляет незашифрованный эхо-запрос ICMP, на который не получен ответ. Когда вместо этого CP-администратор отправляет эхо-запрос 1.1.1.1, анализатор показывает пакет ESP, поступающий с 2.2.2.2 по 1.1.1.1, тогда PA отвечает незашифрованным эхо-ответом ICMP.
Как я могу заставить свой PA отправлять весь трафик через туннель, кроме трафика IPSec?
Я попытался настроить маршрут до 2.2.2.2 через туннель - конечно, туннель не подходит, потому что через неустановленный туннель не отправляются никакие сетевые пакеты.
Я попытался "объяснить" PA для отправки трафика IPSec другим способом, чем другой трафик - таблица маршрутизации не позволяет указать тип трафика.
Я попытался установить пересылку на основе политики, которая требует IP для туннеля. Туннель имеет только 2 IP-адреса; Я попытался прикрепить к нему 1.1.1.1, что не понравилось PA.
Я нашел похожие вопросы, даже здесь, на serverfailt, и да, это та же самая проблема, как маршрутизировать некоторые пакеты прямо через Интернет и другие пакеты через туннель, но это было об открытой vpn на Linux, а не в Palo Alto.
Некоторые записи в журнале, о которых говорил администратор CP, подсказали мне, что CP используют Strong Swan, и я смог воспроизвести вышеупомянутое поведение, используя мой PA и Strong Swan на Linux.
Теперь я могу тестировать быстрее, но не остается понятия, как заставить PA различать зашифрованные и незашифрованные пакеты в вопросах маршрутизации.
Есть идеи получше?
Спасибо! TomTomTom
2 ответа
С сожалением сообщаю вам, что вы теперь можете разделить мое разочарование:
PAN не поддерживают транспортный режим IPsec
Зачем? Я не имею ни малейшего представления. Это сломано вне веры. Я надеюсь, что кто-то исправит меня.
gateway charon: 11[IKE] <con3|14> establishing CHILD_SA con3{15}
gateway charon: 11[ENC] <con3|14> generating CREATE_CHILD_SA request 205 [ N(USE_TRANSP) N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
gateway charon: 11[ENC] <con3|14> parsed CREATE_CHILD_SA response 205 [ N(TS_UNACCEPT) ]
gateway charon: 11[IKE] <con3|14> received TS_UNACCEPTABLE notify, no CHILD_SA built
Решение, которое я пытаюсь развернуть, конечно же, заключается в том, чтобы избавиться от этих завышенных ценностей.
Я не знаю о брандмауэрах Пало-Альто. но я точно знаю, что мы не можем маршрутизировать трафик через туннель и ожидать, что он будет зашифрован. Мы должны указать это через криптографический список доступа (или что-то эквивалентное)