Comments 13
тунель asa-srx работает последние года 3 стабильно, года два назад переделал на vti
проблем с настройкой почти нет, если не лезть в нестандартные настройки.
из минусов — отвратительный дебаг на джунипере (да и на асе тоже) когда не совпадают параметры 1/2 — для того чтобы увидеть что посылается в качестве пропозалов и что настроено локально — приходится плясать с бубнами и лопатить тонны логов
проблем с настройкой почти нет, если не лезть в нестандартные настройки.
из минусов — отвратительный дебаг на джунипере (да и на асе тоже) когда не совпадают параметры 1/2 — для того чтобы увидеть что посылается в качестве пропозалов и что настроено локально — приходится плясать с бубнами и лопатить тонны логов
Возможно, роляют в т.ч. версии софта с обеих сторон, потому что у меня проблемы возникали частенько (основная — это кратковременное падение туннеля при регенерации).
С дебагом у меня проблем обычно не возникало — включаем debug ike и traceoptions (ну и debug на asa), и погнали. Ну да, «тонны логов», и прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно.
С дебагом у меня проблем обычно не возникало — включаем debug ike и traceoptions (ну и debug на asa), и погнали. Ну да, «тонны логов», и прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно.
на асе есть кондитион дебаг, что хоть как то лимитирует лог когда активных тунелей чуть больше чем десяток
а на джунипере нет, те на джуне нужно просматривать лог со всех впн тунелей, что для больших железок может быть слегка утомительно
> прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно
у меня была проблема когда не работал впн с vmware nxs (или как там эта их поделка под сеть называется) — я три дня убил на то чтобы понять что тунель не поднимится пока идл таймаут не поставишь на сессию. а говорил все тоже инкорект пропозал
а на джунипере нет, те на джуне нужно просматривать лог со всех впн тунелей, что для больших железок может быть слегка утомительно
> прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно
у меня была проблема когда не работал впн с vmware nxs (или как там эта их поделка под сеть называется) — я три дня убил на то чтобы понять что тунель не поднимится пока идл таймаут не поставишь на сессию. а говорил все тоже инкорект пропозал
Справедливости ради, первая фаза дебажится через 'request security ike debug local… remote ...', т.е. натравить можно на на конкретное соединение.
В traceoptions, ЕМНИП, тоже можно фильтры задавать
В traceoptions, ЕМНИП, тоже можно фильтры задавать
круто, нужно перечитать траблгайды
Когда-то давно я написал вот эту статью.
На полноту не претендую, но возможно будет полезна)
На полноту не претендую, но возможно будет полезна)
Не так давно подружил по IpSec Netgate 3100 и Juniper SRX100H2, искал долго и не мог найти примеров, пока не догадался что на netgate то крутится PfSense! А по такому тандему гайд сразу нашелся, и дело пошло веселее. Правильный вопрос — уже половина ответа.
В планах по IpSec добавить еще микротик в этот зоопарк.
В планах по IpSec добавить еще микротик в этот зоопарк.
Блин…
А я так ждал серебряной пули
Дочитал до конца, а ответа на вопрос почему оно падает не получил
У меня тоже в хозяйстве есть вечно падающий тунель SRX-ASA. С моей стороны SRX100.
Софт 12.3X48-D65.1, последний для этого железа.
С другой стороны какие то индусы у которых АСА по шаблону настроена и при этом у самих индусов ни доступа к асе нет ни параметров настройки. И вот оно падает раз в день два.
Но тунель используетс еще реже. Когда тунель нужен, то индусы пишут письмо, а я делаю
А между нормальными цисками (не АСА) никогда никаких проблем. Ну и джуники друг с другом отлично соседствуют
А я так ждал серебряной пули
Дочитал до конца, а ответа на вопрос почему оно падает не получил
У меня тоже в хозяйстве есть вечно падающий тунель SRX-ASA. С моей стороны SRX100.
Софт 12.3X48-D65.1, последний для этого железа.
С другой стороны какие то индусы у которых АСА по шаблону настроена и при этом у самих индусов ни доступа к асе нет ни параметров настройки. И вот оно падает раз в день два.
Но тунель используетс еще реже. Когда тунель нужен, то индусы пишут письмо, а я делаю
clear security ike security-associations <peer-ip>А между нормальными цисками (не АСА) никогда никаких проблем. Ну и джуники друг с другом отлично соседствуют
Вот ровно такие боли у меня обычно со связкой ASA<>SRX и бывают, да.
А тут прям удивился, что удалось собрать туннель, который не разваливается раз в сутки
А тут прям удивился, что удалось собрать туннель, который не разваливается раз в сутки
Убедитесь, что traffic selector`ы зеркальные с обеих сторон.
Может быть такое, что они не зеркальные, но «совместимые», когда несовпадение в масках. Тогда туннель будет подниматься, но с регенерацией будут проблемы.
Может быть такое, что они не зеркальные, но «совместимые», когда несовпадение в масках. Тогда туннель будет подниматься, но с регенерацией будут проблемы.
Решал несколько подобных кейсов при подключении ASA к Azure. Там логи норм ))
* Одна из проблем — когда на одной из сторон (ASA) включен PFS, на другой (Azure) — нет.
Тогда во время re-key, если его начинает Azure, то по странной причине ASA его принимает, но трафик ходить перестает, когда истекают старые ключи. Решение — выключить PFS. Или включить. На обеих сторонах.
* Можно подправить время lifetime — сделать его меньше на стороне ASA. Тогда этот процесс всегда будет начинаться со стороны Асы. Но это криво, т.к. не решает проблему, а просто делает её незаметной.
* Часто возникают проблемы с трафик селекторами, как и говорили выше. Они должны быть одинаковыми. В ином случае проблема будет сильно плавающей — в зависимости от того, какая сторона будет начинать re-key. А это будет зависеть от типа трафика.
Если ASA с новой прошивкой (>9.8), лучше использовать VTI и 0.0.0.0/0 трафик-селекторы с обеих сторон (а разрешать/запрещать через маршруты/ACL). Так, по крайней мере, одной проблемой меньше.
* Одна из проблем — когда на одной из сторон (ASA) включен PFS, на другой (Azure) — нет.
Тогда во время re-key, если его начинает Azure, то по странной причине ASA его принимает, но трафик ходить перестает, когда истекают старые ключи. Решение — выключить PFS. Или включить. На обеих сторонах.
* Можно подправить время lifetime — сделать его меньше на стороне ASA. Тогда этот процесс всегда будет начинаться со стороны Асы. Но это криво, т.к. не решает проблему, а просто делает её незаметной.
* Часто возникают проблемы с трафик селекторами, как и говорили выше. Они должны быть одинаковыми. В ином случае проблема будет сильно плавающей — в зависимости от того, какая сторона будет начинать re-key. А это будет зависеть от типа трафика.
Если ASA с новой прошивкой (>9.8), лучше использовать VTI и 0.0.0.0/0 трафик-селекторы с обеих сторон (а разрешать/запрещать через маршруты/ACL). Так, по крайней мере, одной проблемой меньше.
Не понимаю, в чем проблема с логами на Juniper SRX. Тот же ts mismatch — так и пишет в KMD-лог. Про ошибки в фазах — не поднимается — смотришь фазу в логах, просматриваешь все настройки по этой фазе.
PS: у traceoptions обратная ситуация, без фильтров информации слишком много, но это на случай сложного траблшутинга, как было недавно с dynamicVPN, что в итоге потом вышло в KB
PS: у traceoptions обратная ситуация, без фильтров информации слишком много, но это на случай сложного траблшутинга, как было недавно с dynamicVPN, что в итоге потом вышло в KB
Sign up to leave a comment.
Juniper SRX и Cisco ASA: серия очередная