ASAトンネルは稼働しますが、トラフィックは通過しません

私はStrongswanを実行しているpfSenseとIP 9.8.7.6のCisco ASA 5512に戻るIKEv2 IPSecトンネルを持つそれぞれ2つのオフィス(IP 1.2.3.4のビクトリアとIP 5.6.7.8のトロント)を持っています。私は最近ASAのソフトウェアを9.4.2(11)から9.4.3(4)に問題なくアップデートしました。両方のトンネルが復旧して1日と17時間稼働しましたが、どちらの設定も変更されていなくても、ビクトリアトンネルはトラフィックを停止しました。

トンネルは問題なく確立されますが、 show ipsec sa はトラフィックが通過していないことを通知します。トンネルを再起動しても差はありません。

ASA1# show ipsec sa peer 1.2.3.4
peer address: 1.2.3.4
    Crypto map tag: OUTSIDE_map, seq num: 1, local addr: 9.8.7.6

      access-list OUTSIDE_cryptomap_2 extended permit ip 192.168.242.0 255.255.255.0 192.168.244.0 255.255.255.0 
      local ident (addr/mask/prot/port): (192.168.242.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.244.0/255.255.255.0/0/0)
      current_peer: 1.2.3.4


      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 1428, #pkts decrypt: 1428, #pkts verify: 1428
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 9.8.7.6/500, remote crypto endpt.: 1.2.3.4/500
      path mtu 1500, ipsec overhead 55(36), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: CB3A6309
      current inbound spi : 5E3D8A13

    inbound esp sas:
      spi: 0x5E3D8A13 (1581091347)
         transform: esp-aes-gcm-256 esp-null-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 14, IKEv2, }
         slot: 0, conn_id: 167936, crypto-map: OUTSIDE_map
         sa timing: remaining key lifetime (sec): 2676
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0xCB3A6309 (3409601289)
         transform: esp-aes-gcm-256 esp-null-hmac no compression 
         in use settings ={L2L, Tunnel, PFS Group 14, IKEv2, }
         slot: 0, conn_id: 167936, crypto-map: OUTSIDE_map
         sa timing: remaining key lifetime (sec): 2676
         IV size: 8 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x00000001

ドロップされたパケットを探すパケットキャプチャは私にこれを与えますが、どのようなルールが適用されているかはわかりません。

939: 20:11:44.438591 0023.ab3f.8255 24e9.b315.cddf 0x0800 Length: 89
      192.168.244.114.51353 > 192.168.242.200.53:  [no cksum] udp 47 [tos 0x10]  (ttl 63, id 8826) Drop-reason: (acl-drop) Flow is denied by configured rule

関連する設定のいくつかを以下に示します。私が見る限り、両方のオフィスは同じです。もし誰かが何が起こっているのかについて何か提案があれば、それを感謝します!

ASA1# show running-config crypto map
crypto map OUTSIDE_map 1 match address OUTSIDE_cryptomap_2
crypto map OUTSIDE_map 1 set pfs group14
crypto map OUTSIDE_map 1 set peer 1.2.3.4
crypto map OUTSIDE_map 1 set ikev2 ipsec-proposal AESGCM
crypto map OUTSIDE_map 1 set security-association lifetime seconds 3600
crypto map OUTSIDE_map 1 set nat-t-disable
crypto map OUTSIDE_map 2 match address OUTSIDE_cryptomap_3
crypto map OUTSIDE_map 2 set pfs group14
crypto map OUTSIDE_map 2 set peer 5.6.7.8
crypto map OUTSIDE_map 2 set ikev2 ipsec-proposal AESGCM
crypto map OUTSIDE_map 2 set security-association lifetime seconds 3600
crypto map OUTSIDE_map 2 set nat-t-disable
crypto map OUTSIDE_map interface OUTSIDE

ASA1# show running-config access-list OUTSIDE_cryptomap_2
access-list OUTSIDE_cryptomap_2 extended permit ip object NOC-network object Victoria-network

ASA1# show running-config access-list OUTSIDE_cryptomap_3
access-list OUTSIDE_cryptomap_3 extended permit ip object NOC-network object Toronto-network

ASA1# show running-config nat
nat (INSIDE,OUTSIDE) source static NOC-network NOC-network destination static Victoria-network Victoria-network no-proxy-arp route-lookup
nat (INSIDE,OUTSIDE) source static NOC-network NOC-network destination static Toronto-network Toronto-network no-proxy-arp route-lookup

ASA1# show running-config tunnel-group 
tunnel-group 1.2.3.4 type ipsec-l2l
tunnel-group 1.2.3.4 general-attributes
 default-group-policy GroupPolicy_Victoria
tunnel-group 1.2.3.4 ipsec-attributes
 ikev1 pre-shared-key *****
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****
tunnel-group 5.6.7.8 type ipsec-l2l
tunnel-group 5.6.7.8 general-attributes
 default-group-policy GroupPolicy_Toronto
tunnel-group 5.6.7.8 ipsec-attributes
 ikev1 pre-shared-key *****
 isakmp keepalive threshold 15 retry 2
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****

ASA1# show running-config crypto ikev2
crypto ikev2 policy 2
 encryption aes-gcm-256
 integrity null
 group 21 24
 prf sha512
 lifetime seconds 28800
crypto ikev2 policy 3
 encryption aes-256
 integrity sha512
 group 21 24
 prf sha512
 lifetime seconds 28800
crypto ikev2 enable OUTSIDE

ASA1# show running-config crypto ipsec
crypto ipsec ikev2 ipsec-proposal AES256-SHA512
 protocol esp encryption aes-256
 protocol esp integrity sha-512
crypto ipsec ikev2 ipsec-proposal AESGCM
 protocol esp encryption aes-gcm-256
 protocol esp integrity sha-512
crypto ipsec ikev2 sa-strength-enforcement
crypto ipsec security-association pmtu-aging infinite

#ASA1 show running-config all sysopt
no sysopt traffic detailed-statistics
no sysopt connection timewait
sysopt connection tcpmss 1380
sysopt connection tcpmss minimum 0
sysopt connection permit-vpn
sysopt connection reclassify-vpn
no sysopt connection preserve-vpn-flows
no sysopt radius ignore-secret
no sysopt noproxyarp OUTSIDE
no sysopt noproxyarp INSIDE
no sysopt noproxyarp DMZ1
no sysopt noproxyarp management
1
実際にはVPN設定が正しいように見えますが、外部インターフェイスのアクセスリストはトラフィックを拒否しています。 ACLがトラフィックを許可するかどうか、または sysopt connection permit-vpn が有効かどうかを再度確認します。あなたがコマンドが何をしているかを完全に理解していない限り、すぐに有効にしないでください。
追加された 著者 IanW,
@ miken32:いいえ、ACLはインバウンド方向の外部インターフェイスに接続されていることを意味します。 permit-vpnオプションが設定されていないため、通常のインターフェイスACLでトラフィックを許可する必要があります。
追加された 著者 IanW,
はい、それは実際に私が意味するものです。 sysopt connection permit-vpn が設定されていない場合(つまり、 no sysopt connection permit-vpn がアクティブな場合)、インターフェイスに接続されたACLのトラフィックを許可する必要があります。 VPNトンネルが入ります。 show run all sysopt
追加された 著者 IanW,
あなたは何も変わったとは言いませんが、私が今までに遭遇した事例の99%で、誰かが何かを変えました。これらの種類のものは、単に起伏しているだけではありません。最初に確認するのは、VPNのトラフィックが実際にエンドからエンドに向かっていることです。つまり、暗号化後の「インターネット」エンドからのtcpdumpです。次に、トンネルを出入りするトラフィックを調べます。等。
追加された 著者 Neall,
明示的に許可されない限り、ICMPは常に拒否されます。これはアクセスリストとは別です。
追加された 著者 Ron Trunk,
@RickyBeam私はこの会社の中でこれらに触れる唯一の人です。私はインターネットを1分使用していましたが、次に死んでいました。私が言ったように、私はASAのソフトウェアをアップグレードしました。トンネルが落ちたときの稼働時間は41時間でした。 ASAの内部インターフェイスでpingを実行しようとすると、エラーログに示されるように、トラフィックがトンネルを通過しています。
追加された 著者 Rob,
@ waza-ariこの設定は現在有効になっておらず、もう一方のトンネルはうまく動作しています。 access-list OUTSIDE_cryptomap_2 はそのトラフィックを処理する必要がありますが、正しいですか?サブネットが正しいことを確認しました。
追加された 著者 Rob,
トンネル経由でpingを実行しようとしている場合、 ICMP の拒否ログメッセージは、VPNトラフィックが侵入していて、トンネルが立ち上がっている。プライベートな Victoria-network サブネットを私の公開OUTSIDEインターフェイスに許可するエントリが必要だと言っていますか?
追加された 著者 Rob,
@ waza-ari申し訳ありませんが、 sysopt connection permit-vpn sysopt connection reclassify-vpn の両方が有効になっています。 no コマンドは実行コンフィギュレーションにありませんでした。
追加された 著者 Rob,
私はちょうど参加したので、コメントするのに十分な担当者がいないので、これをコメントに移して、より適切であると思うようにしてください。この問題が修正された場合(または方法)、​​またはまだトラブルシューティングを行っている場合は聞いてもらえます(希望しません)。 Nickが提案したように、パケットトレーサを試してみました。 tcp内のパケットトレーサ入力192.168.242.1 1234 192.168.244.1 2345
追加された 著者 hertitu,
#pkts encaps:0、#pkts encrypt:0、#pkts digest:0は非常に疑わしいです。 ASAがリモートエンドに送信するトラフィックを暗号化していないように見えます。それはNATのためか192.168.242.0/24のホストが192.168.244.0/24に達するためにASAに行くことを知らないので起こる可能性があります。 192.168.242.0のASAの後ろにあるホストから192.168.244.0に向かってtracerouteすると、ASAに到達しますか?
追加された 著者 かわいい,

1 答え

あなたのシナリオは、有効なアクティブなSPIを「切り捨て」している古いSPIをASAに持っている場合に見られるものと非常によく似ています。悪いことには、これが当てはまる場合は、ASA自体をリブートすることによってのみこれを修正することができます。

試みることのできるものは、パケットトレーサを実行してトラフィックをシミュレートし、出力に「VPN暗号化フェーズ」が表示されていることを確認することです。そうしても、トラフィックが暗号化に失敗した場合、アクティブではない無効なSPIと一致する可能性があります。

show asp table classify crypto を使用して、暗号化ドメインで一致するものを探すこともできます。同じ cs_id で複数の一致を見たくない場合。次の例を参照してください(これらのネットワークはまったく同じですが、異なる cs_id を持ち、ヒットカウントは1つだけです)。


in  id=0x7fff370d6450, priority=70, domain=ipsec-tunnel-flow, deny=false
    hits=17302, user_data=0x8e0d6a4, **cs_id=0x7fff36c15af0**, reverse, flags=0x0, protocol=0
    src ip/id=10.202.140.0, mask=255.255.255.0, port=0, tag=0
    dst ip/id=10.202.126.0, mask=255.255.255.0, port=0, tag=0, dscp=0x0
    input_ifc=outside, output_ifc=any

in  id=0x7fff3d48dda0, priority=70, domain=ipsec-tunnel-flow, deny=false
    hits=0, user_data=0xaaf9b0c, **cs_id=0x7fff38d9d080**, reverse, flags=0x0, protocol=0
    src ip/id=10.202.140.0, mask=255.255.255.0, port=0, tag=0
    dst ip/id=10.202.126.0, mask=255.255.255.0, port=0, tag=0, dscp=0x0
    input_ifc=outside, output_ifc=any

上記の例は、説明している問題とまったく同じ問題のトラブルシューティングから直接取ったものですが、再起動して問題を修正しました。また、同じファイアウォールが、カプセル化されたアクティブなトンネル上でトラフィックを通過しなくなり、少数のホストだけがデカップする問題が発生しました。トンネルを跳ね返すことで問題が解決されました。

これらの問題は、VPNをIKEv2にアップグレードした後にのみ開始されました。 IKEv2で頻繁にトンネルしているキーを再度キーすると、SPIに問題がある可能性が高いようです。フェーズ2のトンネルの寿命を現在3600に設定しているので、あなたのフェーズ2トンネルの寿命を延ばすことができます(私の顧客はフェーズ2のトンネルで4分ごとにデフォルトのデータライフタイムに達していて、鍵を再設定していたため、データの有効期間を無制限)

2
追加された
私は重複をたくさん見ています。再起動後も私はまだそれらを見る。ドメイン ipsec-tunnel-flow の場合、各トンネルには3つのエントリがあり、すべて同じ cs_id で、ヒットしたエントリは1つだけです。 2つは正しい src dst のアドレスを持ち、残りの2つはゼロです。
追加された 著者 Rob,
あなたは "あなたは同じcs_idで複数のマッチを見たくない"と言ったが、壊れたASAからだと言ったあなたの例は、異なるcs_idがある。あなたが少し明確にすることができ、おそらくこれらの数字が何を意味するか少し話すことができればそれは素晴らしいだろう。答える時間をとってくれてありがとう。
追加された 著者 Rob,