ファイアウォールのインターフェイスに接続やPingができない問題について

Printer Friendly Page

※この記事は以下の記事の日本語訳です。

Unable to Connect to or Ping a Firewall Interface

https://live.paloaltonetworks.com/t5/Management-Articles/Unable-to-Connect-to-or-Ping-a-Firewall-Int...

 

 

問題

あるサービスを利用するために、ファイアウォールのインターフェイスのIPアドレスに接続しようとした際に、あるいはそのインターフェイスにPingしようとした際に、その通信が失敗してしまう。HTTPSやSSHでデバイスを管理しようとしたり、GlobalProtect ポータルやNetConnect webポータルに接続しようとしたり、あるいは単にインターフェイスにPingしようとしているだけでも起きる可能性があります。

 

解決方法

  • インターフェイスが必要なサービスを有効にしたり、接続元からのIPアドレスを許可する適切な管理プロファイルを持っていることを確認します。
    • 管理プロファイルが疑われる場合、以下の"counter"コマンドを実行し、"counter"の増加を確認します: > show counter global name flow_host_service_deny
  • トラフィック ログを確認することにより、インターフェイスに向かうトラフィックをブロックしているセキュリティ ポリシーがないことを確認します。宛先アドレスにファイアウォールのインターフェイスのIPアドレスとなるようにフィルタ対象となるように設定をします。一般的に、セキュリティ ポリシーは接続をブロックしませんが、ブロックしてしまう可能性はあります。
    • パケットが到達するインターフェイスが、開始パケットがファイアウォールに入っていくインターフェイスと異なり、それら2つのインターフェイスが異なるゾーンにある場合、それはインター ゾーン(ゾーン間)のセッションだと考えられるため、そのセッションを許可するセキュリティ ポリシーが必要です。
    • パケットが到達するインターフェイスが、開始パケットがファイアウォールに入っていくインターフェイスと同じ場合、それはイントラ ゾーンのセッションだと考えられ、イントラ ゾーン(ゾーン内)のセッションはデフォルトで許可されているので、セキュリティ ポリシーは必要ありません。しかし、明示的に定義された"deny any to any zone"のセキュリティ ポリシーがあると、デフォルトの許可を上書きしてしまいます。そのため、ファイアウォールのインターフェイスに対して初期化セッションを許可する、より明確なポリシーを保持する必要があります。

注:インターフェイスのセッションのログが何も観測されていない場合、デフォルトのアクションがインター ゾーンやイントラ ゾーンのセッションで取られている時、拒否、許可のどちらについても、トラフィック ログは生成されない動作によることが考えられます。

  • 問題がまだ解決できない場合は別の可能性として、送信元NATで開始パケットの送信元アドレスを、パケットが到達するインターフェイスのアドレスへ変換していることが考えられます。これはファイアウォールに、パケット処理の早い段階でのパケットのドロップを引き起こします。なぜならアドレス変換後にそのパケットは、送信元と宛先が同じとなるLAND攻撃のように見えてしまうからです。
    • これは外部インターフェイスと検証機が内部ネットワークにあり、GlobalProtectポータルへの接続を検証している時によく見られる振る舞いです。開始パケットは外部ゾーンにアクセスするための送信元NATによって外部インターフェイスに変換されてしまいます。
    • ログ プロセスの前にこの仕組みが動き出すため、この場合はトラフィックのログは何も見られません。
    • 以下のコマンドを入力して、これが問題なのかどうかを確認するためにカウンタの増加分を確認します:> show counter global name flow_policy_nat_land
    • この問題を解決するために、原因となるNATポリシーのクローンを作成し、[送信元アドレスの変換]を"none"に変更し、[宛先アドレス]を該当のインターフェイスのIPアドレスに変更します。そして問題のNATポリシーの直上に新しいポリシーを置きます。この措置により、宛先が該当インターフェイスの場合のみ、新しいNATポリシーが適用されます。
  • NATポリシーによって引き起こされる別の問題は、宛先NATが、サーバーのアドレスに向かう該当のインターフェイスのアドレスを宛先アドレスを持つパケットを、変換する場合です。一般的にこの宛先NATは、外部インターフェイスのパブリックなIPアドレスを含みます。この問題を引き起こす可能性のあるNATの設定は2つ考えられます。
    • 宛先NATをすべてのサービスのために設定している場合、該当するインターフェイスの宛先アドレスを持ちNATポリシーに該当するパケットはすべて変換されます。たとえその意図がリモート ホストではなく、該当インターフェイスにパケットを到達させるためであったとしてもです。以下の方法で、この問題を解決できる可能性があります:
      • サーバーが特定のサービス、あるいはファイアウォールのインターフェイスに届く必要のあるポートとは異なるポートを使用する場合、必要なサービスだけを変換してサーバーへ転送するために、NATポリシーの適用範囲を狭くします。
    • その宛先NAT用に特定のサービスが指定して、それらのサービスの宛先ポートに合致するパケットだけが宛先変換されますが、443番ポートの変換を例として挙げると、宛先NATポリシーに合致するパケットであるからといって、ファイアウォールのインターフェイスの443番ポートへ接続されることはありません。以下の方法で、この問題を解決できる可能性があります:
      • 利用可能なアドレスがある場合、別のアドレスをファイアウォールのインターフェイスに追加します。同じサブネット内にアドレスを追加する場合、そのサブネット マスクは"/32"である必要があります。
      • ファイアウォールのインターフェイスのアドレスは変更するか、サーバーのアドレスを変更するべきです。
      • 上記の選択肢のどちらも相応しいアクションでない場合、問題は、サービスが提供されるために十分なパブリックなアドレスを持っていないことである可能性があります。より手の掛かる解決策ではありますが、パブリックなアドレスを追加で入手する必要があるかもしれないということです。
  • 上記の解決方法でも問題を解決できない場合、通信を開始するコンピュータとファイアウォールのインターフェイス間において、ネットワーク上のルートを確認する価値は大いにあります。他のコンピュータがファイアウォールに接続できるかどうかを確認します。必要に応じて、開始パケットがファイアウォールに届いているかどうかを確認するために、ファイアウォール上でパケット キャプチャをします。

 

Trustゾーンのホストが、外部インターフェイスのIPアドレスへの接続を防ぐ送信元NATの例:

Source NAT.png

インターネットからの外部インターフェイスのIPアドレスへのすべての接続を防ぐ宛先NATの例:

Dest NAT.png

 

注:この解決方法は、ファイアウォールの管理インターフェイスには適用されません。

 

 

著者:astanton