キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
5525
閲覧回数
0
いいね!
2
返信

VPN接続環境での「ASA-4-313005: No matching connection for ICMP error message」エラーについて

athirano1
Level 1
Level 1

こんにちは、ASA5515X で構築して、リモートアクセスIPsec-VPN, Clientless SSL-VPN, AnyConnect SSL-VPNの接続を受け付けるようにしています。
・OS :  9.1(5)
・AnyConnectは、3.1.05182
・IPsec-VPNは、Lan-To-LANではなく、リモートアクセスIPsec-VPNで、接続してきたクライアントPCにプライベートIPアドレスを払い出すタイプです。
・VPNの接続サービスのみ提供しています。

show logコマンドでログを見ていると、以下のメッセージが頻繁に出ます。

  Mar 28 2016 11:17:30:
    %ASA-4-313005: No matching connection for ICMP error message: icmp
    src outside:[PCのプライベートIP](LOCAL\[ユーザーID])
    dst inside:[内部NWにあるDNSサーバーのIP] (type 3, code 3) on outside interface.  
    Original IP payload: udp src [内部NWにあるDNSサーバーのIP]/53 dst [PCのプライベートIP]/59174.

ログの字面としては、「通信を許可するために必要なコネクション情報がテーブルにないためドロップした」といったところでしょうか。ただ、
・内部NWにあるDNSサーバ→クライアントPC  に名前解決の正引き結果を返そうとして、返すことができなかった。
・そして、クライアントPCが「Destination Unreachable」を返そうとした。
・それがドロップした。
となるのでしょうか?  どうも納得できません。(DNSのクエリーを出したPCが、自身への宛先が見つからないとエラーを出す?)
何か、私が勘違いをしている気もします。


複数のVPNユーザーの接続にて、頻繁に出るので原因と対処の方法についてお知らせいただけますでしょうか。
(Syslog 4-313005は、シスコのホームページでも結構に検索に引っかかるのですが、今回の問題にすぐ役立ちそうな情報は見つかりませんでした。
例  https://supportforums.cisco.com/discussion/10825211/asa-4-313005-no-matching-connection-icmp-error-message


■状況や機器の設定について
・クライアントPCはWindows7 、クライアントアプリはCisco VPN Client 5.0.07.0290です。

・複数の接続ユーザーについて、このエラーメッセージが出ますが、全てのユーザー(PC)ではありません。
  むしろ、エラーメッセージが出ない接続ユーザーが多いです。
 
・完全には調べていないのですが、リモートアクセスIPsec-VPNユーザーの接続でエラーが多い気がします。
  (AnyConnect SSL-VPNの接続ではエラーが出ていない気がします。)

・エラーメッセージが出ているユーザーで、実使用上の不具合が出ているかは確認できていません。
  (仮に名前解決が失敗していれば、「全く使えない」と申告が来そうなものですが、来ていません。
    DNSサーバーは2台ありますが、Syslogには両方のDNSサーバーのIPアドレスが登場します。)

・クライアントPCから内部NWにあるDNSサーバーへの到達性は問題ありません。
  VPN接続後にPC→内部NWにあるDNSサーバーに、ping/trace routeも通りますし、名前解決も成功します。
 
・意味があるかはともかくとして、インスペクションの対象通信として、icmp, icmp errorを追加してみました。
  (末尾のConfigの抜粋を参照)
  ただ、効果は無いようでした。
 
・ASDM上で再確認しましたが、IPsec-VPN, SSL-VPN共に"Bypass interface access list for inbound VPN sessions"を有効にしています。



■設定の抜粋

---------- Inspection の部分 ---------------
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect ip-options
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip
  inspect xdmcp
  inspect icmp             ←今回の件で調査用に追加
  inspect icmp error    ←今回の件で調査用に追加

!
service-policy global_policy global


---------- タイムアウト設定 -----------
# show run timeout
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
#


よろしくお願いします。

1 件の受理された解決策

受理された解決策

Akira Muranaka
Level 8
Level 8

athirano1さん、こんにちわ。

確認頂いているエラーは、DNSサーバが何らかの理由でエラーを相手に通知したいときに UDP/53パケットではなく、ICMPパケットを使って通知をトライしているためだと思います。 古めのサーバなどを利用時に見られる実装だったと思います。 例えば、古いSMTPサーバでも、似たような動作・トラブルを見たことがあります。

そして、ASAはコネクションベースの機器です。ASAは動的にコネクションを生成して通信を監視しますが、戻りパケットで通過を許可するのは 同じプロトコルのポート番号にマッチした通信のみです。つまり、恐らくUDP/53の通信をしている状態で、突然 (知らない怪しい)ICMPパケットが戻ってきた・・とASAには見えてしまいます。 ASAは、既存のICMPコネクションがある時しか、戻りのICMPパケットの通過を許可しません。これが、今回のドロップの理由かと思います。

ちなみに、ICMPエラーメッセージパケットは、相手のコネクションを不正に切断、にも流用できる、使い方によっては危険なパケットです。 ですので、ASAがブロックしているのはセキュリティ上は正しい動作かと思います。

対応としては、ご利用のDNSサーバの仕様を確認して頂くか、もしくは このICMPパケットのエラーが気になる場合は、以下コマンドで、概要ログメッセージIDの出力の停止するのが良いのかなと思いました。 ご参考になれば。

no logging message 313005

元の投稿で解決策を見る

2件の返信2

Akira Muranaka
Level 8
Level 8

athirano1さん、こんにちわ。

確認頂いているエラーは、DNSサーバが何らかの理由でエラーを相手に通知したいときに UDP/53パケットではなく、ICMPパケットを使って通知をトライしているためだと思います。 古めのサーバなどを利用時に見られる実装だったと思います。 例えば、古いSMTPサーバでも、似たような動作・トラブルを見たことがあります。

そして、ASAはコネクションベースの機器です。ASAは動的にコネクションを生成して通信を監視しますが、戻りパケットで通過を許可するのは 同じプロトコルのポート番号にマッチした通信のみです。つまり、恐らくUDP/53の通信をしている状態で、突然 (知らない怪しい)ICMPパケットが戻ってきた・・とASAには見えてしまいます。 ASAは、既存のICMPコネクションがある時しか、戻りのICMPパケットの通過を許可しません。これが、今回のドロップの理由かと思います。

ちなみに、ICMPエラーメッセージパケットは、相手のコネクションを不正に切断、にも流用できる、使い方によっては危険なパケットです。 ですので、ASAがブロックしているのはセキュリティ上は正しい動作かと思います。

対応としては、ご利用のDNSサーバの仕様を確認して頂くか、もしくは このICMPパケットのエラーが気になる場合は、以下コマンドで、概要ログメッセージIDの出力の停止するのが良いのかなと思いました。 ご参考になれば。

no logging message 313005

Akira Muranakaさん

いつもお世話になっています。athirano1です。
返信が遅くなりましたが、ご回答ありがとうございます。

いただいた回答で、いままでモヤモヤしていたものがすっきりした気がします。
ありがとうございました。