ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 IPSec and tunneling - resource list https://live.paloaltonetworks.com/t5/Management-Articles/IPSec-and-tunneling-resource-list/ta-p/67721   以下のリストにIPSecおよびTunnel設定の理解に役立つ情報を記載しています: 記事名 備考 リソースタイプ 基本 How to configure IPSec VPN IPSec VPN設定 ドキュメント Configuring the Palo Alto Networks device as an IPSec IPSec Passthrough設定 ドキュメント IPSec crypto options IPSec暗号オプション ドキュメント Why is GlobalProtect slower on SSL VPN compared to IPSec VPN? GlobalProtectのSSLオプションがIPSecVPNオプションよりも遅い理由 ドキュメント How to improve performance for IPSec traffic IPSec通信のパフォーマンスを向上させる方法 ドキュメント NAT traversal in an IPSec gateway IPSecゲートウェイでのNAT traversal設定 ドキュメント Config guidelines when terminating IPSec VPN tunnels on the firewall ファイウォールでIPSec VPNを終端する場合のガイドライン ドキュメント Sample IPSec tunnel configuration - Palo Alto Networks firewall to Cisco ASA IPSec tunnel設定例 (Palo Altot NetowrksファイアウォールとCiso ASA) ドキュメント The IPSEC tunnel comes up but hosts behind peer are not reachable  IPSec tunnelトラブルシューティング ドキュメント IPSec VPN with peer ID set to FQDN IPSec VPNのpeer IDをFQDNで設定する場合の注意点  ドキュメント What encryption is used when enabling IPSec for GlobalProtect? GlobalProtectでIPSecを有効にした場合の暗号について ドキュメント How to create an IPSec tunnel that is a responder (not initiator) IPSec tunnel (レスポンダー)設定方法 ドキュメント 中級                   IPSec tunnel details IPSec tunnelトラブルシューティング ドキュメント Differences between IPSec and LSVPN tunnel monitoring LVPNとIPSec VPN のトンネルモニタリングの相違点 ドキュメント IPSec traffic being discarded IPSsec通信のトラブルシューティング ドキュメント How to verify if IPSec tunnel monitoring is working トンネルモニタリング動作状況の確認方法 ドキュメント IPSec VPN error: IKE phase-2 negotiation failed as initiator, quick mode IPSec VPNエラーのトラブルシューティング ドキュメント IPSec interoperability between Palo Alto Network firewalls and Cisco ASA Palo Alto Networks firewallsとCisco ASA firewallシリーズのIPSec相互接続について ドキュメント How to configure dynamic routing over IPSec against Cisco routers IPSec経由でCiscoルートとのダイナミックルーティングを設定する方法 ドキュメント Configuring route based IPSec with overlapping networks ルートベースIPSecの設定 ドキュメント IPSec with overlapping subnet 重複サブネットにおけるIPSec設定 ドキュメント GlobalProtect configuration for the IPSec client on Apple iOS devices Apple iOSのIPSecクライアント向けのGlobalProtect 設定 ドキュメント Site-to-site VPN between Palo Alto Networks firewall and Cisco router is unstable or intermittent Palo Alto Networks firewallとCiscoルータ間でのSite-to-site VPNが不安定になる事象について ドキュメント Configuring captive portal for users over site-to-site IPSec VPN Site-to-site IPSec VPN経由のCaptive Portal設定 ドキュメント IPSec VPN IKE phase 1 is down but tunnel is active IPSec VPNトンネルがアクティブの状態でIKE Phase 1がダウンしている事象について ドキュメント Tips for configuring a Juniper SRX IPSec VPN tunnel to a Palo Alto Networks firewall Juniper SRX IPSecとPalo Alto Networks firewall間のIPSec VPNトンネル設定における Tips ドキュメント Dynamic IPSec site-to-site between Cisco ASA and Palo Alto Networks firewall Cisco ASAとPalo Alto Networkファイウォール間におけるダイナミック site-to-site IPSecについて ドキュメント IPSec site-to-site between Palo Alto Networks firewall and Cisco with NAT device Cisco機器とPalo Alto Networkファイアウォール間にNAT機器がある場合のIPSec site-to-site接続について  ドキュメント How does the firewall handle diffserv headers in an IPSec tunnel? IPSecトンネルにおけるDiffservヘッダーの扱いについて ドキュメント IP phone switch not working through IPSec tunnel IPSecトンネル経由でIPフォンスイッチが動作しない ドキュメント 上級           IPSec tunnel is up and packet is getting dropped with wrong SPI counter increase "wrong SPI" カウンタが増加しパケットがドロップされる事象について ドキュメント Configuring route-based IPSec using OSPF OSPFを利用したRoute-based IPSec設定 ドキュメント IPSec error: IKE phase-1 negotiation is failed as initiator, main mode due to negotiation timeout IPSecラブルシューティング ドキュメント Site-to-site IPSec excessive rekeying on only one tunnel on system logs Site-to-Site IPSecで1つのトンネルのみ大量の rekeyが発生する ドキュメント CLI commands to status, clear, restore and monitor an IPSec VPN tunnel IPSec CLIコマンド ドキュメント What do the port numbers in an IPSec-ESP session represent? IPSec-ESPセッションのポート番号について ドキュメント Configuring IPSec VPN between PAN-OS and CheckPoint Edge / Safe@Office PAN-OSとCheck Point Edge / Safe@Office間のIPSec VPN設定 ドキュメント Configuring site-to-site IPSec VPN in layer 2 Layer 2 インターフェースでの site-to-site IPSec VPN 設定 ドキュメント Site-to-site IPSec VPN between Palo Alto Networks firewall and Cisco router using VTI not passing traffic Palo Alto NetworksファイアウォールとVTIを利用したCiscoルータ間のIPSecトラブルシューティング ドキュメント Configuring IKEv2 VPN for Microsoft Azure Environment Microsoft AzureとのIKEv2 VPN設定 ドキュメント  
記事全体を表示
anishinoya ‎09-12-2018 01:52 AM
6,764件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Tips & Tricks: Why Use a VPN Proxy ID? https://live.paloaltonetworks.com/t5/Featured-Articles/Tips-amp-Tricks-Why-Use-a-VPN-Proxy-ID/ta-p/69524 DotW: 重複するIPを持つIPSec プロキシ IDに関するヘルプでサブネットが重複している場合の問題を取り上げました。私たちは特定の条件下でピアネットワーク同士が通信する方法を模索していました。Palo Alto Networks ファイアウォールでポリシーベースのVPNをサポートするピアと連携する場合はプロキシIDの設定が必要です。   上記のディスカッション・オブ・ザ・ウィーク(DotW)はプロキシIDについてのヘルプですが、VPN プロキシ IDと、それを設定する重要な理由について詳しく説明しましょう。   IPSec VPNトンネルについての話で触れたように、Palo Alto Networks ファイアウォールでポリシーベースのVPNをサポートするピアと連携する場合は、プロキシ IDを定義する必要があります。ポリシーベース VPNをサポートするデバイスは、IPSecトンネルを介するトラフィックを許可するための特定のセキュリティルール/ポリシーまたはアクセスリスト(送信元アドレス、宛先アドレス、およびポート)を使用します。 これらのルールは、クイック モード / IKE フェーズ 2のネゴシエーション中に参照され、ネゴシエーション プロセスの最初または2番目のメッセージでプロキシ IDとして交換されます。 そのため、Palo Alto Networks ファイアウォールでポリシーベースのVPNをサポートするピアと連携するように設定する場合は、フェーズ 2のネゴシエーションを成功させるために両方のピアの設定が同一になるようにプロキシ IDを定義する必要があります。プロキシ IDが設定されていない場合、Palo Alto Networks ファイアウォールはルート ベースのVPNをサポートしているため、プロキシ IDとして使用されるデフォルト値は、"source ip: 0.0.0.0/0, destination ip: 0.0.0.0/0 and application: any"となり、これらの値がネゴシエーション中にピアと交換されると、結果としてVPN接続のセットアップに失敗します。   それでは、プロキシ IDの設定内容とオプションを見てみましょう: プロキシ ID セクションの中(Network > IPSec トンネル (IPSec Tunnels) > トンネス名を選択 > プロキシ ID (Proxy IDs)タブ)に、いくつかのオプションを見ることができます: プロキシ ID (Proxy ID) - 追加(Add)をクリックしてプロキシを識別するための名前を入力します。任意の名前を使用できますが、数字だけの名前は使用できません。 ローカル (Local) - IP アドレス / サブネットマスクの形式でIPアドレスやサブネットを入力します。 (例: 10.1.2.1/24) リモート (Remote) - ピアが必要とする場合、IP アドレス / サブネットマスクの形式でIPアドレスやサブネットを入力します。 (例: 10.1.1.1/24) プロトコル (Protocol) - プロトコルとローカルとリモートのポート番号を指定します: 番号 (Number) - プロトコル番号を指定します。(サードパーティ製デバイスとの相互接続に使用) いずれか (Any) - TCP / UDPのいずれのトラフィックも許可します。 TCP - ローカル及びリモートのTCP ポート番号を指定します。 UDP - ローカル及びリモートのUDP ポート番号を指定します。 注: 各プロキシ IDはVPN トンネルとしてカウントされるので、ファイアウォールのIPSec VPN トンネルの容量に影響します。(訳注: 各プラットフォームの上限数についてはデータシートをご参照ください)   プロキシ IDの利点は、特定のトラフィックだけがVPN トンネルを通過するようにしたい場合、プロトコル番号またはTCP / UDP ポート番号で細かく設定を容易にすることができる点です。   IKEには2つのバージョンがあり、プロキシ IDの動作は異なります。 - IKEv1では、Palo Alto Networks ファイアウォールはプロキシ IDの完全一致のみをサポートします。ピアのプロキシ IDが一致しない場合、VPNの動作に問題が発生します。 - IKEv2では、2つのVPN ゲートウェイ間でプロキシ IDの設定が異なっている場合に、トラフィック セレクタの絞り込みが行われます。実装されている選択肢について以下で説明します。 IKEv2の使用例 多くのIPSec VPN セットアップを説明するのに役立つIPSecとIKEv2の使用例のリスト、及びプロキシ IDを正しく使用する方法については、以下を参照してください。   例: 2つのVPN ゲートウェイ AとBがあります。IKE ネゴシエーションはVPN GW-aにより開始されます。i=イニシエータ、r=レスポンダ   VPN GW-aをトラフィック セレクタ TSi-a/TSr-aと定義し、VPN GW-bをトラフィック セレクタ TSi-b/TSr-bの設定を有していると仮定します。TSr-aはTSr-bと同様なので無視することができます。TSi-aはTSi-bとは異なる可能性があります。   A. TSi-aがTSi-bと同じ場合。 例:両方とも5.10.11.0/24: 期待値:動作は既存のIKEv1 プロキシ IDの場合と同じであり、トラフィックは通過できません。この例では適切な通信を可能にするためにNATが必要となります。   VPN GW-a: 送信: TSi: 5.10.11.0 - 5.10.11.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [最終結果]   このソリューションについては、DotWの記事で詳しく説明しています。 DotW: Help with IPSec Proxy IDs with overlapping IPs DotW: 重複するIPを持つIPSec プロキシ IDに関するヘルプ(日本語翻訳) B. TSi-aがTSi-bを含む上位ネットワークの場合: b1. VPN GW-aはTSi-a = 5.10.0.0/16を、VPN GW-bはTSi-b = 5.10.11.0/24を提案する場合:   i. トンネルはトラフィックなしで起動します。(たとえば、初期化中やテストコマンドによって)   期待値: レスポンダとしてVPN GW-bはVPN GW-aに5.10.11.0/24で応答します。VPN GW-aはそれを受け入れてchild-saを作成します。   VPN GW-a: 送信: TSi: 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [共通サブセットに絞り込まれます]   ii. VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.10.11.2)がトンネルを起動しようとします。   期待値: レスポンダとしてVPN GW-bはVPN GW-aに5.10.11.0/24で応答します。VPN GW-aはそれを受け入れてchild-saを作成し、トラフィックは通過します。   VPN GW-a: 送信: TSi: 5.10.11.2; 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [共通サブセットに絞り込まれます]   Palo Alto Networks ファイアウォールがイニシエータの場合、IKE ペイロードの最初の特定トラフィック セレクタ (5.10.11.2)を送信しません。 レスポンダとして特定のトラフィック セレクタを送信するピアに対応することができます。トラフィック セレクタを共通サブセットに絞り込みます。   iii. VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.10.6.2)がトンネルを起動しようとします。   期待値: レスポンダとしてVPN GW-bはVPN GW-aに5.10.11.0/24で応答します。VPN GW-aはそれを受け入れてchild-saを作成します。   VPN GW-a: 送信: TSi: 5.10.6.2; 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [共通サブセットに絞り込まれます]   Palo Alto Networks ファイアウォールがイニシエータの場合、IKE ペイロードの最初の特定トラフィック セレクタ (5.10.6.2)を送信しません。   レスポンダとしてトラフィック セレクタを共通サブセットに絞り込みます。受信したTS ペイロードに特定のトラフィック セレクタが含まれている場合、ローカル ポリシーから外れていても引き続きトラフィック セレクタの絞り込みは行いますが、RFC 5996に従って特定のトラフィック セレクタは無視されます。   b2. VPN GW-aはTSi-a = 5.10.0.0/16を、VPN GW-bは2つ以上の定義エントリ TSi-b = 5.10.11.0/24と5.10.12.0/24を提案する場合:   i. トンネルはトラフィックなしで起動します。   トラフィック セレクタごとの複数エントリはstrongswanによってサポートされています。したがって、strongswanはVPN GW-bとして設定することができます。PAN-OSがGW-bの場合、複数のプロキシ IDを設定する必要があります。   VPN GW-a: 送信: TSi: 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [PANOS: 最初に一致したエントリから共通サブセットを使用します]   上記はレスポンダ (VPN GW-b)としてのPAN-OSの結果を示しています。VPN GW-aに5.10.11.0/24または5.10.12.0/24のいずれかのエントリで応答します("show vpn tunnel"で表示されるフル トンネル名のアルファベット順に基づく最初のエントリ)。   他社製品がVPN GW-bとして両方のエントリ (5.10.11.0 - 5.10.11.255 + 5.10.12.0-5.10.12.255)をトラフィック セレクタとして返答しても、Palo Alto Networks ファイアウォールは最初のエントリのみをインストールします。   ii. VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.10.11.2)がトンネルを起動しようとします。   期待値: レスポンダとしてVPN GW-bはVPN GW-aに5.10.11.0/24で応答し、トラフィックは通過します。   VPN GW-a: 送信: TSi: 5.10.11.2; 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [PAN-OS: 5.10.11.2をカバーできるポリシーを優先し、最初に一致したエントリから共通サブセットを取得します。]   Palo Alto Networks ファイアウォールがイニシエータの場合、IKE ペイロードの最初の特定トラフィック セレクタ ( 5.10.11.2)を送信しません。   レスポンダの場合、絞り込みまたは完全一致により特定のトラフィック セレクタを1つのエントリでカバーできるまで、設定されたすべてのプロキシIDを検索します。 特定のトラフィック セレクタを共通サブセットでカバーできない場合は、引き続き絞り込みを試みます。   iii. ステップ iiのあと、VPN GW-aの背後にある別のホスト(たとえば、ホスト IP 5.10.12.2)がVPNの対向側に通信しようとする。   期待値: このトラフィックは先に作成されたVPN トンネルに一致しないので、別のIPSec SAがネゴシエートされます。 VPN GW-a: 送信: TSi: 5.10.12.2; 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.12.0 - 5.10.12.255 [PANOS: 5.10.12.2をカバーできるポリシーを優先し、最初に一致したエントリから共通サブセットを取得します]   この時点で両方のプロキシ IDのVPN トンネルが起動し、トラフィックが通過します。   他社製品の中には別のIKE ネゴシエーションを開始しないものもあります。5.10.12.2と一致しませんが、ステップ iiで確立した既存のトンネルを使用してパケットを送信します。 この種の動作を分析するためには、トンネル ネゴシエーション プロセス全体を確認する必要があります。   iv. VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.10.6.2)がVPNの対向側に通信しようとする。(ステップ iiおよびiiiが実行されていない場合)   期待値: VPN GW-aに一致するSAが無いので、VPN GW-bとのネゴシエートを試行します。応答は実装に依存します。   VPN GW-a: 送信: TSi: 5.10.6.2; 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.12.0 - 5.10.12.255 [PANOS: 最初に一致したエントリから共通サブセットを使用します]   v. ステップ iiiのあとで、VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.10.6.2)がVPNの対向側に通信しようとする。   イニシエータはピアへトラフィックを転送するために以前に確立したトンネルを使うことができます。トンネルの選択はベンダーの実装に依存します。   b3. VPN GW-bがトラフィック セレクタの絞り込みをサポートしていない場合:   VPN デバイスの中にはトラフィック セレクタの絞り込みをサポートしていないものがあります。たとえば、このような場合にCisco IOS 15.0はNO_PROPOSAL_CHOSENと応答します。   トンネルを確立できず、設定を変更する必要があります。   C. TSi-aがTSr-bのサブセットの場合: VPN GW-aはTSi-a = 5.10.11.0/24を、VPN GW-bはTSr-b = 5.10.0.0/16を提案する。   i. トンネルはトラフィックなしで起動します。   期待値: VPN GW-bは5.10.11.0/24で応答し、トンネルはトラフィック セレクタの共通部分(5.10.11.0/24)を使用して確立されます。   VPN GW-a: 送信: TSi: 5.10.11.0 - 5.10.11.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [最終結果 - 共通サブセット]   ii. VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.10.11.2)がトンネルを起動しようとします。   期待値: トラフィック セレクタ 5.10.11.0/24でトンネルが確立され、トラフィックは通過します。   VPN GW-a: 送信: TSi: 5.10.11.2; 5.10.11.0 - 5.10.11.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [最終結果]   Palo Alto Networks ファイアウォールがイニシエータの場合、IKE ペイロードの最初の特定トラフィック セレクタ (5.10.11.2)を送信しません。   レスポンダとして特定のトラフィック セレクタを送信するピアに対応することができます。イニシエータ側が小さいためトラフィック セレクタはイニシエータから選択されます。   iii. VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.10.6.2)がトンネルを起動しようとします。   期待値: VPN GW-a: 送信: TSi: 5.10.6.2; 5.10.11.0 - 5.10.11.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [最終結果]   PAN-OSがイニシエータの場合、プロキシ IDが設定されていないか、単一のプロキシ IDが同じトンネル インターフェイス上に定義されている場合、トンネルは上記のようにネゴシエートされ、トラフィックはトンネルを介して送信されます。   複数のプロキシ IDがある場合、一致するものがあるかどうか他のプロキシ ID(トンネル ID)を確認します。一致するものがなければ、最後のプロキシ IDを使用してトンネルをネゴシエートし、トラフィックを送信します。これはIPSec Multiple Phase 2 Associationsとして定義されている動作です。   PAN-OSがレスポンダで、ポリシー VPNが動作している別のベンダー機器がイニシエータである場合、パケットがローカル ポリシーの範囲外であるため、トンネル ネゴシエーションを開始しない可能性があります。トンネル ネゴシエーションを開始する場合は、イニシエータのトラフィック セレクタを狭くして使用します。   D. TSi-aとTSr-bの間で重複がある場合: VPN GW-aはTSi-a = 5.10.0.0/16を、VPN GW-bはTSr-b = 5.10.11.0/24と5.9.0.0/24を提案する。 i. トンネルはトラフィックなしで起動します。   期待値: VPN GW-bは5.10.11.0/24で応答し、トンネルはトラフィック セレクタの共通部分(5.10.11.0/24)を使用して確立されます。   VPN GW-a: 送信: TSi: 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [最終結果 - 重複したサブセット]   ii. VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.10.11.2)がトンネルを起動しようとします。   期待値: トラフィック セレクタ 5.10.11.0/24でトンネルが確立され、トラフィックは通過します。   VPN GW-a: 送信: TSi: 5.10.11.2, 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [共通サブセット]   Palo Alto Networks ファイアウォールがイニシエータの場合、IKE ペイロードの最初の特定トラフィック セレクタ (5.10.11.2)を送信しません。   レスポンダとして特定のトラフィック セレクタを送信するピアに対応することができます。トラフィック セレクタを共通サブセットに絞り込みます。   iii. VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.10.12.2 - VPN GW-aのポリシー内だが、VPN GW-bのポリシー外)がトンネルを起動しようとします。   期待値: VPN GW-a: 送信: TSi: 5.10.12.2, 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [共通サブセット]   PAN-OSがイニシエータの場合、レスポンダは5.10.12.2で使用可能な範囲を見つけることができないため、共通サブセット(5.10.11.0/24)を返します。トンネルを確立することができますが、特定のトラフィック セレクタは送信しません。   IPsec Multiple Phase 2 Associationsで定義されている既存の動作に基づいて、パケットはこのトンネルを介して送信されますが、レスポンダによって廃棄される可能性があります。送信側のVPN トンネルはパケットが廃棄されたことに気が付かないかもしれません。   iv. VPN GW-aの背後にあるホスト(たとえば、ホスト IP 5.9.0.2 - PN GW-bのポリシー内だが、VPN GW-aのポリシー外)がトンネルを起動しようとします。   期待値: VPN GW-a: 送信: TSi: 5.9.0.2, 5.10.0.0 - 5.10.255.255 VPN GW-b: 応答: TSi: 5.10.11.0 - 5.10.11.255 [共通サブセット]   PAN-OSがイニシエータの場合、プロキシ id 0.0.0.0/0(プロキシ IDが定義されていない場合)または最後のプロキシ ID(トンネル インターフェース上に複数のプロキシ IDが定義されている場合)がTSiで使用されます。   トラフィックはトラフィック セレクタの絞り込みに違反するため、レスポンダ(ポリシー ベース VPNの機器)で廃棄される可能性があります。 イニシエータ(PAN-OS以外の機器)が厳格なVPN ポリシー チェックを行っている場合、VPN ポリシーに違反するため、IKE ネゴシエーションがトリガーされないことがあります。   これでこのTips & Tricksは終わりです。この記事が参考になれば幸いです。     著者: Joe Delio
記事全体を表示
tsakurai ‎08-26-2018 04:52 PM
4,975件の閲覧回数
0 Replies
※この記事は以下の DotW (Discussion of the Week) の日本語訳です。 DotW: Help with IPSec Proxy IDs with overlapping IPs https://live.paloaltonetworks.com/t5/Featured-Articles/DotW-Help-with-IPSec-Proxy-IDs-with-overlapping-IPs/ta-p/69123   プロキシ IDについてのヘルプが必要ですか?それはLive Communityでも人気のトピックのようです。いくつかの異なるシナリオをもとに、私たちのコミュニティでどのようなノウハウがトピックに取り入れられ、どのような解決策が推奨されるかを見てみましょう。   今週のDiscussion of the Week(DotW)のもととなったプロキシ IDについてのディスカッションは以下を参照してください: https://live.paloaltonetworks.com/t5/General-Topics/Proxy-IDs-help/m-p/3579   コミュニティ メンバーのNeo.The.OneはIPSec VPNのプロキシ IDに関するトピックを投稿しました。彼は対向機器としてCheck Point ファイアウォールを利用するVPNを設定しており、VPN トンネルを正しく稼働させるためにどのようなプロキシ IDの設定が必要になるか求めていました。 Neo.The.Oneは2つのシナリオを持っています: Case 1 VPN用のインターナル ネットワーク (Palo Alto Networks ファイアウォール): 173.16.10.0/24, 10.31.0.0/16, 10.40.40.0/24 対向機器の先にあるネットワーク (Check Point ファイアウォール): 不明   Case 2 VPN用のインターナル ネットワーク (Palo Alto Networks ファイアウォール): 173.16.10.0/24, 10.31.0.0/16, 10.40.40.0/24 対向機器の先にあるネットワーク (Check Point ファイアウォール): インターナルと全く同じ、172.16.10.0/24 , 10.31.0.0/16, 10.40.40.0/24   ライブコミュニティのメンバーであるHULKとSatishは、Neo.The.Oneを助ける素晴らしい答えを提供しました。   HulkはIPSec VPNのSPI キーを定義するためにプロキシ IDが必要であると説明しました。SPIはキーペアであり、ESP パケットのカプセル化/解除に使用されます。 プロキシ IDの設定はWebUIで確認することができます。Hulkはプロキシ ID設定についての素晴らしいスクリーン ショットを提供しました。   Network > IPSec トンネル (IPSec Tunnels) > 既存のトンネル名 > プロキシ ID (Proxy IDs) タブ   サブネットの重複問題に対処することで、Case 2を解決できます。 重複したサブネットとIPSec VPN トンネルを示す次の図を参照してください: トンネルの両側に同じネットワークが存在するため、トラフィックをVPN トンネル経由でルーティングする方法はありません。   この問題を解決する唯一の方法は、内部ネットワーク サブネットを新しいユニークなネットワーク サブネットに変換するためのNAT(ネットワーク アドレス変換)を両側の隣接ゲートウェイで作成するか、もしくは片方のサブネット IPを変更することです。以下の図を参照してください: この場合、いずれかの側の全てのトラフィックは、他の(同じ)ネットワークの代わりに新しいNAT アドレス宛てになります。 この解決方法では、正しい動作をさせるために両方のゲートウェイでNATを実施する必要があります。しかしこの方法を用いると、どちらの側にどのネットワークがあるのか混乱することはありません。   Neo.The.OneはSatishの提案に対し、2つの追加質問をしました: 質問: 私は0.0.0.0/0を入力するか空欄のままにする必要がありますか? 回答:  アドレスは必須です。   質問:   私はPalo Alto Networks ファイアウォールと隣接ファイアウォールの外部インターフェイスのIP アドレスをプロキシ IDの一覧に追加する必要がありますか? 回答:   はい、正しく動作させるには、外部インターフェイスのIP アドレスかNAT アドレスをプロキシ IDの一覧に追加する必要があります。   Satishは、VPN 設定の一助となるリンクとして How to Configure IPSec VPN を提供しました。   この文書がプロキシ IDとVPN トンネルの両側でサブネットが重複している場合の対処方法を理解するために役立つことを願っています。   元となったディスカッションを見るには次のリンクを使用してください: https://live.paloaltonetworks.com/t5/General-Topics/Proxy-IDs-help/m-p/3579   著者: Joe Delio
記事全体を表示
tsakurai ‎08-16-2018 11:20 PM
3,721件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Dead Peer Detection and Tunnel Monitoring https://live.paloaltonetworks.com/t5/Configuration-Articles/Dead-Peer-Detection-and-Tunnel-Monitoring/ta-p/61371   概要 デッド ピア検出(DPD)とは、非アクティブまたは使用不能なインターネット鍵交換(IKE/Phase1)ピアを検出する方法で、RFC 3706に記載されている機能を指します。トンネル モニタリングはPalo Alto Networks独自の機能で、IPSEC トンネルの対向インターフェイスに対してPINGを送信することで、IPSEC トンネルをトラフィックが正常に通過することを確認します。トンネル モニタリングを"モニター プロファイル"と組合わせて使用することで、トンネル インターフェースをダウンさせるとともに、ルーティングを更新し、トラフィックをセカンダリ ルートを用いてルーティングできるようにします。トンネル モニタリングはDPDを必要としません。デッド ピア検出はIPSEC トンネルの両端で有効または無効にする必要があり、片方が有効でもう片方が無効の状態の場合、VPNの信頼性に問題を引き起こす可能性があります。   詳細 デッド ピア検出 DPDはIKE-SA (Security Association and IKE, Phase 1) の死活監視機能です。 DPDはピア デバイスがまだ有効なIKE-SAを持っているかどうかを検出するために使用されます。定期的に"ISAKMP R-U-THERE" パケットをピアに送信し、ピアは"ISAKMP R-U-THERE-ACK" パケットで確認応答します。   Palo Alto Networksは現時点でDPD パケットに関連するログをもっていませんが、デバッグ パケット キャプチャで検出できます。以下はピア デバイスからのpcapです:   Mar  4 14:32:36 ike_st_i_n: Start, doi = 1, protocol = 1, code = unknown (36137), spi[0..16] = cd11b885 588eeb56 ..., data[0..4] = 003d65fc 00000000 ... Mar  4 14:32:36 DPD; updating EoL (P2 Notify Mar  4 14:32:36 Received IKE DPD R_U_THERE_ACK from IKE peer: 169.132.58.9 Mar  4 14:32:36 DPD: Peer 169.132.58.9 is UP status_val: 0.   DPD のクエリと遅延間隔は、Palo Alto Networks デバイスでDPDが有効になっているときに設定できます。DPDはピアが応答しなくなったことを認識するとSAを破棄します。 注: DPDは永続的ではありません、またフェーズ2のRe-Keyによってのみトリガーされます。つまりフェーズ2が稼働している場合、Palo Alto Networks ファイアウォールはIKE-SAがアクティブかどうかを確認しません。フェーズ1のIKE-SAを確認するためのDPDをトリガーするために、フェーズ2のRe-Keyをトリガーするには、トンネル モニタリングを有効にします。   トンネル モニタリング トンネル モニタリングはIPSec トンネル全体の接続性を確認するために使用されます。トンネル モニター プロファイルを作成する際に、トンネルが使えない場合の2つのアクション オプションとして、"回復を待機(Wait Recover)"か"フェイル オーバー(Failover)"のどちらかを指定します。 回復を待機: トンネルが回復するまで待機し、他のアクションは実行しません。 フェイル オーバー: 利用可能な場合、トラフィックをバックアップ パスにフェイル オーバーします。 どちらの場合も、復旧を早めるためファイアウォールは新しいIPsec キーのネゴシエートを行います。 指定されたアクションを実行する前に待機するハートビートの数を指定するために、"しきい値(Threshold)"オプションを設定することができます。この範囲は2~100で、デフォルトは5です。"ハートビート間隔(Interval)"も設定できます。範囲は2~10で、デフォルトは3秒です。   以下に示すように、トンネル モニタリング プロファイルが作成できたら、それを選択し監視するリモート エンドのIP アドレスを入力します。   著者: panagent
記事全体を表示
tsakurai ‎07-31-2018 06:27 PM
4,786件の閲覧回数
0 Replies
1 Like
※この記事は以下の記事の日本語訳です。 macOS X 10.13 & iOS 11 - New Requirements for GlobalProtect Connections https://live.paloaltonetworks.com/t5/Configuration-Articles/macOS-X-10-13-amp-iOS-11-New-Requirements-for-GlobalProtect/ta-p/179049 この情報の入手先についてはAppleのサポート記事 https://support.apple.com/en-us/HT207828(英文)https://support.apple.com/ja-jp/HT207828(日本語)を参照してください。   要約するとこれらのリリースには次の要件が含まれています: SHA-1 証明書を使用した TLS 接続はサポートされなくなります。TLS サービスの管理者の方は、SHA-2 証明書を使うようにサービスをアップデートしてください。 すべての TLS 接続において、RSA 鍵長が 2048 ビット未満の証明書は信頼対象から除外されます。 TLS 1.2 を EAP-TLS ネゴシエーションのデフォルトとして使用します。このデフォルト設定は、構成プロファイルで変更できます。古いクライアントでは引き続き 1.0 が必要な場合もあります。 注: GlobalProtect ポータルとゲートウェイの"SSL/TLS サービス プロファイルの最大バージョンが"TLSv1.1"と設定されている場合、iOS 11とMac OS X 10.13のどちらのシステムでも接続を確立できます。最大バージョンが"TLSv1.2"または "max"に設定された状態で設定がコミットされると、GlobalProtect エージェントは接続に成功します。   iOS 11における変更点(原文) Security iOS 11, tvOS 11, and Mac OS High Sierra include the following changes to TLS connections: Removes support for TLS connections using   SHA-1 certificates. Administrators of TLS services should update their services to use SHA-2 certificates. Removes trust from certificates that use RSA key sizes smaller than 2048 bits across all TLS connections. Uses TLS 1.2 as the default for EAP-TLS negotiation. You can change this default setting with a configuration profile. Older clients might still need 1.0. Authentication based on client certificates requires the server to support TLS 1.2 with cipher suites that are compatible with forward secrecy. macOS High Sierra における変更点(原文) Security macOS High Sierra, tvOS 11, and iOS 11 include the following changes to TLS connections: Removes support for TLS connections using SHA-1 certificates. Administrators of TLS services should update their services to use SHA-2 certificates. Removes trust from certificates that use RSA key sizes smaller than 2048 bits across all TLS connections. Uses TLS 1.2 as the default for EAP-TLS negotiation. You can change this default setting with a configuration profile. Older clients might still need 1.0. Authentication based on client certificates requires the server to support TLS 1.2 with cipher suites that are compatible with forward secrecy.   著者: jjosephs
記事全体を表示
tsakurai ‎07-02-2018 02:45 AM
5,216件の閲覧回数
0 Replies
1 Like
※この記事は以下の記事の日本語訳です。 Advanced VPN IPSec troubleshooting 8.0 (enable debugging per VPN peer) https://live.paloaltonetworks.com/t5/Management-Articles/Advanced-VPN-IPSec-troubleshooting-8-0-enable-debugging-per-VPN/ta-p/169303   PAN-OS 8.0以降より、IPSec VPNのpeer を指定してdebug ログを有効にすることができます。   PAN-OS 8.0以前:  admin@PA-VM-7.1> debug ike > global   global > pcap     pcap > socket   socket > stat     show IKE daemon statistics    PAN-OS 8.0 以降:  admin@PA-VM-8.0> debug ike > gateway   debug IKE gateway > global    global > pcap      pcap > socket    socket > stat      show IKE daemon statistics > tunnel    debug IPSec tunnel     "gateway" もしくは "tunnel" のキーワードを使用して、指定したVPN ゲートウェイもしくはIPSec トンネルでのみdebug ログを有効にすることができます。   例:  admin@PA-VM-8.0> debug ike gateway IKE-GW-HQ > clear   clear IPSec tunnel statistics > off     Turn off IPSec tunnel debug logging > on      Turn on IPSec tunnel debug logging > stats   show IPSec tunnel statistics admin@PA-VM-8.0> debug ike gateway IPSEC-HQ > clear   clear IPSec tunnel statistics > off     Turn off IPSec tunnel debug logging > on      Turn on IPSec tunnel debug logging > stats   show IPSec tunnel statistics   注: 指定できるフィルタはIKE ゲートウェイ、IPSec トンネル併せて 5 つまでです。     VPN IPSEC トラブルシューティングの情報についてはこちらもご覧ください。(英文) https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Troubleshoot-IPSec-VPN-connectivity-issues/ta-p/59187
記事全体を表示
anishinoya ‎06-25-2018 10:05 PM
2,862件の閲覧回数
0 Replies
 ※この記事は以下の記事の日本語訳です。 Error: Failed to find PANGP virtual adapter interface when connecting to GlobalProtect https://live.paloaltonetworks.com/t5/Management-Articles/Error-Failed-to-find-PANGP-virtual-adapter-interface-when/ta-p/65259   事象 このエラーは、通常、GlobalProtectクライアントがアップグレードされたか、GlobalProtectが正しくインストールされていない場合に見られるものです。   解決策 以下の手順を実施してください。   WMIサービスを無効にします:ファイル名を指定して実行 - services.msc - Windows Management Instrumentation(WMI) - 停止 C:\Windows\System32\wbem\Repository 下のファイルを削除します regeditを開く HKEY_LOCAL_MACHINE > Software and HKEY_CURRENT_USER > Software に移動します。 Palo Alto Networks フォルダを削除します。 同じフォルダがHKEY_USERSの下の他のユーザーに存在する場合は、同じフォルダを削除します。 Windowsの「プログラムと機能」からGlobalProtectをアンインストールします。 仮想アダプタがネットワークアダプタの設定に存在しないことを確認します。 マシンを再起動します。 管理者権限でGlobalProtectを再インストールします。 WMIサービスが実行されていることを確認します。 これで問題が解決するはずです。   著者: rchougale
記事全体を表示
dyamada ‎04-17-2018 09:11 PM
2,718件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。   TCP MSS adjustment for IPSec traffic https://live.paloaltonetworks.com/t5/Learning-Articles/TCP-MSS-adjustment-for-IPSec-traffic/ta-p/74988   IPSec 通信において、パロアルトネットワークス・ファイアウォールは 3ウェイ ハンドシェイクを介して TCP MSSを 自動 調整します。これは、 VPNの外部インターフェース設定で、 TCP MSS 調整機能オプションを有効に設定しているのとは関係なく動作するものです。   MSS 計算結果は以下の 2つの値の小さい方を使用します。   トンネル・ インターフェースの MTU - 40 bytes インターフェイス MTU、 暗号化、 認証アルゴリズムをベースに計算した MSS値   オリジナル パケット サイズ、暗号化アルゴリズム、認証アルゴリズム、インターフェイスの MTUとの関連性   以下の構成について考えてみます :   クライアント  ——— パロアルト ——— インターネット  ——— 対向ファイアウォール ——— サーバー                                  \____ __ __ __ ______(IPSec) __ __ __ __________/   クライアント MTU : 1500 サーバー MTU: 1500 終端 VPN 装置インターフェイスの MTU : 1500 トンネル・インターフェースの MTU : 1500 暗号化アルゴリズム : AES-256-CBC 認証アルゴリズム : SHA1   ESP オーバーヘッド : ( 全ては bytes 表示 )   Outer IP Header 20 Sequence Number 4 SPI 4 Initialisation Vector 16 ESP Padding [0-15] Padding Length 1 Next Header 1 Authentication Data 12     Total [58-73]   暗号化アルゴリズム ( AES-256) と 認証アルゴリズム ( SHA1) は最大 73 bytes のオーバーヘッドを生成します。   オリジナル パケット サイズ + 最大オーバーヘッド  <= 1500 TCP セグメント + TCP ヘッダー + IP ヘッダー + 最大オーバーヘッド  <= 1500 TCP セグメント + 20 bytes + 20 bytes +  73 bytes <= 1500 TCP セグメント <= 1387 bytes   もし MSS が 1388 bytes 使用する場合、 ESP ヘッダーは 1496 bytes となります。 (パディングは10 bytes のみです )     上記から、   トンネル・ インターフェース MTU からの MSS 計算結果 = 1500 - 20 Bytes (IP ヘッダー ) - 20 bytes (TCP ヘッダー ) = 1460 Bytes インターフェイス MTU, 暗号化 , 認証アルゴリズムによる MSS 計算結果 = 1388 Bytes   最終的な MSS 計算結果 : 小さい方 (1460, 1388) = 1388.   同様の計算手法は、様々な暗号化/ 認証アルゴリズム の組み合わせに対して使うことができます。いくつかのよく使われる値は :   初期ベクターのサイズ AES : 16 bytes DES : 8 bytes   認証データのサイズ MD5/ SHA-1 :  12 bytes SHA-256 : 16 bytes SHA-384 : 24 bytes SHA-512 : 32 bytes   パディングされる最大値 AES : 15 bytes DES : 7 bytes   注意 :   上記の値は、 PAN-OS 6.0 以降のバージョンで試験されたものです。 上記の例にて、もしインターフェイスの MTU が 1400 に設定されていた場合、 MSS の結果は 1388 でなく、 1360 になるでしょう。   上記の計算様式は、IPSecトンネルのMSS調整の計算にも使われます。もしファイアウォールがESPオーバーヘッドを考慮して自動調整をしなければ、 TCP調整のために 適切なMTUの値をトンネル・インターフェースに設定します。   例えば、上記の例で、ファイアウォールが ESP オーバーヘッドを考慮してMSS値を調整しないのであれば、トンネル・インターフェースの MTUに 1387 + 40 = 1427 bytes を 設定することもできます。これは結果的に MSS 値が、 1387 bytes に調整されるのと同じになります。   これらは、IPSecト ン ネル上で動作する、TCPアプリケーションのパフォーマンスを向上させます。   著者: abjain
記事全体を表示
kkondo ‎04-05-2018 05:50 AM
5,478件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Certificate config for GlobalProtect - (SSL/TLS, Client cert profiles, client/machine cert) https://live.paloaltonetworks.com/t5/Configuration-Articles/Certificate-config-for-GlobalProtect-SSL-TLS-Client-cert/ta-p/131592   この文書はGlobalProtectセットアップにおける証明書の設定の基礎について説明します。この文書でカバーされないGlobalProtect用の証明書の展開方法もありうることを、ご承知おきください。   A. SSL/TLS サービス プロファイル - ポータル/ゲートウェイのサーバー証明書用。ポータル/ゲートウェイはこれを一つ必要とします。 B. 証明書プロファイル(必要に応じて) - ポータル/ゲートウェイがクライアント/マシン証明書を要求するために使用します。 C. クライアント機器へのクライアント/マシン証明書のインストール     A. SSL/TLS サービス プロファイル GlobalProtectの枠組みにおいて、このプロファイルはGlobalProtectポータル/ゲートウェイの"サーバー証明書"と、SSL/TLSプロトコルのバージョン範囲の規定に使用されます。同じインターフェイスがポータルとゲートウェイ両方に使われている場合、同じSSL/TLS サービス プロファイルをポータル/ゲートウェイに使用できます。異なるインターフェイスで ポータル/ゲートウェイを通して提供する場合、証明書が両方のポータル/ゲートウェイのIP/FQDNをそのサブジェクト代替名(SAN)に含んでいれば同じSSL/TLS サービス プロファイルを使用できます。含んでいない場合は、ポータルとゲートウェイにそれぞれ異なるプロファイル作成します。   SSL/TLS サービス プロファイルに"サーバー証明書"とそのチェーンをインポート/生成するには、以下のとおり操作します。 外部で作成した証明書をインポートするには、Device > 証明書の管理 > 証明書 に移動し、下部にある'インポート'をクリックします。 ファイアウォールで証明書を生成するには、Device > 証明書の管理 > 証明書 に移動し、下部にある'生成'をクリックします。   サーバー証明書が公なサードパーティ認証局や内部のPKIサーバーによって署名されている場合 1. ルート認証局証明書をインポートします(秘密鍵のインポートはオプションです)。 2. 中間認証局証明書がある場合はインポートします (秘密鍵のインポートはオプションです)。 3. 上記の認証局によって署名された証明書を秘密鍵とともにインポートします。     重要! サブジェクト代替名(SAN)がない証明書の場合:この証明書の共通名(CN)はポータル/ゲートウェイのIPまたはFQDNにマッチしなければなりません。 サブジェクト代替名が1つ以上存在する場合、そのポータル/ゲートウェイで使用されるIPかFQDNは、SANのリストの中の一つにマッチしなければなりません。 認証局であってはなりません。エンド エンティティでなければなりません。 ベスト プラクティスとして、IPよりFQDNの使用が望ましいです。設定上、およびエンドユーザーによるGlobalProtect クライアント上での"ポータル:"欄での入力において、FQDN/IPを一貫して使用するようにしてください。例えば、ポータル/ゲートウェイがFQDN   'vpn.xyz.com' かIP '1.1.1.1'で到達できるとします。証明書の参照が'vpn.xyz.com'であれば、ユーザーは1.1.1.1ではなく、'vpn.xyz.com'を使用しなければなりません。   4. SSL/TLS サービス プロファイル (  Device > 証明書の管理 > SSL/TLS サービス プロファイルにあります) 名前 - 任意の名前を入力します 証明書   - 前述の手順3のサーバー証明書を参照します プロトコル設定   - クライアント サーバー間のsslトランザクションで使用されるssl/tlsの最小と最大のバージョンを選択します   5. このSSL/TLS サービス プロファイルを、必要なポータル/ゲートウェイで参照します。   サーバー証明書をPalo Alto Networksファイアウォールで生成する必要がある場合 1. ルート証明書をユニークな共通名(ポータル/ゲートウェイのIP、FQDN以外)で生成します   ( Device > 証明書の管理 > 証明書にて下部の "生成"をクリックします)   2. (オプション )上記のルート証明書で署名をした中間証明書を生成します。共通名はユニークなもの(ポータル/ゲートウェイのIP、FQDN以外)にします。   3. 上記の中間証明書で署名されたサーバー証明書を生成 a. この証明書の共通名は、サブジェクト代替名(SAN)が存在しない場合、ポータル/ゲートウェイのIPかFQDNにマッチ思案ければなりません。Palo Alto Networks ファイアウォールではSANは'証明書の属性'のタイプを'Host Name'、'IP'、'Email'で作成できます。 b. 一つ以上のSANがある場合、ポータル/ゲートウェイで使用するIPかFQDNがSANのリストに存在しなければなりません。 c.  認証局であってはいけません。 d. 実践においては、IPではなくFQDNの使用が望ましいです。 設定上、およびエンドユーザーによるGlobalProtect クライアント上での"ポータル:"欄での入力において、FQDN/IPを一貫して使用するようにしてください。例えば、ポータル/ゲートウェイがFQDN   'vpn.xyz.com' かIP '1.1.1.1'で到達できるとします。証明書の参照が'vpn.xyz.com'であれば、ユーザーは1.1.1.1ではなく、'vpn.xyz.com'を使用しなければなりません。        4. SSL/TLS サービス プロファイル (  Device > 証明書の管理 > SSL/TLS サービス プロファイルにあります) 名前 - 任意の名前を入力します 証明書   - 前述の手順3のサーバー証明書を参照します プロトコル設定   - クライアント サーバー間のsslトランザクションで使用されるssl/tlsの最小と最大のバージョンを選択します    5. このSSL/TLS サ ービス プロファイルを、必要なポータル/ゲートウェイで参照します。   B. 証明書プロファイル ( Device > 証明書の管理 > 証明書プロファイルにあります) 証明書プロファイルは認証局と中間認証局のリストを定義します。証明書プロファイルが設定上で適用されると、ポータル/ゲートウエイは、証明書プロファイルの認証局または中間認証局で署名されたクライアント/マシン証明書クライアント証明書を、クライアントに要求します。このプロファイルにはルート認証局だけでなく、中間認証局も設定することを奨めます。    重要! - 'user-logon’/'on-demand'が接続方式となっているとクライアント証明書はユーザーの証明書となり、ユーザーの認証に使用されます。 - 'pre-logon'が接続方式となっているとクライアント証明書はマシン証明書となり、ユーザーではなく、機器の認証に使用されます。   1. クライアント/マシン証明書を署名したルート認証局をDevice > 証明書の管理 > 証明書  にて インポートします(秘密鍵はオプション)。 2. クライアント/マシン証明書を署名した中間認証局がある場合は、Device > 証明書の管理 > 証明書 にてインポートします (秘密鍵はオプション)。 3. Device > 証明書の管理 > 証明書プロファイル に移動して、追加をクリックします。 4. プロファイルの名前を入力します。 5. 手順1と2のルート認証局証明書と中間認証局証明書を追加します。   6. 注: ユーザー名フィールドはデフォルトで'None'となっており、典型的なセットアップではLDAP/RADIUS認証から引用されるので、'None'のままとしておくことができます。一方、証明書のみによる認証の場合(つまりポータル/ゲートウェイが使用するRADIUS/LDAPがない場合)、ユーザー名フィールドはユーザー名をクライアント証明書の共通名またはEmail/プリンシパル名から抽出するために'None'から'サブジェクト'または'サブジェクト代替名'に変更しなければなりません。さもないとCommit失敗となります。   7. (オプション)CRLまたはOSCPによるクライアント/マシン証明書の無効化ステータスの確認が必要な場合、'証明書状態が不明な場合にセッションをブロック'をチェックしていると、クライアントの接続に失敗しますのでご注意ください。   8. この証明書プロファイルを必要なポータル/ゲートウェイから参照します。   C. クライアント/マシン証明書をクライアント端末にインストール   クライアント/マシン証明書をインポートする際、秘密鍵を含むPKCSフォーマットでインポートを行ってください。   Windows での手順を以下に説明します。   1.スタート > ファイル名を指定して実行にてmmcを入力して、Microsoft 管理コンソールを開きます: 2. ファイル > スナップインの追加と削除をクリックします。     重要! 3. 証明書 > 追加 を行い、以下のどちらか、ないしは両方を行います:     a. クライアント(ユーザー)証明書を'ユーザー アカウント'を選択して追加します。これは  ' user-logon 'と' on-demand 'で ユーザーを認証するためです。 b. マシン(機器)証明書を'コンピューター アカウント'を選択して追加します。これは  ' pre-logon ' でマシンを認証するためです。             4. クライアント/マシン証明書をmmcにインポートします。 a. クライアント証明書をインポートする場合、'証明書-現在のユーザー'下の'個人'フォルダにインポートします。 b. マシン証明書をインポートする場合、'証明書(ローカル コンピューター)' 下の'個人'フォルダにインポートします。         5. 同様にルート認証局証明書を'信頼されたルート証明機関'に、(あれば)中間認証局証明書を'中間証明機関'にインポートします。     重要! 6. 一旦インポートしたら、インポートしたクライアント/マシン証明書をダブルクリックして、以下を確認します。 a. 秘密鍵(訳注:日本語版Windowsでは"秘密キー"と表記されます)を持っているか。 b. ルート認証局までの完全な証明書チェーンがあるか。もしルート認証局や中間認証局までのチェーンに欠落がある場合は、手順5での説明に従い、それらの認証局証明書を該当するフォルダーにインポートします。           7.この時点で証明書はクライアントにインストールされていますので、mmcコンソールをセーブすることなくクローズして構いません。
記事全体を表示
TShimizu ‎03-07-2018 09:54 PM
9,397件の閲覧回数
0 Replies
1 Like
※この記事は以下の記事の日本語訳です。 How to Configure Global Protect Gateway on Loopback Interface with iPhone Access https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-Global-Protect-Gateway-on-Loopback-Interface/ta-p/56866   httpsでないGlobal Protectポータルの使用に加えて、loopbackインターフェイスに紐付けられたゲートウェイにアクセスすることが可能です。Publicネットワークで使用できるIPアドレスが一つのみしかなく、OWAのようなSSLベースのアプリケーションをそのIPでもホストしたい場合、以下の設定手順を参照してください。 別のナレッジ記事   How to Configure GlobalProtect Portal Page to be Accessed on any Port   も参照してください。1つ目のloopbackインターフェイスに加えて、ポータルのために2つ目のloopbackインターフェイスが必要になるでしょう。   追加のloopbackインターフェイスの作成 untrustに属するインターフェイスから、loopbackに対してPingが可能であることを確認しておきます。 > ping source 99.7.172.157 host 10.1.1.     PING 10.1.1.2 (10.1.1.2) from 99.7.172.157 : 56(84) bytes of data.     64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=0.126 ms     64 bytes from 10.1.1.2: icmp_seq=2 ttl=64 time=0.068 ms         loopbackインターフェイスをポータルのアドレスとして割り当てます。 loopback.1インターフェイスをゲートウェイのアドレスとして割り当てます。   以下のサービス群、およびそれらを含むサービスグループの作成 これらのサービスはゲートウェイのループバックインターフェイスにてアドレス変換されます。この例では、宛先とするポートは500 (ike/ciscovpn), 4501 (ipsec-esp-udp)です。 定義済みのservice-httpsに加えて、2つのカスタムサービスが"gateway"サービス グループ プロファイルに追加されています。   サービスの作成     サービス グループ オブジェクトへのサービスの追加 必要なセキュリティ ポリシーを作成します。 先のナレッジ記事に記載したとおり、SSL標準ポート宛でないトラフィックを最初のループバック インターフェイスにリダイレクトするためのルールが必要です。 ここではGPポータルはポート443ではなく、ポート7000でアクセスできます。このルールの下に、ゲートウェイへのike、ipsec、panos-global-protect、sslそしてweb-browsingをそれぞれ許可するルールを作成します。       2つ目のループバック インターフェイス(loopback.1)にトラフィックを向けるNATポリシーを作成します。 loopback.1インターフェイスに先に設定した10.1.1.2にトラフィックを向けるために、この例ではgateway サービス グループを使用します。       ゲートウェイ上でのiPhone/iPad用の設定 'X-Auth サポート'を有効化してグループ名とグループ パスワードをそれぞれ設定します。これはモバイル機器のVPNプロファイル設定の際に利用されます。     VPNプロファイルを先の手順で設定した共有秘密鍵を使用して作成します。該当のプロファイルのパスワードは選択した認証方式と合わせる必要があります。(LDAP、Kerberos、ローカル データベースなど)   モバイル デバイスと同様に Global Protectクライアント経由でのアクセスを確認します。   > show global-protect-gateway current-user           GlobalProtect Name : gp-gateway (2 users)         Domain User Name      Computer        Client          Private IP      Public IP      ESP    SSL    Login Time      Logout/Expiration TTL       Inactivity TTL         ------ ---------      ---------      ----------      ---------      ---    ---    ----------      ----------------- ---      -----------   ---               \renato          PAN01347        Windows 7 (Version 6.1 Build 7601 Service Pack 1)10.10.10.2      64.124.57.5    exist  none    Oct.02   06:04:01 Nov.01 06:04:01  2589926  9641               \renato          64.124.57.5    iPhone OS:6.0  10.10.10.1      64.124.57.5    exist  none    Oct.02 06:38:33 Oct.02 07:39:33  3657       10798     著者: rkalugdan
記事全体を表示
TShimizu ‎11-06-2017 05:43 PM
4,344件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Stop GlobalProtect from Loading Automatically at Startup https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Stop-GlobalProtect-from-Loading-Automatically-at-Startup/ta-p/60506   手順 システム起動時の他のスタートアップ アプリケーションとともに、GlobalProtectクライアントがロードされることを止める方法は以下のとおりです。   Windows 7 とそれ以前 スタートメニューから"msconfig"を実行します(訳注:"プログラムとファイルの検索"のボックス、または"ファイル名を指定して実行"に"msconfig"と入力します。)。システム構成のウィンドウが表示されます。 スタートアップ タブに移動します。GlobalProtectのチェックを外し、OKをクリックした後、システムを再起動します。 Windows 7 System Configuration window showing the StartUp applications and options.   Windows 10: Windows 10ではこの機能はタスクマネージャーのシステム構成に移動されています。それにより2つの方法でシステム構成に到達できるようになっています。 スタート > ファイル名を指定して実行 > msconfigを実行し、"スタートアップ"をクリックします。タスクマネージャーを起動するリンクが有ります。 System Config showing you have to open Task Manager . あるいは "Control + Shift + Esc"、ないしはWindowsのタスクバーの空白部分にて右クリックし、”タスクマネージャー”をクリックすることでタスクマネージャーを開始できます。その後に"スタートアップ"タブをクリックしてください。    スタートアップタブにて”GlobalProtect client”を確認します。それを右クリックし"無効化"をクリックする、ないしは一度クリックしWindowの最下部にある"無効にする"をクリックします。 Task Manager screen showing the options to disable GlobalProtect.  訳注1:"プログラムとファイルの検索"のボックス、または"ファイル名を指定して実行"に"msconfig"と入力します。   著者: tshivkumar  
記事全体を表示
TShimizu ‎11-06-2017 05:39 PM
4,217件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Password Expiry Warning on the GlobalProtect Client https://live.paloaltonetworks.com/t5/Configuration-Articles/Password-Expiry-Warning-on-the-GlobalProtect-Client/ta-p/52737   概要 LDAPを認証方法として使用している場合、Global Protectユーザーはパスワードの期限が切れた際の失効の警告メッセージを受けます。   詳細 これは、以下の通りGlobal Peotectに用いるファイアウォール上の認証プロファイルでLDAPを指定することで実現できます。   ファイアウォール上のGlobal Protect用 認証プロファイルの設定 サーバー プロファイル: 設定したLDAP プロファイルを指定している。 ログイン属性: ユーザーまたはグループを一意に示すLDAP ディレクトリ属性を入力します。 パスワード失効の警告: パスワード失効の前に、パスワードはあとX日で期限切れとなることを、ユーザーに警告する通知メッセージを表示し始める日数を(1から255日の範囲で入力できます)入力します。   デフォルトでは通知のメッセージはパスワード失効の7日前に表示されます。パスワードが失効するとユーザーはVPNでのアクセスができなくなります。 下記スクリーンショットのとおり、ADサーバー上では、デフォルトのドメイン ポリシーの maximum password age (パスワードの有効期限)を設定して下さい。   以下はGlobal Protectクライアントでの警告メッセージです。     注: ベストプラクティスとして、接続手段としてpre-logonを設定することを考慮してください。これによりユーザーはパスワードの失効後であっても、パスワード変更のためのドメインへの接続を許可されます。   著者: hnatarajan  
記事全体を表示
TShimizu ‎08-14-2017 11:01 PM
6,209件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 GlobalProtect Client Stuck at Connecting when Workstation is on the Local Network https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-Client-Stuck-at-Connecting-when-Workstation-is-on/ta-p/53795   症状 GlobalProtectクライアントがインストールされた端末が、社内ネットワークに接続している際に、GlobalProtectゲートウェイ、ポータルに接続できないことがあります。一方で、インターネットからの接続は問題なくできます。   問題 典型的な状況として、GlobalProtectクライアントは社内ネットワーク接続する時に、GlobalProtectゲートウェイ、ポータルの外部インターフェイスに接続しようとします。接続が失敗する理由としては、ファイアウォールが内部ゾーンから外部ゾーンへの通信として識別し、それが外部IPアドレスへの接続である為、ソースアドレスをNAT変換します。パケットの宛先は既に外部インターフェイスのIPであり、宛先と送信元アドレスが同じになり、意図しないLAN攻撃を作り出します。それによりファイアウォールはこれらのセッションを破棄します。詳しくはUnable to Connect to or Ping a Firewall Interfaceを参照ください。   解決方法 GlobalProtectポータルのライセンスがファイアウォール上で有効である場合、最適な方法としては、内部ゲートウェイを設定し、GlobalProtectクライアントにその内部ゲートウェイを検索させ、接続させることです。そうすることにより社内ネットワーク接続にトラフィックをトンネリングしないようにします。詳しくはGlobalProtect Configuration Tech Noteをご参照ください。   しかしながら上記の設定では、内部ユーザの外部GlobalProtectポータルへの接続が有効になりません。 もしポータルへの接続が必要な場合、もしくはライセンスがない場合、ファイアウォールの外部インターフェイス接続に使用する、例外的に動作するデフォルトの外部NATルールとして設定できます。 外部向けNATルールをクローンで作成します。 そのルールを既存の外部向けNATルールの上位に移動します。 ルールの名前を変更します。 外部インターフェイスのIPアドレスを、元のアドレスの宛先アドレスフィールドに追加します。 送信元アドレスの変換をNoneに変更します。 この設定により内部ユーザが外部ゲートウェイ、ポータルに対してソースアドレスの変更、パケットドロップなしに接続することができます。ユーザが外部ゲートウェイに接続している場合、そのトラフィックは暗号化され、内部ネットワークから外部インターフェースへ送られています。 著書: astanton
記事全体を表示
kkondo ‎08-09-2017 10:35 PM
9,035件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 GlobalProtect app on Android 6.0+ cannot establish VPN connection using IP address https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-app-on-Android-6-0-cannot-establish-VPN-connection/ta-p/140190   事象 以下の状況において、Android 6.0以降の GlobalProtect アプリ でVPNを接続できない場合があります:   GlobalProtect ポータル/ゲートウェイの証明書を証明する ルートCA 証明書がAndroid 端末にインストールされている GlobalProtect ポータル/ゲートウェイの証明書の コモンネーム (Common Name, CN) が IP アドレスになっている   接続できない状況では、次のメッセージが表示されます : Cannot connect to GlobalProtect portal     GlobalProtect アプリケーションで取得する Gp.log では、以下のようなエラーが出力されます: (6227)01/05 17:55:33:120201 - javax.net.ssl.SSLPeerUnverifiedException: Hostname 192.168.206.1 not verified: certificate: sha1/5BHzss0x9EpOd9YtEPZcwtCNaOQ= DN: CN=192.168.206.1,ST=Tokyo,C=JP subjectAltNames: [192.168.206.1] (6227)01/05 17:55:33:120352 - exception GetHttpResponse, response code is 0 (6227)01/05 17:55:33:120521 - response from server is: null, exception Message: Hostname 192.168.206.1 not verified: certificate: sha1/5BHzss0x9EpOd9YtEPZcwtCNaOQ= DN: CN=192.168.206.1,ST=Tokyo,C=JP subjectAltNames: [192.168.206.1] eType:javax.net.ssl.SSLPeerUnverifiedException: Hostname 192.168.206.1 not verified: certificate: sha1/5BHzss0x9EpOd9YtEPZcwtCNaOQ= DN: CN=192.168.206.1,ST=Tokyo,C=JP subjectAltNames: [192.168.206.1] (6227)01/05 17:55:33:120557 - (l5)JNI,6243,508,not handled, ret=error, javax.net.ssl.SSLPeerUnverifiedException: Hostname 192.168.206.1 not verified: certificate: sha1/5BHzss0x9EpOd9YtEPZcwtCNaOQ= DN: CN=192.168.206.1,ST=Tokyo,C=JP subjectAltNames: [192.168.206.1], return NULL now     原因 これはアンドロイドOS 6.0以降における新しい挙動によるものです。   Android 6.0より、証明書の CN が IP アドレスである場合、その IP アドレスは「サブジェクトの別名 (Subject Alternative Name, subAltName, SAN)」にも存在していることを確認します。もし IP アドレスが subAltName に存在しない場合、証明書の検証に失敗します。 古い バージョンの Android では、CN が一致している場合には検証に成功します。       解決策 GlobalProtect ポータル/ゲートウェイの証明書として iPAddress subAltName フィールドを持つような証明書を生成し、既存の証明書を置き換えます。   以下のスクリーンショットでは、Palo Alto Netrwork 次世代ファイアウォールで iPAddress subAltName を設定する方法を示しています。   証明書の生成時、Type に "IP" を追加し、IP アドレスを Value フィールドに入力します。     生成された証明書には Subject Alternative Name にIPアドレスが存在しています :   この証明書をGlobalProtect ポータル/ゲートウェイの証明書として設定します。その後、VPN接続が確立可能となります。   GlobalProtect 用のサーバ証明書の設定方法は以下のガイドをご確認ください:  Deploy Server Certificates to the GlobalProtect Components      他の方法として、GlobalProtect Portal / Gateway を証明するルートCA証明書をAndroid端末から削除する方法があります。(多くの場合 "Setting > Security > Trusted credentials" から可能)   この場合、GlobalProtect アプリは"信頼できない証明書"であることを示す警告を一度表示し、その後接続が確立されます。       この方法は、ユーザ自身によるVPN接続先の正当性の確認が必要となるため、推奨されません。  
記事全体を表示
dyamada ‎05-09-2017 11:55 PM
7,786件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Dual ISP Branch Office Configuration https://live.paloaltonetworks.com/t5/Configuration-Articles/Dual-ISP-Branch-Office-Configuration/ta-p/59346     この資料は、拠点オフィスのデュアル ISPの設定方法について記載します。今回のシナリオでは、外向けの接続に冗長性を持たせるため、オフィスは2つのISPに接続されています。この設定では、スタティック ルーティングやポリシー ベース フォワーディング (PBF)、宛先・送信元NATを使用します。 ISP間でBGPルーティング プロトコルを必要とすることなく、自動的に外向けのインターネットの冗長性を提供します。   注:この資料は、PAN-OS 5.0やそれ以降のバージョン用に更新されています。複数の外部ゾーンは必要ありません。     著者:kbrazil
記事全体を表示
hshirai ‎08-23-2016 12:15 AM
3,202件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure GlobalProtect Portal Page to be Accessed on any Port https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-GlobalProtect-Portal-Page-to-be-Accessed-on-any/ta-p/53460   訳注:GlobalProtectの設定画面はPAN-OS Versionにより大幅に異なります。ご使用になるPAN-OSバージョンのWebインターフェイス リファレンス ガイドを合わせてご参照ください。   GlobalProtectが使用するポートを変更することはできませんが、ループバック IPアドレスとセキュリティ ルールによって他のポートを使うことができます。   設定方法: ループバック Interfaceを作成します。 Untrustのインターフェイスが、ループバックにpingできることを確認しておきます。 ポータルのアドレスとゲートウェイのアドレスに、ループバックアドレスを設定します。 GlobalProtectポータルにて、[クライアントの設定]タブよりクライアントの設定を作成し、[外部 ゲートウェイ]を設定します (例:10.30.6.56:7000) 。 ポート番号7000を使用する10.30.6.56 (Untrustのインターフェイス)が、ポート番号443を使用する10.10.10.1 (ループバック) に変換される宛先NATルールを作成します。 Untrustのインターフェイスを宛先アドレスとし、ポート番号7000と443をサービスとしてセキュリティ ポリシーを作成します。 この設定を行うことで、https://10.30.6.56:7000 でGlobalProtectポータルにアクセスできるようになります。https://10.30.6.56:7000  は https://10.10.10.1  が変換されたものです。 GlobalProtectクライアント ソフトウェアをダウンロードして、インストールします。 [ユーザー名]と[パスワード]で資格情報を使用します。[ポータル]欄では、以下の図のように10.30.6.56:7000 をIPアドレスとして使用します。                             著者:mvenkatesan
記事全体を表示
hshirai ‎07-20-2016 08:04 PM
3,733件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Verify if IPSec Tunnel Monitoring is Working https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Verify-if-IPSec-Tunnel-Monitoring-is-Working/ta-p/56466   概要 IPSecトンネル モニタは監視するIPアドレスにトンネル設定されたインターフェイスから継続的にPingを送付するメカニズムです。Ping間隔は、WebUI管理画面上のMonitorプロファイル (Network > Network Profiles > Monitor > Interval)にて設定します。 注意 : WebUI管理画面上の監視対象のIPアドレス設定は(Network > IPSec Tunnels > General Tab > Destination IP)になります。   詳細 トンネル モニタがupもしくはdownしているかのチェックは、以下のコマンドにて確認します。 > show vpn flow id  name               state     monitor  local-ip        peer-ip      tunnel-i/f ------------------------------------------------------------------------------------ 1  tunnel-to-remote    active    up       10.66.24.94     10.66.24.95  tunnel.2   上記の表示例では、モニターステータスが"up"になっていることを示します。   Pingした回数を確認するには、”show vpn flow tunnel-id <id>”コマンドで確認します。 出力例 : > show vpn flow tunnel-id 1 tunnel  tunnel-to-remote         id:                    1         type:                  IPSec         gateway id:            1         local ip:              10.66.24.94         peer ip:                10.66.24.95         inner interface:        tunnel.2         outer interface:        ethernet1/3         state:                  active         session:                6443         tunnel mtu:            1436         lifetime remain:        2663 sec         latest rekey:          937 seconds ago         monitor:                on         monitor status:        up         monitor interval:      3 seconds         monitor threshold:      5 probe losses         monitor packets sent:  739180         monitor packets recv:  732283         monitor packets seen:  584         monitor packets reply:  584         en/decap context:      76         local spi:              F18E58FF         remote spi:            B90FCFB2   上記の表示例において、 monitor packets sent - Pingが何回送付されたか monitor packets recv - 送られたPingに対して何回応答があったか monitor packets seen - 対向側の問い合わせから、受信されたモニター パケットの数 monitor packets reply - "monitor packets seen"に対して何回応答したか。トンネル インターフェイスIPに対してリクエストが作られた場合のみカウントします。   特定のトンネルの、リアルタイムのステータスを監視するためには以下のコマンドを実行してください : > show running tunnel flow tunnel-id 1 | match monitor         monitor:                on         monitor status:        up         monitor interval:      3 seconds         monitor threshold:      5 probe losses         monitor packets sent:  739180         monitor packets recv:  732283         monitor packets seen:  584         monitor packets reply:  584   もしモニターが"on"でステータスが何らかの理由で"down"場合、"monitor packets sent"が増えているにも関わらず、"monitor packets recv"は一定かもしれません。トンネルがダウンかつモニター ステータスがdownでも、"monitor packets sent"は定期的な間隔でPingを送付しているからです。   注意: トンネルがダウンした時はいつでも、Palo Alto Networks ファイアウォールはsystem logs (severityはcriticalに設定)にイベントを通知します。Criticalログに電子メールの通知設定がなされている場合、電子メール通知が送付されます。詳しくは、 How to Configure Email Alerts for System Logs? 注意   他の参照リンク Dead Peer Detection and Tunnel Monitoring CLI Commands to Status, Clear, Restore, and Monitor an IPSEC VPN Tunnel   著者: dreputi
記事全体を表示
kkondo ‎07-12-2016 12:04 AM
5,184件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Site-to-Site IPSec VPN Between Palo Alto Networks Firewall and Cisco Router using VTI Not Passing Traffic https://live.paloaltonetworks.com/t5/Configuration-Articles/Site-to-Site-IPSec-VPN-Between-Palo-Alto-Networks-Firewall-and/ta-p/62103   問題 パロアルトネットワークス ファイアウォールとCiscoルーターで仮想トンネル インターフェイス(VTI)を使用してサイト間VPNが設定されているとします。しかしIKEフェーズ2通信がパロアルトネットワークス ファイアウォールと Ciscoルーターで通りません。 まとめると、以下の状況でVPNはダウンしています。 トンネル インターフェイスがダウンしている。 IKEフェーズ1はアップしているが、IKEフェーズ2がダウンしている。   原因 PFSの不一致によりIKEフェーズ2が不一致となり、この問題が発生している可能性があります。   解決策 パロアルトネットワークス ファイアウォールとCiscoルーターが同じPFSの設定を持つように設定します。   パロアルトネットワークス ファイアウォール上では、[Network] >[IPSec 暗号]に移動します。トンネルに設定している[IPSec暗号プロファイル]を選び、DH グループの値がCiscoルーターと一致するか確認します。   Ciscoルーターではパロアルトネットワークス ファイアウォールと一致するようPFSを設定します。   以下はパロアルトネットワークス ファイアウォールのCLIで tail follow yes ikemgr.log コマンド を実行したときの出力です。 最初の赤線で囲った部分はPFSの不一致のメッセージとなります。二番目の赤線で囲った部分はPFSの不一致を修正したあとのメッセージとなります。   パロアルトネットワークス ファイアウォール上で show vpn flow tunnel-id <ID番号>  を実行すると、暗号化、復号化のパケットのカウントが増えていることを確認できます。   Ciscoルーターでは、 show crypto ipsec sa  と入力すると、暗号化、復号化のパケットが増加していることを確認できます。   著者:jlunario  
記事全体を表示
TShimizu ‎07-10-2016 10:44 PM
4,157件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 Common Issues with GlobalProtect https://live.paloaltonetworks.com/t5/Learning-Articles/Common-Issues-with-GlobalProtect/ta-p/59534   よくある問題1 GlobalProtectポータルへのログインができるものの、それ以上すすまない。   トラブルシューティング 場合によっては先のインスタンスを完全に削除したことを確認の上、Global Protectクライアント/エージェントを再度ダウンロードする必要があるかもしれません。 接続がどこで失敗しているかを確認するため、調査用のログを収集します。これらのログから認証が意図通り機能しているのか、あるいは認証設定を調整する必要があるのかを確認することができます。どのステージでエラーが発生しているのかの確認のため、GlobalProtectクライアント/エージェントからのログ収集を推奨します。ログは "トラブルシューティング> ログ > ログ  = PanGPサービス、デバッグ レベル: = デバッグ"と設定して収集することができます。 ファイアウォール上では、GlobalProtectのユーザーが接続を試行した際は、以下のログを確認して調査する必要があります。 tail follow yes web-server-log sslvpn-access.log tail follow yes mp-log authd.log   現在のユーザーをチェックするには、以下のコマンドを実行してください。 > show global-protect-gateway current-user     よくある問題 2 GlobalProtectポータルは認証に成功するが、Global Protectゲートウェイでは失敗する。   トラブルシューティング ポータルの認証の際、ユーザーの資格情報はポータルからゲートウェイに渡されます。ポータルとゲートウェイが同じ認証方法が設定されている場合、この問題は発生しません。 ゲートウェイが異なるタイプの認証方法を設定していると、ゲートウェイの認証でポータルの認証と同じユーザー名を使用していることが重要になります。もしポータルからゲートウェイに渡された資格情報をゲートウェイが認識できない場合、ユーザーは再度パスワードの入力を促されます。重要!別のユーザー名を使うことはできないため、同じユーザー名をそれぞれの認証方法で使うようにしてください。 LDAP(またはRADIUS)に加えて二要素認証(例としてRSA SecurID)を行うには、LDAP/RADIUS認証はポータルのステージで設定されなければなりません。ユーザーは最初にドメイン名とパスワードでのログインをし、それから再度(ゲートウェイによって)チャレンジ レスポンスのため RSA SecurIDトークンに表示された ワンタイム パスワードを入力します。ここでもまたユーザー名はGlobalProtectポータルとゲートウェイは同じものが使われる前提です。   著者: sjamaluddin
記事全体を表示
TShimizu ‎07-06-2016 12:48 AM
6,551件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure VPN Tunnel Between a Palo Alto Networks Firewall and Azure https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-VPN-Tunnel-Between-a-Palo-Alto-Networks/ta-p/59065   概要 このドキュメントでは、Palo Alto Networks ファイアウォールと Azure のサイト間の VPN トンネルの設定方法について説明します。現時点では、Palo Alto Networks は IKE バージョン 1 のみをサポートしています。静的 IP アドレスを使用するとAzure は IKE バージョン 1 のみをサポートします。またAzure トンネルが動的 IP アドレスで設定されている場合、Azure は IKE バージョン 2 のみをサポートします。 このためAzure トンネルは静的 IP アドレスで設定しなければなりません。     手順 Azure 側の設定情報に関しては、Azure のドキュメントを参照してください。下記例は Azure のアドレス空間の設定を示しています。 Palo Alto Networks ファイアウォール VPN エンドポイント のローカル ネットワークとそのゲートウェイ アドレスを定義する設定例: 次に、トンネル インターフェイスを設定します。 Azure ゲートウェイ サブネットと同じサブネット上の IP を割り当てます。 仮想ルータと適切なセキュリティ ゾーンを選択します。既存のゾーン (他のサーバーを含む) を選択すると、新規ポリシーを作成する必要がなくなると考えられます。 デフォルトの IKE 暗号化プロファイルの設定は、Azure の IKE 暗号化プロファイルの設定と同じである必要があります。 新規に Azure 用の IPSec 暗号化プロファイルを、ライフタイム値が同じになるように作成します。例えば、Azure のライフタイムが 3600 秒で、その値がネットワークの他のトンネルとは異なる場合、Azure 用に新規の作成が必要となります。Perfect Forward Secrecy (PFS) 無しの場合、DH グループには "no-pfs" を選択するのが正しいです。 注: ライフタイムのサイズは 98 GB になります。 トンネルがこれ 1 つのみの場合、または、他のトンネルが同一の設定を使用する場合は、デフォルトの設定を修正することができます。 IKE ゲートウェイの作成で、Palo Alto Networks ファイアウォールの外部インターフェイスを選択し、「Local IP Address」にそのインターフェイスの IP を選択します。この IP アドレスは、トンネル接続する Azure の「ローカル アドレス」にて設定された「VPN ゲートウェイ アドレス」と一致します。「Peer IP Address」は、同一の Azure 仮想ネットワークの Azure 仮想ネットワーク ダッシュボードから取得できます。「Local Identification」の IP アドレスは、同じ画面上の「Local IP Address」と一致している必要があります。「Pre-shared Key」は Azure 仮想ネットワークの Azure 仮想ネットワーク ダッシュボード上の「キーの管理」をクリックすることで取得できます。あとはコピー & ペーストするだけです。 次に、先ほど作成したトンネル インターフェイス、IKE ゲートウェイ、IPSec 暗号化プロファイルで、新規に IPSec トンネルを設定します。 「Proxy IDs」タブに移動し、適切なローカル サブネットおよびリモート サブネットで最低 1 つの ID を作成します。「Local」は、Palo Alto Networks ファイアウォール IPSec トンネル エンドポイントの適切なゲートウェイ アドレスが設定された Azure の「ローカル ネットワーク」の定義に一致している必要があります。「Remote」は Azure のアドレス空間の設定に一致している必要があります。 最後に、トンネル インターフェイスを経由して Azure 仮想ネットワークへトラフィックを転送するためのルートを作成します。 この時点で Azure 仮想ネットワークに ping するとトンネルがアップするはずですが、もしアップしない場合は System ログを確認しトラブルシューティングを行います (例えば、ping 応答は無いが、他の通信はできている、など)。   注: このドキュメントは次のディスカッションから作成されました: How to configure PAN to Azure VPN tunnel 著者:panagent
記事全体を表示
kishikawa ‎06-08-2016 04:37 AM
4,188件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 CLI Commands to Status, Clear, Restore, and Monitor an IPSEC VPN Tunnel https://live.paloaltonetworks.com/t5/Learning-Articles/CLI-Commands-to-Status-Clear-Restore-and-Monitor-an-IPSEC-VPN/ta-p/55917   概要 このドキュメントのCLI コマンドを使用することにより IPSEC tunnel のステータスの確認、 Tunnel のモニタリング、 Tunnel の切断と再接続ができます。   詳細 VPN Tunnelのモニタリングと接続状況の確認: show vpn flow Note: monitor status がdownの場合は 宛先IP Address への接続ができていないことを示します。   例: > show vpn flow   total tunnels configured:        1 filter - type IPSec, state any   total IPSec tunnel configured:   1 total IPSec tunnel shown:        1   id  name     state    monitor  local-ip        peer-ip        tunnel-i/f -------------------------------------------------- ------------------------ 4   tunnel   active    up      172.17.128.135  172.17.128.1     VPN Tunnel 内でデータ通信が行われてる事の確認 : show vpn flow tunnel-id x   << VPN Tunnel の ID 番号(上の例だと4)   例: データ通信が行われていればpackets と bytes のカウンターは上がります。 > show vpn flow tunnel-id 2         encap packets:    500         decap packets:    500         encap bytes:      54312         decap bytes:      54312         key acquire requests: 35     接続しているIKE phase 1 SAの詳細の表示: show vpn ike-sa gateway <gateway name>   例: > show vpn ike-sa gateway GW-to-Lab1   phase-1 SAs GwID  Peer-Address    Gateway Name    Role Mode Algorithm ----  -------------  ---------------  ---------------------------                1    57.1.1.1        gw-to-Lab1      Init Main PSK/DH2/A128/SHA1   Show IKEv1 IKE SA: Total 1 gateways found.     接続しているIKE phase 2 SAの詳細の表示: show vpn ipsec-sa tunnel <tunnel name>   Example: > show vpn ipsec-sa tunnel IPVPN-tunnel1.1-to-LAB1   GwID  TnID  Peer-Address  Tunnel(Gateway)          Algorithm      ----  ----- ------------  -----------------------  ------------ 1     2     57.1.1.1      IPVPN-tunnel1.1-to-LAB1  ESP/A128/SHA1   Show IPSec SA: Total 1 tunnels found.     これらのコマンドはVPN Tunnel を切断する時に使用します : > clear vpn ike-sa gateway GW-to-Lab1 Delete IKEv1 IKE SA: Total 1 gateways found.   > clear vpn ipsec-sa tunnel IPVPN-tunnel1.1-to-LAB1 Delete IKEv1 IPSec SA: Total 1 tunnels found.   これらのコマンドはVPN Tunnel を再接続する時に使用します : > test vpn ike-sa gateway GW-to-Lab1 Initiate IKE SA: Total 1 gateways found. 1 ike sa found.   > test vpn ipsec-sa tunnel IPVPN-tunnel1.1-to-LAB1 Initiate IPSec SA: Total 1 tunnels found. 1 ipsec sa found.   注意: GW-to-Lab1 と IPVPN-tunnel1.1-to-LAB1 はgateway と tunnel 名前の例です。   Phase 1 Phase 2  
記事全体を表示
oconnellm ‎04-19-2016 10:30 PM
7,558件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Troubleshoot VPN Connectivity Issues https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Troubleshoot-VPN-Connectivity-Issues/ta-p/59187   詳細 フェーズ1 ISPに関連する問題を除外するため、PAの外側のインターフェイスからピアのIPへpingし、ピアの外側のインターフェイス上でpingが有効になっていることを確認します。 セキュリティ要件によりpingがブロックされている場合は、もう一方のピアがMain/Aggresive モードのメッセージまたは DPD に応答しているかどうか確認します。それから、Monitorタブ配下のSystemログまたはikemgrログにてピアから "Are you there?" メッセージの応答があるかどうかを確認します。 IKE識別が正しく設定されていることを確認します。 IKEおよびIPSECアプリケーションを許可するポリシーが適切に配置されていることを確認します。通常、このポリシーは、PAに Clean-upルールが設定されていなければ不要です。もしClean-up ルールが設定されている場合は、このポリシーは通常、外側のzone から外側の zoneに対して設定されます。 プロポーザルが正しいことを確認します。もし正しくない場合、ミスマッチに関するログがSystemログで確認できます。もしくは、以下の CLIコマンドを使用して確認することができます。 >  less mp-log ikemgr.log 事前共有キーが正しいことを確認します。正しくない場合、ミスマッチに関するログがSystemログで確認できます。もしくは、以下の CLIコマンドを使用して確認することができます。 >  less mp-log ikemgr.log トラフィックを分析するためにパケットキャプチャを実施します。フィルタを使用してキャプチャされたトラフィックの範囲を絞ります。 役に立つCLIコマンド: > show vpn ike-sa gateway <name> > test vpn ike-sa gateway <name> > debug ike stat 高度なCLIコマンド: 詳細なログを確認するためには、ログ レベルを "debug" にします。 > debug ike global on debug > less mp-log ikemgr.log Main/AggresiveおよびQuick モードのネゴシエーションを参照するために、パケットキャプチャを有効にしてこれらのネゴシエーションをキャプチャすることが可能です。Main モードのメッセージ 5、6以降、およびQuick モードの全てのパケットはデータのペイロードが暗号化されています。 > debug ike pcap on > view-pcap no-dns-lookup yes no-port-lookup yes debug-pcap ikemgr.pcap debugを停止します。 > debug ike pcap off  パケット フィルタを設定してキャプチャすると、キャプチャ結果を調査対象のパケットのみに限定することができます。debug ike pcap on を実行すると、すべてのVPNトラフィックのキャプチャが参照できます。   NAT-Tが有効かどうかを確認するためには、Mainモードの第5、6メッセージから、パケットの送受信ポートが500から4500に変更されているかどうかを確認します。 ピアのベンダーIDが Palo Alto Networks デバイスでサポートされているかどうか、逆に、Palo Alto Networks デバイスのベンダーIDがピアのデバイスでサポートされているかどうかを確認します。   フェーズ2 ファイアウォールがトンネルをネゴシエートしていることを確認し、2つの一方向のSPIが存在することを確認します。 > show vpn ipsec-sa > show vpn ipsec-sa tunnel <tunnel.name> プロポーザルが正しいことを確認します。正しくない場合、ミスマッチに関するログが、Monitorタブ配下のSystemログで確認できます。もしくは以下のコマンドを使用して確認できます。 >  less mp-log ikemgr.log PFSが両方のエンドで有効になっていることを確認します。正しくない場合、ミスマッチに関するログが、Monitorタブ配下のSystemログで確認できます。もしくは以下のコマンドを使用して確認できます。 >  less mp-log ikemgr.log Proxy-IDの設定を確認します。この設定は通常トンネルが2つの Palo Alto Networks のファイアウォール間のトンネルの場合は必要ありませんが、ピアが別のベンダーの場合はIDの設定が必要です。正しくない場合、ミスマッチがSystemログで確認できます。もしくは以下のコマンドを使用して確認できます。 > less mp-log ikemgr.log 役に立つCLIコマンド: > show vpn flow name <tunnel.id/tunnel.name> > show vpn flow name <tunnel.id/tunnel.name> | match bytes カプセル化と非カプセル化のバイト数が増加しているかどうかを確認します。トラフィックがファイアウォールを通過していれば、カプセル化と非カプセル化の両方の値が増加しているはずです。 > show vpn flow name <tunnel.id/tunnel.name> | match bytes もしカプセル化のバイト数が増加していて非カプセル化のバイト数が一定の場合は、ファイアウォールはパケットを送信していますが受信していません。 ポリシーがトラフィックをドロップしていないか、もしくは、PANの手前のポート変換デバイスがESPパケットをドロップしていないかを確認します。 > show vpn flow name <tunnel.id/tunnel.name> | match bytes   もし非カプセル化のバイト数が増加していてカプセル化のバイト数が一定の場合、ファイアウォールはパケットを受信していますが送信していません。 ポリシーがトラフィックをドロップしているか確認します。 > test routing fib-lookup virtual-router default ip <destination IP> -------------------------------------------------- runtime route lookup -------------------------------------------------- virtual-router:  default destination:      10.5.1.1 result:          interface tunnel.1 >  show routing route > test vpn ipsec-sa tunnel <name> Advanced CLI commands: > debug ike global on debug > less mp-log ikemgr.log > debug ike pcap on > view-pcap no-dns-lookup yes no-port-lookup yes debug-pcap ikemgr.pcap > debug ike pcap off トンネルはアップしているがトラフィックがトンネルを通過していない場合、 セキュリティ ポリシーとルーティングを確認します。 ポートアドレス変換を行っているアップストリームのデバイスがあるか確認します。ESPは レイヤ3プロトコルなので、ESPパケットにはポート番号がありません。このようなデバイスが ESPパケットを受信すると、変換するポート番号が確認できないため、パケットをサイレントにドロップする可能性が高いです。 必要に応じて debug packet filters、debug packet captures、debug packet logs を適用し、トラフィックがどこでドロップされているかを切り分けます。
記事全体を表示
kishikawa ‎04-14-2016 10:20 PM
6,529件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure a Palo Alto Networks Firewall with Dual ISPs and Automatic VPN Failover https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-a-Palo-Alto-Networks-Firewall-with-Dual-ISPs/ta-p/59774     概要 本文書はVPNトンネルを用いて2つのISP接続をPalo Alto Networks ファイアーウォールに設定する際の、設定手順を解説します。   設定目標: 1つのデバイスが2つのインターネット接続を持つ(高可用性) 静的なサイト間VPN インターネット接続とVPNの自動フェイルオーバー   構成 この構成は本社、支社間の接続方法として一般的なものです。ISP1は Ethernet1/3でプライマリとして、ISP2はバックアップとしてEthernet1/4に接続します。   設定 2つのファイアウォールの設定は同一のため、ここでは1台についてのみ説明します。この例では2つのヴァーチャルルーター(VR)を設定します。 インターフェイス設定 2つのインターフェイスを設定: Eth 1/3: 10.185.140.138/24 (ISP1に接続) をuntrust zoneに配置 Eth 1/4: 10.80.40.38/24 (ISP2に接続)を the untrust zoneに配置   ヴァーチャルルーター 2つのヴァーチャルルーター を設定: VR1: プライマリ (ISP1) (Ethernet1/3) VR2: セカンダリ (ISP2) (Ethernet1/4)   各VRに1つのISP向けインターフェイスを追加しますが、他のすべてのインターフェイス(将来の追加分も含め)はセカンダリのVRに追加します。これはメインのISP障害時に、すべてのインターフェイスの存在をコネクティッドルートとVR上のルートによって、ルーティングを用いて明示するためです。 プライマリのVRにはEthernet1/3を追加 プライマリVRのルートはデフォルトルートと、すべてのプライベートアドレスの戻りルートとなり、これらはインターフェイスのConnectedルートがあるセカンダリVRに向かいます。トラフィックがPBFによってインターフェイスから出力される場合、それらのトラフィックはセカンダリVRの生存しているインターフェイスによって戻りのルートを知ることになります。 セカンダリVRには  下記の通りEthernet1/4 と他のすべてのインターフェイスを追加。 セカンダリVRに接続したインターフェイスのルートは、ルーティング上にコネクティッドルートとしてルーティングテーブルに現れます。そして、トンネル向けのルートはポリシーベースフォワーディング(PBF)にて扱われます。 プライマリISP向けインターフェイスからトラフィックを出力するために、PBFの送信元ルーティングにてTrustedゾーンを追加します。 ファイアウォールはPBFにてプライベートネットワーク向けにトラフィックを転送しません。これはプライベートアドレスはインターネット上ではルーティングされないためです。プライベートアドレスの転送が必要となるため、Negateをチェックします。 下記の例の通り、プライマリインターフェイスから出力するように設定し、またモニター機能にてルールを無効化を設定します。すべてのコネクティッドルートを持つセカンダリVRのルーティングテーブルを使って切り替えを行います。 送信元NATポリシーを両方のISP用に設定します。両方のNATルールにて"元のパケット"タブにある宛先インターフェイスを確実に設定してください。 複数のVRを設定するのは、両方のトンネルが同時にアップとなり稼働するためです。もしISP1へのVPNの接続性の問題が発生すれば、すみやかにISP2にフェイルオーバーします。もしISP2へのバックアップVPNがネゴシエーション済みであれば、フェイルオーバーの高速化につながります。   フェーズ1設定 それぞれのVPNトンネルのためIKEゲートウェイを設定します。   フェーズ2設定 それぞれのVPNトンネルにIPSecトンネルを設定します。トンネルが別の Palo Alto Networks ファイアウォールに接続する場合、 IPSecトンネルにてトンネルモニターによるフェイルオーバーを設定します。そうでない場合はPBFでモニターを有効化し、セカンダリのトンネルにルートする設定を行います。   トンネルモニタリング(Palo Alto Networks ファイアウォール同士の接続) トンネルモニター有りのプライマリトンネル。 トンネルモニター有りのセカンダリトンネル。 モニターのプロファイルにて、アクションでフェイルオーバーを選択。 この設定方法ではトンネルモニターに2つのルートがルーティングテーブルにあることを利用します。1つ目のルートはメトリック10のプライマリVPNトラフィック向け、2つ目はメトリック20のセカンダリVPN向けです。トンネルはセカンダリVRで終端されるので、これらのルートはセカンダリのVRに置かれます。   ポリシーベースフォワーディング (Palo Alto Networks ファイアウォールと他ベンダーのファイアウォールとの接続) この設定方法は2つのファイアウォール感での接続に使用されます。 送信元ゾーンを設定します。 対抗のネットワーク向けの宛先トラフィックを指定します。(この例では192.168.10.0/24)。 トラフィックをトンネルに転送します。 PBFが無効になると宛先は到達不能となるので、もう一つのVPNはルーティングテーブルを使用し始めます。そのルーティングテーブルには、同じ宛先ですが、別に設定したトンネルがエントリとして存在しています。   注: 上記の例では接続性を確認するため192.168.10.2にプローブをします。プローブは送信元IPアドレスがなければならず、出力インターフェイス、つまりトンネルインターフェイスのIPアドレスを使用します。もしIP アドレスがトンネルインターフェイスに設定されていないと、PBFルールは有効になりません。この設定例では、例えば172.16.0.1/30といった任意のIPが設定されている必要があります。192.168.10.2宛のスタティックルートはトンネルインターフェイスを選択の上、ネクストホップを指定しなければなりません。さもないとファイアウォールから開始されるトラフィックがPBF対象とならずに、PBFは常に失敗します。対抗のデバイスが復路のパケットを適切に送信できることを確認する必要があります。Cisco ASAを使用している場合、172.16.0.1/30宛の復路のトラフィックを適切に処理できることを確認しておいてください。さらに、Palo Alto NetworksファイアウォールでのIPSecトンネルのプロキシIDを設定しておく必要があります。     著者: rvanderveken
記事全体を表示
TShimizu ‎04-04-2016 09:37 PM
3,273件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 How to Configure IPSec VPN https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-IPSec-VPN/ta-p/56535     概要 本ドキュメントは、IPSec VPNの設定方法について記載しています。Palo Alto Networksファイアウォールにおいて、少なくとも二つのレイヤ3インターフェイスが設定されている事を想定しています。   手順 "Network" > "トンネル" > "トンネル インターフェイス" へ移動し、新規にトンネル インターフェイスを作成し、以下のパラメータを設定します。 インターフェイス名:tunnel.1 仮想ルーター:(既存の仮想ルーターを選択) ゾーン:(トラヒックの開始元となるレイヤー3の内部ゾーンを選択) 注:もしトンネル インターフェイスがトラヒックが入ってくる、もしくはトラヒックが出て行くゾーンと異なるゾーンにある場合、送信元ゾーンからトンネル インターフェイスを含むゾーンへのトラヒックを許可するポリシーを作成する必要があります。 "Network" > "ネットワーク プロファイル" > "IKE 暗号" > "IKE 暗号プロファイル" へ移動し、IKE 暗号 (IKEv1 フェーズ1) パラメータを定義します。 IKEフェーズ1ネゴシエーションが成功するために、これらのパラメータは対向側のファイアウォールの設定と一致している必要があります。 "Network" > "ネットワーク プロファイル" > "IKE ゲートウェイ" に移動し、IKE フェーズ1ゲートウェイを設定します。 注:上記で設定したトンネルはトンネルを通過するトラヒックをTrustゾーンで終端します。もしより細かい制御がそのトンネルのポリシー設定で必要な場合は、VPNを使用するか別のゾーンを使ってください。また、以下のゲートウェイの設定はUntrustインターフェイス用の設定であり、Trustインターフェイスで終端するトンネルとは異なることに注意してください。 "Network" > "ネットワーク プロファイル" > "IPSec 暗号" へ移動し、"IPSec 暗号プロファイル" を定義します。 "IPSec 暗号プロファイル" 内でプロトコル、認証方法等、IPSec SAネゴシエーション(IKEv1 フェーズ2)をベースにしたVPNトンネルで使用する暗号化方式などを設定します。IKEフェーズ2ネゴシエーションが成功するために、これらのパラメータは対向側のファイアウォールの設定と一致している必要があります。 "Network" > "IPSec トンネル" > "全般" へ移動し、ファイアウォール間でIPSec VPNトンネルを確立するためのパラメータを設定します。 注: もし対向側のトンネルがポリシー ベースVPNとして設定されているサードパーティ製のVPNデバイスの場合、ローカルproxy IDとリモートproxy IDを対向側と一致するように設定します。 NATされているトラヒックのローカルとリモートのIPネットワークを特定するためにIPSecトンネルProxy-IDを設定する際、そのIPSecトンネルのためのProxy-IDはNATされた後のIPネットワーク情報を元に設定されなければなりません。なぜならばProxy-ID情報は両端のIPSec設定おいて、トンネル経由で許可されるネットワークを定義するからです。  "Network" > "仮想ルーター" > "スタティック ルート" へ移動し、対向のVPNエンドポイントの後ろにあるネットワーク用に新しいルートを追加します。 設定をコミットします。   注:Palo Alto NetworksではIPSec VPNのトンネルモードのみをサポートします。IPSec VPNのトランスポート モードはサポートしません。   See Also VPNに関するより複雑な設定については、以下のドキュメントを参照してください。 How to Configure a Palo Alto Networks Firewall with Dual ISPs and Automatic VPN Failover Selecting an IP Address to use for PBF or Tunnel Monitoring Dead Peer Detection and Tunnel Monitoring  
記事全体を表示
ymiyashita ‎04-03-2016 10:23 PM
13,515件の閲覧回数
0 Replies
※この記事は以下の記事の日本語訳です。 IPSec VPN Error: IKE Phase-2 Negotiation is Failed as Initiator, Quick Mode https://live.paloaltonetworks.com/t5/Management-Articles/IPSec-VPN-Error-IKE-Phase-2-Negotiation-is-Failed-as-Initiator/ta-p/60725   問題 Palo Alto Networks ファイアーウォール と他ベンダーの機器間で拠点間 IPsec VPN (site-to-site IPsec VPN) を設定した際、IKEフェーズ1 は成功しますが、IKEフェーズ2 のネゴシエーションに失敗します。 ikemgr.logの内容を以下のコマンドで確認します。 > tail follow yes mp-log ikemgr.log   以下のエラーが確認されます: ( description contains 'IKE protocol notification message received: INVALID-ID-INFORMATION (18).' ) および IKE phase-2 negotiation is failed as initiator, quick mode. Failed SA: 192.168.1.150[500]-192.168.5.108[500] message id:0x43D098BB. Due to negotiation timeout   解決策 最も良くあるIKEフェーズ2失敗の原因は、Proxy ID の不一致によるものです。 Palo Alto Networksファイアーウォールと他ベンダーの機器上でProxy ID の設定を確認します。 Note: 他ベンダーの機器上では、Proxy ID は アクセスコントロールリスト(アクセスリスト、ACL)と呼ばれる場合があります。 IPsec でネゴシエーションされる暗号化方式についても、両サイドで確認します。
記事全体を表示
dyamada ‎04-01-2016 07:39 AM
3,915件の閲覧回数
0 Replies
Ask Questions Get Answers Join the Live Community