Назад | Перейти на главную страницу

IPSec между Palo Alto и Strong Swan - трафик между IP-адресами конечных точек туннеля (используется для транспорта ESP) должен проходить через туннель

Есть межсетевой экран Пало-Альто (который мне нужно настроить) и промышленный контроллер (они называют его CP), которые я не контролирую.

Скажем, Пало-Альто имеет внешний IP 1.1.1.1, а CP - 2.2.2.2. Это IP-адреса, которые они используют для связи друг с другом, и эти IP-адреса можно увидеть в сниффере, подключенном к внешнему интерфейсу PA.

Туннель IPSec устанавливается, и если 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?

Некоторый вывод журнала, о котором говорил администратор CP, натолкнул меня на мысль, что CP используют Strong Swan, и я смог воспроизвести описанное выше поведение, используя свой PA и Strong Swan на компьютере с Linux.

Теперь я могу тестировать быстрее, но понятия не имею, как заставить PA различать зашифрованные и незашифрованные пакеты в вопросах маршрутизации.

Есть идеи лучше?

Спасибо! TomTomTom

С сожалением сообщаю вам, что теперь вы можете разделить мое разочарование:

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

Решение, которое я пытаюсь развернуть, - это, конечно же, избавиться от этой дорогой чуши.

Я ничего не знаю о брандмауэрах Пало-Альто. но я точно знаю, что мы не можем направить трафик через туннель и ожидать, что он будет зашифрован. Мы должны указать это через список доступа к криптовалюте (или что-то подобное)