Первый раз строить IPSec между Juniper SRX и Cisco ASA мне довелось ещё в далёком 2014 году. Уже тогда это было весьма болезненно, потому что проблем было много (обычно — разваливающийся при регенерации туннель), диагностировать было сложно (ASA стояла у нашего заказчика, поэтому возможности для дебага были ограничены), но как-то это работало.
С той поры и рекомендованный JunOS для SRX обновился на 15.1 (для линейки SRX300, по крайней мере), и ASA научилась в route based IPSec (c версии софта 9.8), что несколько упрощает настройку. И вот на текущей работе не так давно представился шанс снова собрать такую схему. И снова неудачно — при регенерации туннель благополучно падал (и не всегда поднимался без ручного рестарта). И снова в логах тишина и непонятки, а т.к. ASA находилась у нашего партнёра, то и дебажить, соответственно, не было никакой возможности.
И вот теперь представился случай собрать схему, при которой обе стороны (и SRX, и ASA) находятся под нашим управлением, соответственно, поиграться можно на славу.
Итак, что у нас имеется:
Начнём с конфигурации SRX. У меня довольно много различных туннелей строится именно на нём, в итоге я пришёл примерно к такой схеме:
Видно, что используется IKEv2, без traffic-selectors (у нас в арсенале и без того достаточно средств, чтобы ограничить хождение трафика — от префикс-листов BGP до security policies). До кучи используется DPD (dead peer detection) и vpn-monitor (у них немного разный тип проверок, для надёжности я использую оба).
Конфигурация ASA:
Структура конфигов примерно одинаковая на обоих роутерах, но, как обычно, название секций не совпадают совершенно.Давайте пробежимся, что чему соответствует.
Здесь начинается некоторая путаница в терминологии. То, что у Cisco называется IKE policy, у Juniper — IKE Proposal. А IKE policy у Juniper похоже на tunnel group у ASA… Лично мне больше нравится подход Juniper, но тут, безусловно, дело привычки.
Надо сказать, настройка IKEv2 (тем более route based) на ASA выглядит всё же куда логичнее, чем crypto maps и прочее безобразие, которое было раньше.
Здесь оба вендора делают плюс-минус одинаково — сначала создаём proposal с параметрами шифрования/аутентификации, а потом навешиваем на него lifetime и pfs.
А здесь отличия уже более явные. На ASA PSK указывается непосредственно в настройках пира. Juniper же позволяет здесь задать и исходящий интерфейс и дополнительные опции типа local-identity, плюс ссылается на ike policy (где мы указывали PSK).
Кстати, если вы захотите переделать на ASA IKEv2 в IKEv1 (и наоборот), то у Cisco надо будет пересоздавать всю tunnel-group. А на SRX всего лишь сменить одну опцию. (Правда, далее при commit могут вылезти несовместимые опции, но это уже детали)
И снова конфиг Juniper мне кажется более логичным. VPN настраивается отдельно (он может быть и policy-based), сам security tunnel — отдельно. Отдельное спасибо за «establish-tunnels immediately». Очень полезная опция ;) (цисководы поймут, о чём я). Ещё один «бонус» SRX — можно строить многоточечные IPSec, как с автообнаружением пиров (работает, к сожалению, только между SRX), так с ручным роутингом. Это, конечно, не полноценный DMVPN, но жизнь в сетапах типа «один центр — много филиалов» значительно облегчает.
Отдельно остановлюсь на настройке интерфейсов, на которых строится IPSec. У Juniper это, соответственно, ae0.4, у ASA — outside
На интерфейсах нужно разрешить ike, иначе работать ничего не будет :) Дополнительно, у SRX нужно для туннельного интерфейса разрешить bgp/ospf/whatever для входящих подключений на st0.x интерфейсе.
Тут всё довольно банально (с одной стороны)
На ASA отдаём агрегированный префикс нашей локалки — у меня это будет 10/8. От ASA ничего не принимаем, потому что с версии софта 9.8.4 всё равно нельзя анонсировать по BGP адреса management-интерфейсов (что объяснимо) и BVI (что жутко неудобно). Но если у вас за ASA есть ещё какие-то сети, их нужно будет добавить в policy, конечно.
Чтобы «увидеть» inside интерфейс, нужно будет на SRX прописать static route в сторону ipsec:
Вдобавок, ASA до сих пор не умеет в loopback интерфейсы, поэтому все логи/netflow и прочая мы будем отправлять с inside.
В ASA5506 есть встроенный свич, поэтому можно использовать виртуальный BVI-интерфейс (особенно полезно, когда у вас схема «роутер-на-палочке», и используется всего лишь один физический порт.
После этого в нужных местах (logging, snmp, flow) в качестве интерфейса-источника нужно будет указать `inside`.
Первое — у вас должны установиться обе фазы IPSec (у Juniper это, собственно, IKE/IPSec).
Смотрим:
На ASA:
У Juniper ещё можно посмотреть статистику по ipsec-туннелю, включая причины падения:
Если с IPSec всё в порядке, то нужно смотреть на ACL (security policies, host-inbound правила и т.д.). На крайней случай, можно попробовать перезагрузить коробку (ASA) — мне, бывало, помогает.
UPD: Про дебаг IPsec в Juniper я уже присал на Хабр тут
Здесь всё довольно стандартно — если сессия не устанавливается, можно посмотреть через capture, летят ли BGP-hello в обе стороны.
На этом всё. Не знаю, виной ли тому новый софт, или звёзды так сошлись — но туннель ASA<>SRX держится стабильно и не падает раз в сутки, как было раньше.
Надеюсь, у вас тоже всё получится!
С той поры и рекомендованный JunOS для SRX обновился на 15.1 (для линейки SRX300, по крайней мере), и ASA научилась в route based IPSec (c версии софта 9.8), что несколько упрощает настройку. И вот на текущей работе не так давно представился шанс снова собрать такую схему. И снова неудачно — при регенерации туннель благополучно падал (и не всегда поднимался без ручного рестарта). И снова в логах тишина и непонятки, а т.к. ASA находилась у нашего партнёра, то и дебажить, соответственно, не было никакой возможности.
И вот теперь представился случай собрать схему, при которой обе стороны (и SRX, и ASA) находятся под нашим управлением, соответственно, поиграться можно на славу.
Диспозиция
Итак, что у нас имеется:
- Juniper SRX340 (JunOS 15.1X49D150.2)
- Cisco ASA 5506 (софт 9.8.4)
- route based IPSec между ними (роутинг будет обеспечиваться BGP, о нём тоже скажу пару слов)
Схема
Конфигурация
Juniper
Начнём с конфигурации SRX. У меня довольно много различных туннелей строится именно на нём, в итоге я пришёл примерно к такой схеме:
set security ike policy IKE-ASA mode main
set security ike policy IKE-ASA proposals SHA256-AES128-5-86400
set security ike policy IKE-ASA pre-shared-key ascii-text ...
set security ike gateway GW-ASA ike-policy IKE-ASA
set security ike gateway GW-ASA address 192.0.2.2
set security ike gateway GW-ASA dead-peer-detection interval 10
set security ike gateway GW-ASA dead-peer-detection threshold 3
set security ike gateway GW-ASA local-identity inet 198.51.100.2
set security ike gateway GW-ASA external-interface ae0.4
set security ike gateway GW-ASA version v2-only
set security ipsec vpn VPN-ASA bind-interface st0.7
set security ipsec vpn VPN-ASA df-bit clear
set security ipsec vpn VPN-ASA vpn-monitor source-interface st0.7
set security ipsec vpn VPN-ASA vpn-monitor destination-ip 169.254.100.2
set security ipsec vpn VPN-ASA ike gateway GW-ASA
set security ipsec vpn VPN-ASA ike ipsec-policy SHA256-AES128-3600-14-policy
set security ipsec vpn VPN-ASA establish-tunnels immediately
set interfaces st0 unit 7 description "ASA AnyConnect router"
set interfaces st0 unit 7 family inet mtu 1436
set interfaces st0 unit 7 family inet address 169.254.100.1/30
set routing-options static route 192.0.2.2/32 next-hop 198.51.100.1
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services ping
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services ike
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services traceroute
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic protocols bgp
Видно, что используется IKEv2, без traffic-selectors (у нас в арсенале и без того достаточно средств, чтобы ограничить хождение трафика — от префикс-листов BGP до security policies). До кучи используется DPD (dead peer detection) и vpn-monitor (у них немного разный тип проверок, для надёжности я использую оба).
Cisco
Конфигурация ASA:
crypto ipsec ikev2 ipsec-proposal SHA256-AES128
protocol esp encryption aes-256 aes-192 aes
protocol esp integrity sha-256
crypto ipsec profile IPSEC-PROFILE-AMS1-VPN2
set ikev2 ipsec-proposal SHA256-AES128
set pfs group14
set security-association lifetime kilobytes unlimited
set security-association lifetime seconds 3600
crypto ikev2 policy 1
encryption aes-256 aes-192 aes
integrity sha256
group 5
prf sha256
lifetime seconds 86400
tunnel-group 198.51.100.2 type ipsec-l2l
tunnel-group 198.51.100.2 ipsec-attributes
isakmp keepalive threshold 30 retry 10
ikev2 remote-authentication pre-shared-key ...
ikev2 local-authentication pre-shared-key ...
crypto ikev2 enable outside
interface Tunnel7
nameif l2l-ams1-vpn2
ip address 169.254.100.2 255.255.255.252
tunnel source interface outside
tunnel destination 198.51.100.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC-PROFILE-AMS1-VPN2Структура конфигов примерно одинаковая на обоих роутерах, но, как обычно, название секций не совпадают совершенно.Давайте пробежимся, что чему соответствует.
Сравнение конфигов
IKE policy / proposal
crypto ikev2 policy 1
encryption aes-256 aes-192 aes
integrity sha256
group 5
prf sha256
lifetime seconds 86400set security ike proposal SHA256-AES128-5-86400 description ike-phase1-proposal1
set security ike proposal SHA256-AES128-5-86400 authentication-method pre-shared-keys
set security ike proposal SHA256-AES128-5-86400 dh-group group5
set security ike proposal SHA256-AES128-5-86400 authentication-algorithm sha-256
set security ike proposal SHA256-AES128-5-86400 encryption-algorithm aes-128-cbc
set security ike proposal SHA256-AES128-5-86400 lifetime-seconds 86400
set security ike policy IKE-ASA mode main
set security ike policy IKE-ASA proposals SHA256-AES128-5-86400
set security ike policy IKE-ASA pre-shared-key ascii-text ...
Здесь начинается некоторая путаница в терминологии. То, что у Cisco называется IKE policy, у Juniper — IKE Proposal. А IKE policy у Juniper похоже на tunnel group у ASA… Лично мне больше нравится подход Juniper, но тут, безусловно, дело привычки.
Надо сказать, настройка IKEv2 (тем более route based) на ASA выглядит всё же куда логичнее, чем crypto maps и прочее безобразие, которое было раньше.
IPSec policy/proposal
crypto ipsec ikev2 ipsec-proposal SHA256-AES128
protocol esp encryption aes-256 aes-192 aes
protocol esp integrity sha-256
crypto ipsec profile IPSEC-PROFILE-SHA256-AES128-3600-14
set ikev2 ipsec-proposal SHA256-AES128
set pfs group14
set security-association lifetime kilobytes unlimited
set security-association lifetime seconds 3600set security ipsec proposal SHA256-AES128-3600 description ipsec-phase2-proposal
set security ipsec proposal SHA256-AES128-3600 protocol esp
set security ipsec proposal SHA256-AES128-3600 authentication-algorithm hmac-sha-256-128
set security ipsec proposal SHA256-AES128-3600 encryption-algorithm aes-128-cbc
set security ipsec proposal SHA256-AES128-3600 lifetime-seconds 3600
set security ipsec policy SHA256-AES128-3600-14-policy description SHA256-AES128-3600-14-policy
set security ipsec policy SHA256-AES128-3600-14-policy perfect-forward-secrecy keys group14
set security ipsec policy SHA256-AES128-3600-14-policy proposals SHA256-AES128-3600Здесь оба вендора делают плюс-минус одинаково — сначала создаём proposal с параметрами шифрования/аутентификации, а потом навешиваем на него lifetime и pfs.
Gateway
tunnel-group 198.51.100.2 type ipsec-l2l
tunnel-group 198.51.100.2 ipsec-attributes
isakmp keepalive threshold 30 retry 10
ikev2 remote-authentication pre-shared-key ...
ikev2 local-authentication pre-shared-key ...set security ike gateway GW-ASA ike-policy IKE-ASA-LEGAL
set security ike gateway GW-ASA address 192.0.2.2
set security ike gateway GW-ASA dead-peer-detection interval 10
set security ike gateway GW-ASA dead-peer-detection threshold 3
set security ike gateway GW-ASA local-identity inet 198.51.100.2
set security ike gateway GW-ASA external-interface ae0.4
set security ike gateway GW-ASA version v2-onlyА здесь отличия уже более явные. На ASA PSK указывается непосредственно в настройках пира. Juniper же позволяет здесь задать и исходящий интерфейс и дополнительные опции типа local-identity, плюс ссылается на ike policy (где мы указывали PSK).
Кстати, если вы захотите переделать на ASA IKEv2 в IKEv1 (и наоборот), то у Cisco надо будет пересоздавать всю tunnel-group. А на SRX всего лишь сменить одну опцию. (Правда, далее при commit могут вылезти несовместимые опции, но это уже детали)
VPN / VTI
interface Tunnel7
nameif l2l-ams1-vpn2
ip address 169.254.100.2 255.255.255.252
tunnel source interface outside
tunnel destination 198.51.100.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC-PROFILE-SHA256-AES128-3600-14set security ipsec vpn VPN-ASA bind-interface st0.7
set security ipsec vpn VPN-ASA df-bit clear
set security ipsec vpn VPN-ASA vpn-monitor source-interface st0.7
set security ipsec vpn VPN-ASA vpn-monitor destination-ip 169.254.100.2
set security ipsec vpn VPN-ASA ike gateway GW-ASA
set security ipsec vpn VPN-ASA ike ipsec-policy SHA256-AES128-3600-14-policy
set security ipsec vpn VPN-ASA establish-tunnels immediately
set interfaces st0 unit 7 description "AnyConnect router"
set interfaces st0 unit 7 family inet mtu 1436
set interfaces st0 unit 7 family inet address 169.254.100.1/30И снова конфиг Juniper мне кажется более логичным. VPN настраивается отдельно (он может быть и policy-based), сам security tunnel — отдельно. Отдельное спасибо за «establish-tunnels immediately». Очень полезная опция ;) (цисководы поймут, о чём я). Ещё один «бонус» SRX — можно строить многоточечные IPSec, как с автообнаружением пиров (работает, к сожалению, только между SRX), так с ручным роутингом. Это, конечно, не полноценный DMVPN, но жизнь в сетапах типа «один центр — много филиалов» значительно облегчает.
Interfaces
Отдельно остановлюсь на настройке интерфейсов, на которых строится IPSec. У Juniper это, соответственно, ae0.4, у ASA — outside
crypto ikev2 enable outsideset security zones security-zone ZONE-INTERNET interfaces ae0.4 host-inbound-traffic system-services ike
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services ping
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic system-services traceroute
set security zones security-zone ZONE-VPN interfaces st0.7 host-inbound-traffic protocols bgpНа интерфейсах нужно разрешить ike, иначе работать ничего не будет :) Дополнительно, у SRX нужно для туннельного интерфейса разрешить bgp/ospf/whatever для входящих подключений на st0.x интерфейсе.
Настройка BGP
Тут всё довольно банально (с одной стороны)
set protocols bgp group ASA type external
set protocols bgp group ASA description "AnyConnect router"
set protocols bgp group ASA hold-time 30
set protocols bgp group ASA import IMPORT-EBGP-ASA
set protocols bgp group ASA export EXPORT-EBGP-ASA
set protocols bgp group ASA local-as 64666
set protocols bgp group ASA neighbor 169.254.100.2 peer-as 65001
set policy-options policy-statement EXPORT-EBGP-ASA term 0 from route-filter 10.0.0.0/8 exact
set policy-options policy-statement EXPORT-EBGP-ASA term 0 then accept
set policy-options policy-statement EXPORT-EBGP-ASA term 1 then reject
set policy-options policy-statement IMPORT-EBGP-ASA term 1 then rejectНа ASA отдаём агрегированный префикс нашей локалки — у меня это будет 10/8. От ASA ничего не принимаем, потому что с версии софта 9.8.4 всё равно нельзя анонсировать по BGP адреса management-интерфейсов (что объяснимо) и BVI (что жутко неудобно). Но если у вас за ASA есть ещё какие-то сети, их нужно будет добавить в policy, конечно.
asa(config-router-af)# network 10.255.32.252 mask 255.255.255.254
ERROR: BGP configuration not supported on management-only/BVI interfaceЧтобы «увидеть» inside интерфейс, нужно будет на SRX прописать static route в сторону ipsec:
set routing-options static route 10.255.32.252/31 next-hop 169.254.100.2Вдобавок, ASA до сих пор не умеет в loopback интерфейсы, поэтому все логи/netflow и прочая мы будем отправлять с inside.
В ASA5506 есть встроенный свич, поэтому можно использовать виртуальный BVI-интерфейс (особенно полезно, когда у вас схема «роутер-на-палочке», и используется всего лишь один физический порт.
interface BVI1
nameif inside
security-level 100
ip address 10.255.32.253 255.255.255.254
management-access insideПосле этого в нужных местах (logging, snmp, flow) в качестве интерфейса-источника нужно будет указать `inside`.
Если что-то пошло не так a.k.a. troubleshooting
IKE/IPSec
Первое — у вас должны установиться обе фазы IPSec (у Juniper это, собственно, IKE/IPSec).
Смотрим:
admin@srx> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
2128190 UP ae7d7d447326218a 2be3b3004ae0e36a IKEv2 192.0.2.2
admin@srx> show security ipsec security-associations
Total active tunnels: 6
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<131077 ESP:aes-cbc-128/sha256 fec3c7d1 2867/ unlim U root 500 192.0.2.2
>131077 ESP:aes-cbc-128/sha256 74d792ca 2867/ unlim U root 500 192.0.2.2 На ASA:
asa# sho crypto ikev2 sa
IKEv2 SAs:
Session-id:5, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
585564345 192.0.2.2/500 198.51.100.2/500 READY RESPONDER
Encr: AES-CBC, keysize: 128, Hash: SHA256, DH Grp:5, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/47018 sec
Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0xc989d9ea/0xcca8b6d5У Juniper ещё можно посмотреть статистику по ipsec-туннелю, включая причины падения:
admin@srx> show security ipsec security-associations index 131078 detail
ID: 131078 Virtual-system: root, VPN Name: VPN-ASA-LEGAL-PL
Local Gateway: 198.51.100.2, Remote Gateway: 192.0.2.2
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Version: IKEv2
DF-bit: clear, Copy-Outer-DSCP Disabled, Bind-interface: st0.7
Port: 500, Nego#: 734, Fail#: 0, Def-Del#: 0 Flag: 0x600a29
Tunnel events:
Mon Dec 09 2019 13:40:35: IPSec SA rekey successfully completed (48 times)
Mon Dec 09 2019 00:30:47: IKE SA rekey successfully completed (10 times)
Fri Nov 29 2019 02:13:55: IPSec SA negotiation successfully completed (1 times)
Fri Nov 29 2019 02:13:55: IKE SA negotiation successfully completed (1 times)
Fri Nov 29 2019 02:13:55: No response from peer. Negotiation failed (7 times)
Fri Nov 29 2019 02:10:14: DPD detected peer as down. Existing IKE/IPSec SAs cleared (1 times)
Fri Nov 29 2019 01:39:15: IPSec SA rekey successfully completed (1 times)
Fri Nov 29 2019 00:49:50: IPSec SA negotiation successfully completed (1 times)
Fri Nov 29 2019 00:49:50: IKE SA negotiation successfully completed (1 times)
Fri Nov 29 2019 00:49:30: No response from peer. Negotiation failed (23 times)
Fri Nov 29 2019 00:37:24: DPD detected peer as down. Existing IKE/IPSec SAs cleared (1 times)
Fri Nov 29 2019 00:30:00: IPSec SA rekey successfully completed (77 times)
Thu Nov 28 2019 20:11:31: IKE SA rekey successfully completed (7 times)
Tue Nov 26 2019 08:51:44: IPSec SA negotiation successfully completed (1 times)
Thu Nov 21 2019 21:24:32: IKE SA negotiation successfully completed (1 times)
Thu Nov 21 2019 01:06:27: IKE SA rekey successfully completed (6 times)
Direction: inbound, SPI: 4bd2e2bd, AUX-SPI: 0
, VPN Monitoring: UP
Hard lifetime: Expires in 3132 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2495 seconds
Mode: Tunnel(10 10), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: 504f306e, AUX-SPI: 0
, VPN Monitoring: UP
Hard lifetime: Expires in 3132 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2495 seconds
Mode: Tunnel(10 10), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Если с IPSec всё в порядке, то нужно смотреть на ACL (security policies, host-inbound правила и т.д.). На крайней случай, можно попробовать перезагрузить коробку (ASA) — мне, бывало, помогает.
UPD: Про дебаг IPsec в Juniper я уже присал на Хабр тут
BGP
Здесь всё довольно стандартно — если сессия не устанавливается, можно посмотреть через capture, летят ли BGP-hello в обе стороны.
Итого
На этом всё. Не знаю, виной ли тому новый софт, или звёзды так сошлись — но туннель ASA<>SRX держится стабильно и не падает раз в сутки, как было раньше.
Надеюсь, у вас тоже всё получится!
Комментарии (13)
Tufed
24.12.2019 12:35+1Не так давно подружил по IpSec Netgate 3100 и Juniper SRX100H2, искал долго и не мог найти примеров, пока не догадался что на netgate то крутится PfSense! А по такому тандему гайд сразу нашелся, и дело пошло веселее. Правильный вопрос — уже половина ответа.
В планах по IpSec добавить еще микротик в этот зоопарк.
Night_Snake Автор
24.12.2019 12:42По микротику тоже много гайдов (даже у меня есть парочка, хе-хе). Но там всё несколько веселее — с новыми версиями добавляются новые возможности, и старые гайды могут стать неактуальны или неоптимальны.
iddqda
24.12.2019 15:00+1Блин…
А я так ждал серебряной пули
Дочитал до конца, а ответа на вопрос почему оно падает не получил
У меня тоже в хозяйстве есть вечно падающий тунель SRX-ASA. С моей стороны SRX100.
Софт 12.3X48-D65.1, последний для этого железа.
С другой стороны какие то индусы у которых АСА по шаблону настроена и при этом у самих индусов ни доступа к асе нет ни параметров настройки. И вот оно падает раз в день два.
Но тунель используетс еще реже. Когда тунель нужен, то индусы пишут письмо, а я делаюclear security ike security-associations <peer-ip>
А между нормальными цисками (не АСА) никогда никаких проблем. Ну и джуники друг с другом отлично соседствуютNight_Snake Автор
24.12.2019 15:26Вот ровно такие боли у меня обычно со связкой ASA<>SRX и бывают, да.
А тут прям удивился, что удалось собрать туннель, который не разваливается раз в сутки
Rel1cto
24.12.2019 15:48+1Убедитесь, что traffic selector`ы зеркальные с обеих сторон.
Может быть такое, что они не зеркальные, но «совместимые», когда несовпадение в масках. Тогда туннель будет подниматься, но с регенерацией будут проблемы.
mobileha
25.12.2019 11:53+1Решал несколько подобных кейсов при подключении ASA к Azure. Там логи норм ))
* Одна из проблем — когда на одной из сторон (ASA) включен PFS, на другой (Azure) — нет.
Тогда во время re-key, если его начинает Azure, то по странной причине ASA его принимает, но трафик ходить перестает, когда истекают старые ключи. Решение — выключить PFS. Или включить. На обеих сторонах.
* Можно подправить время lifetime — сделать его меньше на стороне ASA. Тогда этот процесс всегда будет начинаться со стороны Асы. Но это криво, т.к. не решает проблему, а просто делает её незаметной.
* Часто возникают проблемы с трафик селекторами, как и говорили выше. Они должны быть одинаковыми. В ином случае проблема будет сильно плавающей — в зависимости от того, какая сторона будет начинать re-key. А это будет зависеть от типа трафика.
Если ASA с новой прошивкой (>9.8), лучше использовать VTI и 0.0.0.0/0 трафик-селекторы с обеих сторон (а разрешать/запрещать через маршруты/ACL). Так, по крайней мере, одной проблемой меньше.
vertex4
25.12.2019 17:44Не понимаю, в чем проблема с логами на Juniper SRX. Тот же ts mismatch — так и пишет в KMD-лог. Про ошибки в фазах — не поднимается — смотришь фазу в логах, просматриваешь все настройки по этой фазе.
PS: у traceoptions обратная ситуация, без фильтров информации слишком много, но это на случай сложного траблшутинга, как было недавно с dynamicVPN, что в итоге потом вышло в KB
extiander
тунель asa-srx работает последние года 3 стабильно, года два назад переделал на vti
проблем с настройкой почти нет, если не лезть в нестандартные настройки.
из минусов — отвратительный дебаг на джунипере (да и на асе тоже) когда не совпадают параметры 1/2 — для того чтобы увидеть что посылается в качестве пропозалов и что настроено локально — приходится плясать с бубнами и лопатить тонны логов
Night_Snake Автор
Возможно, роляют в т.ч. версии софта с обеих сторон, потому что у меня проблемы возникали частенько (основная — это кратковременное падение туннеля при регенерации).
С дебагом у меня проблем обычно не возникало — включаем debug ike и traceoptions (ну и debug на asa), и погнали. Ну да, «тонны логов», и прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно.
extiander
на асе есть кондитион дебаг, что хоть как то лимитирует лог когда активных тунелей чуть больше чем десяток
а на джунипере нет, те на джуне нужно просматривать лог со всех впн тунелей, что для больших железок может быть слегка утомительно
> прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно
у меня была проблема когда не работал впн с vmware nxs (или как там эта их поделка под сеть называется) — я три дня убил на то чтобы понять что тунель не поднимится пока идл таймаут не поставишь на сессию. а говорил все тоже инкорект пропозал
Night_Snake Автор
Справедливости ради, первая фаза дебажится через 'request security ike debug local… remote ...', т.е. натравить можно на на конкретное соединение.
В traceoptions, ЕМНИП, тоже можно фильтры задавать
extiander
круто, нужно перечитать траблгайды
Night_Snake Автор
Когда-то давно я написал вот эту статью.
На полноту не претендую, но возможно будет полезна)