Есть межсетевой экран Пало-Альто (который мне нужно настроить) и промышленный контроллер (они называют его 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?
Я попытался настроить маршрут к 2.2.2.2 через туннель - конечно, туннель не подходит, потому что через неустановленный туннель не отправляются сетевые пакеты.
Я попытался «объяснить», что PA отправляет трафик IPSec другим способом, чем другой трафик - таблица маршрутизации не позволяет указать тип трафика.
Я попытался установить пересылку на основе политики, которая требует IP-адреса для туннеля. В туннеле всего 2 IP-адреса; Пытался прикрепить к нему 1.1.1.1, что не понравилось PA.
Я нашел похожие вопросы, даже здесь, на serverfailt, и да, это та же проблема, как маршрутизировать одни пакеты прямо через Интернет, а другие пакеты через туннель, но речь шла об открытом vpn в Linux, а не в Пало-Альто.
Некоторый вывод журнала, о котором говорил администратор 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
Решение, которое я пытаюсь развернуть, - это, конечно же, избавиться от этой дорогой чуши.
Я ничего не знаю о брандмауэрах Пало-Альто. но я точно знаю, что мы не можем направить трафик через туннель и ожидать, что он будет зашифрован. Мы должны указать это через список доступа к криптовалюте (или что-то подобное)