事例紹介：ASA-IPSec トンネルは張れるが、通信ができない。

[haigujin]

• 始めに
• 事象
• 発生原因
• 事例紹介
• 後備
• 参考情報

始めに

本ドキュメントでは、IPSec トンネルは張れるけど、通信ができない場合一般的に注目すべきポイントついて紹介いたします。
本ドキュメントは以下のソフトウェアバージョンを用いて確認、作成しています。

• HW:ASAv
• SW:9.12(3)12
• Ikev1 + Crypto Map IPsec VPN

事象

IPSecトンネルは張れるが、通信ができない

発生原因

IPSecは以下のProtocolを利用しています。

• UDP 500/4500
• ESP IP Protocol 50
  (NAT-T UDP 4500 やAHについては本ドキュメントでは紹介していません)

ISAKMPでVPNトンネルを確立するにはUDP 500ポートが利用されますが、VPNトンネルよりデータ通信をする際にはESPを利用します。つまり、ESP がBlockされてもIPSecトンネルは張れます。そのため、ネットワーク経路上、ESPがBlockされてしまった場合このような事象が発生する可能性があります。

show crypto ipsec sa の出力結果から、Inbound/Outbound のどの方向でパケットロスが発生したのかをある程度推測する事が出来ます。

事例紹介

以下の構成を元にご説明いたします。

注：以下のテストはPingを利用し、すべてのPingの成功/失敗はPC1から確認しています。
正常時：Pingが成功した際の Show crypto ipsec sa の出力結果は以下の通りとなります。

 
事例1：以下の方向でESPをBlockする

Pingが失敗した際の Show crypto ipsec sa の出力結果は以下の通りとなります。

上記のように、送信元のASAv1の暗号パケットのカウンターのみ上昇している場合は、先にASAv1 のOutbound方向でESPがBlockされていないかご確認ください。

事例2：事例1と逆の方向でESPをBlockする

Pingが失敗した際の Show crypto ipsec sa の出力結果は以下の通りとなります。

上記のように、送信元のASAv1の復号パケットのカウンターのみ上昇しない場合は、先にASAv1 のInbound方向にESPがBlockされていないかを確認してください。

事例3：PC2のDefault Gatewayを削除し、PC1へのPingをPC2からドロップするようにする

Pingが失敗した際の Show crypto ipsec sa の出力結果は以下の通りです。

上記のように、送信元の ASAv1の暗号パケットのカウンターが上昇、及び受信側のASAv2の復号パケットのカウンターが上昇している場合は、先にパケットがASAv2に届ていていたかをご確認ください。

後備

IPSecにより暗号化、復号化されるパケットの数は必ず一致する必要がありません。ご利用の通信種類により暗号化、復号化の数が不一致の場合も少なくありません。

参考情報

・Understand IPsec IKEv1 Protocol
https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/217432-understand-ipsec-ikev1-protocol.html#anc63
・Configure a Site-to-Site IPSec IKEv1 Tunnel Between an ASA and a Cisco IOS Router
https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/119425-configure-ipsec-00.html