Первый раз строить IPSec между Juniper SRX и Cisco ASA мне довелось ещё в далёком 2014 году. Уже тогда это было весьма болезненно, потому что проблем было много (обычно — разваливающийся при регенерации туннель), диагностировать было сложно (ASA стояла у нашего заказчика, поэтому возможности для дебага были ограничены), но как-то это работало.

image

С той поры и рекомендованный 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 86400

set 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 3600

set 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-14

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 "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 outside

set 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)


  1. extiander
    24.12.2019 10:37

    тунель asa-srx работает последние года 3 стабильно, года два назад переделал на vti
    проблем с настройкой почти нет, если не лезть в нестандартные настройки.
    из минусов — отвратительный дебаг на джунипере (да и на асе тоже) когда не совпадают параметры 1/2 — для того чтобы увидеть что посылается в качестве пропозалов и что настроено локально — приходится плясать с бубнами и лопатить тонны логов


    1. Night_Snake Автор
      24.12.2019 10:55

      Возможно, роляют в т.ч. версии софта с обеих сторон, потому что у меня проблемы возникали частенько (основная — это кратковременное падение туннеля при регенерации).

      С дебагом у меня проблем обычно не возникало — включаем debug ike и traceoptions (ну и debug на asa), и погнали. Ну да, «тонны логов», и прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно.


      1. extiander
        24.12.2019 13:59

        на асе есть кондитион дебаг, что хоть как то лимитирует лог когда активных тунелей чуть больше чем десяток

        а на джунипере нет, те на джуне нужно просматривать лог со всех впн тунелей, что для больших железок может быть слегка утомительно

        > прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно
        у меня была проблема когда не работал впн с vmware nxs (или как там эта их поделка под сеть называется) — я три дня убил на то чтобы понять что тунель не поднимится пока идл таймаут не поставишь на сессию. а говорил все тоже инкорект пропозал


        1. Night_Snake Автор
          24.12.2019 14:02

          Справедливости ради, первая фаза дебажится через 'request security ike debug local… remote ...', т.е. натравить можно на на конкретное соединение.
          В traceoptions, ЕМНИП, тоже можно фильтры задавать


          1. extiander
            24.12.2019 14:25

            круто, нужно перечитать траблгайды


            1. Night_Snake Автор
              24.12.2019 16:50

              Когда-то давно я написал вот эту статью.
              На полноту не претендую, но возможно будет полезна)


  1. Tufed
    24.12.2019 12:35
    +1

    Не так давно подружил по IpSec Netgate 3100 и Juniper SRX100H2, искал долго и не мог найти примеров, пока не догадался что на netgate то крутится PfSense! А по такому тандему гайд сразу нашелся, и дело пошло веселее. Правильный вопрос — уже половина ответа.
    В планах по IpSec добавить еще микротик в этот зоопарк.


    1. Night_Snake Автор
      24.12.2019 12:42

      По микротику тоже много гайдов (даже у меня есть парочка, хе-хе). Но там всё несколько веселее — с новыми версиями добавляются новые возможности, и старые гайды могут стать неактуальны или неоптимальны.


  1. iddqda
    24.12.2019 15:00
    +1

    Блин…
    А я так ждал серебряной пули
    Дочитал до конца, а ответа на вопрос почему оно падает не получил

    У меня тоже в хозяйстве есть вечно падающий тунель SRX-ASA. С моей стороны SRX100.
    Софт 12.3X48-D65.1, последний для этого железа.
    С другой стороны какие то индусы у которых АСА по шаблону настроена и при этом у самих индусов ни доступа к асе нет ни параметров настройки. И вот оно падает раз в день два.
    Но тунель используетс еще реже. Когда тунель нужен, то индусы пишут письмо, а я делаю

    clear security ike security-associations <peer-ip>


    А между нормальными цисками (не АСА) никогда никаких проблем. Ну и джуники друг с другом отлично соседствуют


    1. Night_Snake Автор
      24.12.2019 15:26

      Вот ровно такие боли у меня обычно со связкой ASA<>SRX и бывают, да.
      А тут прям удивился, что удалось собрать туннель, который не разваливается раз в сутки


    1. Rel1cto
      24.12.2019 15:48
      +1

      Убедитесь, что traffic selector`ы зеркальные с обеих сторон.
      Может быть такое, что они не зеркальные, но «совместимые», когда несовпадение в масках. Тогда туннель будет подниматься, но с регенерацией будут проблемы.


  1. 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). Так, по крайней мере, одной проблемой меньше.


  1. vertex4
    25.12.2019 17:44

    Не понимаю, в чем проблема с логами на Juniper SRX. Тот же ts mismatch — так и пишет в KMD-лог. Про ошибки в фазах — не поднимается — смотришь фазу в логах, просматриваешь все настройки по этой фазе.
    PS: у traceoptions обратная ситуация, без фильтров информации слишком много, но это на случай сложного траблшутинга, как было недавно с dynamicVPN, что в итоге потом вышло в KB