ナレッジドキュメント

※この記事は以下の記事の日本語訳です。 GLOBALPROTECT: ONE-TIME PASSWORD-BASED TWO FACTOR AUTHENTICATION https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm8ICAS     原文はSivasekharan   Rajasekaranによるものです。 @ srajasekar   背景   企業では社内リソースへのアクセスの許可のために、ワンタイム パスワード（OTP）のような、より強力な認証手段が求められています。OTPベースの認証を要求することで、企業は攻撃者が不正にユーザーの資格情報を入手したり、承認されないアクセスをすることを防ぐことができます。しかしOTPを要求するどの実装も、エンドユーザーがOTPを使いづらく感じ、敬遠する恐れがあります。   目的   GlobalProtectはOTPベース認証をサポートし、ユーザー体験を維持する手段を提供します。この文書の目的は、企業の管理者に異なるGlobalProtectのOTP認証のワーク フローと、彼らのセキュリティとコンプライアンスの要求に合致しつつ、ユーザー体験を簡潔に維持するGlobalProtectの認証シナリオを決定する一助となることです。     GlobalProtectのOTP認証   GlobalProtectはRADIUSまたはSAML経由のOTPベースの認証をサポートし、OTPベンダーに全く依存しません。 RADIUSかSAMLをOTPベンダーが対応している限り、どのOTPベンダーも使用できます。OTPサービスをどのように設定したか次第で、ユーザーは2つのワーク フローのいずれかに従って認証されます。 ユーザーはユーザー名とパスワードを最初に入力し、その後にOTPによりChallengeが行われます。OTPは承認のプッシュ、SMS、トークン コードのいずれかを使用します。 ユーザーはユーザー名を入力し、Challengeを待つことなくワンタイム パスワード（あるいは同時にパスワード）を即認証します。 GlobalProtectはこれらのワークフローをサポートします。  Duoによる2つのワークフローを行うRADIUS設定のサンプルはこちらです。   Always-OnモードでのOTPベース認証が必要な場合 - こちらを参照   On-DemandモードでのOTPベース認証が必要な場合   GlobalProtectをOn-Demandモードで展開している場合、ユーザーは手動で必要に応じてGlobalProgtectに接続します。このモードは一般的な安全なリモート アクセスのユース ケースで、リモートのユーザーは社内データ センターのリソースにアクセスするためにVPNトンネルをセットアップし、内部のデータ センターへのアクセスが必要なくなったときにはVPNを切断します。   ユース ケース1： RADIUSを使用したOn-DemandモードでOTPを使用する   On-Demandによる接続では、GlobalProtectエージェントは、ユーザーがGlobalProtectへの接続を開始する毎に、常に最初にポータル、続いてゲートウェイを認証します。OTP認証がポータルとゲートウェイ両方に必要ということは、ユーザーが二回OTP認証を促されることを意味します（一回はポータル、続く一回はゲートウェイ）。しかし（PAN-OS 7.1およびGlobalProtect 3.1以降から）、ユーザーの認証の回数を最小化する認証オーバーライド機能を提供しています。認証オーバーライドの詳細は、Enhanced Two-Factor Authenticationをご覧ください。   推奨の設定： ポータルとゲートウェイ両方にOTP認証を必要とする。 ポータルにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 Cookie有効期間を'N'時間に設定。'N'時間はユーザーが認証情報を再度入力を促されるまでの時間です。提供したいユーザー体験に基づいて決めてください。 ゲートウェイにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 クッキーの暗号化/復号には、ポータルとゲートウェイで同じ証明書を使用するようにしてください。 注： 認証オーバーライドに使用する証明書を更新する必要ができたときに柔軟に対応するため、認証クッキーの暗号化と復号化に使用する証明書は専用のものとしてください。 Configuration on the Portal   Configuration on the Gateway   この設定にて、エンドユーザーがGlobalProtectに手動で接続するとき、エンドユーザーの体験は次のようになります。   ワーク フロー – 1 ワーク フロー – 2       ユース ケース2： SAMLを使用したOn-DemandモードでOTPを使用する   GlobalProtectは、PAN-OS 8.0とGlobalProtect 4.0からSAML認証をサポートします。SAMLを使用するとGlobalProtectエージェントはSAMP IdPからの認証ページを、Web/組み込みブラウザーで表示し、ユーザーを認証します。ブラウザが異なる（組み込みブラウザー）ため、 GlobalProtectの認証により得られたSAMLクッキーは、他のSAML有効化アプリケーションによるSSOには使用できません。逆もまた同様です。 GlobalProtect の認証により得られたSAMLクッキーは、再起動やログアウト後には残りません。 SAMLによるOTPを使用した場合、透過的な認証を行うために推奨される設定は次のようになります。 ポータルとゲートウェイの両方にSAML認証を使用します。 IdP設定により、SAMLクッキーの有効な期間を決定します。SAMLクッキーが継続し有効である限り、ユーザーからみてGlobalProtectへの透過的な認証になります。 Oktaを使用したGlobalProtectのSAML認証の設定方法はこちらをご覧ください。   GlobalProtect認証オーバーライドを用いて、再起動やログアウト後も透過的な認証を提供する   ポータルにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 Cookie有効期間を'N'時間に設定。'N'時間はユーザーが認証情報を再度入力を促されるまでの時間です。提供したいユーザー体験に基づいて決めてください。 ゲートウェイにて、 ユーザー認証情報の保存を “Save Username Only” 認証オーバーライドの有効化と、"クッキーを生成して認証上書き"、"クッキーを受け入れて認証上書き"の両方の有効化。 クッキーの暗号化/復号には、ポータルとゲートウェイで同じ証明書を使用するようにしてください。 注： 認証オーバーライドに使用する証明書を更新する必要ができたときに柔軟に対応するため、認証クッキーの暗号化と復号化に使用する証明書は専用のものとしてください。   GlobalProtect Always-OnモードでのOTP認証の推奨については、このシリーズのこちらの次記事を参照してください。   設定例   2つのワーク フロー実現のためのDuoによるサンプル設定です。 DuoによるOTP認証を提供する方法の詳細については、こちらをご覧ください。   ワーク フロー1： ユーザーはユーザー名とパスワードを最初に入力し、その後にOTPによりChallengeが行われます。OTPは承認のプッシュ、SMS、トークンコードのいずれかを使用します。   [ad_client] host=<AD-Server> service_account_username=<administrator> service_account_password=<administrator’s password> search_dn=DC=acme,DC=com   [duo_only_client] [radius_server_challenge] ikey=<duo-integration-key> skey=<duo-security-key> api_host=<duo-host-name> radius_ip_1=<firewall-mgmt-ip> radius_secret_1=<radius-secret> client=ad_client failmode=safe port=1812

※この記事は以下の記事の日本語訳です。 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設定 ドキュメント  

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 GlobalProtect failed to connect - required client certificate is not found https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-failed-to-connect-required-client-certificate-is/ta-p/70192 問題 2要素認証を使用するように認証プロファイルと証明書プロファイルをGlobalProtect ポータルとゲートウェイで構成しましたが、クライアント コンピューターでGlobalProtectに接続しようとした際に、GlobalProtect クライアントのステータス ページに以下のエラーメッセージが表示されます: "Required Client Certificate is not found"   また、PanGP サービス ログでは以下のエラー メッセージが表示されます: Debug(3624): Failed to pre-login to the portal XX.XX.XX.XX. Error 0 Debug(1594): close WinHttp close handle. Debug(3588): prelogin status is Error Error(3591): pre-login error message: Valid client certificate is required Debug(1594): close WinHttp close handle. Debug(4213): portal status is Client Cert Required. Debug(3697): Portal required client certificate is not found.   解決方法 これらのエラーはクライアント コンピュータに正しい/有効な証明書がないため発生します。 クライアント マシンにインポートされた証明書はGlobalProtect ポータル及びゲートウェイで設定されたサーバ証明書と一致する必要があります。 自己署名証明書の場合は、"個人"及び"信頼されたルート証明機関"の両方にインポートする必要があります。 クライアント コンピュータに証明書をインポートする方法については、ここをクリックして"step 2"を参照してください。   次の手順に従い、P12形式の証明書をクライアント コンピュータ(Windows マシン)にインポートします:   スタートをクリックし、mmcを実行します。 ファイル > スナップインの追加と削除をクリックします。 スナップインから"証明書"を選択し、追加をクリック、コンピューター アカウントを選択し完了をクリックします。 OKをクリックしスナップインの追加と削除を閉じます。 "個人"と"信頼された証明機関"に証明書をインポートします。

※この記事は以下の記事の日本語訳です。 Configure Palo Alto GlobalProtect with Azure Multi-Factor Authentication https://live.paloaltonetworks.com/t5/Management-Articles/Configure-Palo-Alto-GlobalProtect-with-Azure-Multi-Factor/ta-p/79117   AzureのRADIUS認証で多要素認証 (MFA) を使ったGlobalProtectの設定方法について記述します。設定の注意点として、AzureはPAP と MSCHAPv2 認証のみのサポートなので、Palo Alto Networks GlobalProtectでは、PAP認証方式のみ設定が可能です。   Azure MFA設定は、オンプレミスのMFA Server RADIUS（Microsoft推奨）を使用します。 注意: MFA Serverが既にインストールされており、ADとユーザー情報がSync済みであることを前提としています。   Radius認証を有効にします。 クライアント タブでは、Azure Multi-Factor Authentication RADIUS serviceがRADIUS リクエストを受け付けるポートをスタンダードポート以外にする必要がある場合、認証、アカウンティングポートを変更します。これはPalo Alto Networks上の設定も同様です。 クライアント欄で、Addをクリック Palo Alto Networks ファイアウォールのManagement IPをAzure Multi-Factor Authentication Serverに認証するIPアドレスとして設定します。 名前を入力します（任意設定） 共有暗号鍵 (shared secret) を入力します。 'Require Multi-Factor Authentication user match' チェックボックスをクリック。 もしユーザがAzure Multi-Factor Authenticationモバイルアプリ認証を使用していて、OATHのパスコードを、外線通話、SMS、プッシュ通知の際に利用したい場合は、‘Enable fallback OATH token’ チェックボックスをクリックします。      8. Targetタブで、機器がドメインに参加している場合は‘Windows domain’を選択、そうでない場合は’LDAP bind’を選択します。       GlobalProtect設定 注意: Azure MFA SeverはPAPとMSCHAPv2のみのサポートです。GlobalProtectの設定で、PAP認証を設定する必要があります。デフォルト設定はAutoです。もし違う認証が選択された場合、authd.logに不正ユーザ名/パスワードのエラーメッセージのみが記録されます。 RADIUS CHAP認証モードをPAN-OS 7.0.3、それ以前で、CLI、WebUIから手動設定で外すオプションはありません。 PAN-OS 7.0.4以降では、以下のコマンドで、手動設定でRADIUS認証タイプを選択できます。 > set authentication radius-auth-type <auto|chap| pap >   Palo Alto Networks ファイアウォールにログインします。 Device> サーバー プロファイル > RADIUSに移動し、以下のプロファイルを作成します。 a. プロファイル名 (Profile Name) -  MFA serverの名前 b. 場所 (Location) - 共有 (Shared) c. タイムアウト (Timeout) – 30～60秒で、multi-factor認証、Radiusアクセス・リクエスト処理の送受信など、ユーザ認証に必要な時間（以下のスクリーンショットを参照） d. 再試行 (Retries) – 3回 e. 追加 (Add) をクリックし、RADIUS ServerにWindows Azure Multi-Factor Authentication serverのFQDNもしくはIP アドレスと、以前に設定したshared secretを入力 f. ポート (Port) - 1812 (デフォルト). Network > ゲートウェイ（ゲートウェイは設定済みであることが前提） 全般 > 認証プロファイルでステップ2で作成したプロファイルを選択           著者: smisra  

 ※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 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にマッチしなければなりません。 サブジェクト代替名が１つ以上存在する場合、そのポータル/ゲートウェイで使用される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. 手順１と２のルート認証局証明書と中間認証局証明書を追加します。   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. ルート認証局までの完全な証明書チェーンがあるか。もしルート認証局や中間認証局までのチェーンに欠落がある場合は、手順５での説明に従い、それらの認証局証明書を該当するフォルダーにインポートします。           7.この時点で証明書はクライアントにインストールされていますので、mmcコンソールをセーブすることなくクローズして構いません。

※この記事は以下の記事の日本語訳です。 SSL Certificate for IOS Devices https://live.paloaltonetworks.com/t5/Management-Articles/SSL-Certificate-for-IOS-Devices/ta-p/67061   症状 IOS デバイスはインストールされたSSL証明書を検証できる場合にのみ使用可能になります。クライアント証明書を用いてGlobal Protectに接続する場合、デバイスには検証済みのクライアント証明書が必要となり、検証が完了していない証明書の場合は接続できません。またSSL復号化を行っている場合、httpsサイトへのアクセス時にIOS デバイス上で証明書エラーが表示されます。 MAC, WindowsPC, Android デバイスでは同じ証明書が動作しますが、IOS デバイスでは正常に動作しない場合があります。   発行済みの自己署名証明書、内部/外部CAを証明書として使用することができます。CAに関係なく、完全な証明書チェーンがIOS デバイスで利用可能になるようにする必要があります。        診断 まず初めにIOS デバイスで検証されている証明書プロファイルを確認し、完全な証明書チェーンが存在するかをチェックします。証明書が検証され、完全な証明書チェーンが存在すれば緑色のチェックマークが表示されます。   1. 設定 > 一般 > プロファイルへ移動します。 2. インストール済みの証明書を選択すると未検証のエラーメッセージが表示されます。以下のイメージを参照してください。   3. インストールされた証明書が完全なチェーンを持っていることを確認してください。デバイスに中間証明書とルート証明書をemailで送信する簡単な方法もあります。これらの証明書は秘密鍵は不要で公開鍵でインストール可能です。中間証明書が無い場合は中間CA証明書は不要で、ルート証明書と実際のサーバ証明書が必要です。   4. 完全な証明書チェーンがインストールされれば、IOS デバイスはインストールされた証明書を検証することができ、Global Protectの接続を確立できます。   IOS 10.3以降のデバイスをお使いの場合、新しくインストールした証明書を信頼する為に追加の手順が必要となりますので以下のサイトをご参照ください。 https://support.apple.com/en-us/HT204477 https://support.apple.com/ja-jp/HT204477   SSL通信に対して証明書の信頼を有効にするには、設定 > 一般 > 情報 > 証明書信頼設定 の順に選択します。"ルート証明書を全面的に信頼する" で証明書に対する信頼を有効にします。   解決方法 上記により完全な証明書チェーンが信頼されていれば、GlobalProtectが正常に接続できるはずです。GlobalProtectのクライアント証明書をデバイスにインストールする場合は、emailで送信した証明書が秘密鍵を含むPKCS形式であることを確認してください。SSL復号化用のサーバ証明書をインストールする場合、秘密鍵は必要ありません。  

※この記事は以下の記事の日本語訳です。 GlobalProtect Error During Installation: "An instance of GlobalProtect is already present on the system." https://live.paloaltonetworks.com/t5/Configuration-Articles/GlobalProtect-Error-During-Installation-quot-An-instance-of/ta-p/51937   問題 GlobalProtectクライアントをアンインストールし、新しいクライアントをインストールしようとすると、次のメッセージが表示される: "An instance of GlobalProtect is already present on the system. Uninstall the current version before attempting to install the new version of GlobalProtect"   解決方法 以下のレジストリ パス内のレジストリ項目を削除します（Windows OS）: HKEY_LOCAL_MACHINE\Software\Palo Alto Networks\ GlobalProtect \PanGPS Windowsのコマンドラインから管理者として以下のコマンドを実行する: sc delete PanGPS 該当のコンピューターを再起動します。   これでGlobalProtectクライアントは該当のコンピュータより完全に削除され、新しいクライアントは問題なくインストールできるようになります。   著者: shasnain

※この記事は以下の記事の日本語訳です。 How Can IP Overlaps be Prevented with GlobalProtect https://live.paloaltonetworks.com/t5/Configuration-Articles/How-Can-IP-Overlaps-be-Prevented-with-GlobalProtect/ta-p/54406     問題 リモートのユーザーが社内ネットワークにGlobalProtectで接続する際、コンピューターにはゲートウェイに設定されたプールからIPアドレスが割り当てられます。このIPアドレスが該当するワークステーションが既にいるサブネットと重複している場合、問題が発生しえます。   例：リモートの従業員がホテルの部屋から、10.0.0.0/8のレンジでローカルに割り当てられたIPアドレスを用いて接続しています。GlobalProtectクライアントが利用できるIPプールは10.1.1.0/24です。これはIPプールがローカルのサブネットに包含されるため、問題が発生するでしょう。 この場合、 "Assign Private IP address failed"のエラーがファイアウォールのシステムログに生成されます。   解決方法 推奨される解決方法は異なるサブネットの新しいIPプールを作成し、新しいプールをリストの下に配置することです。IP プールは上から使用されますが、もしクライアントのサブネットが最初のIP プールと衝突する場合は、ファイアウォールは自動的に2つ目のプールからIPアドレスをアサインします。   著者: tpiens

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 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  

※この記事は以下の記事の日本語訳です。 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  

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 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接続先の正当性の確認が必要となるため、推奨されません。  

※この記事は以下の記事の日本語訳です。 Split Tunneling for VPNC Client on Linux Distributions https://live.paloaltonetworks.com/t5/Configuration-Articles/Split-Tunneling-for-VPNC-Client-on-Linux-Distributions/ta-p/57244     概要 VPNCはオープンソースのサードパーティ IPsec VPNクライアントで拡張認証 (X-Auth) をサポートしており、組織内部ののネットワークへのアクセス用としてGlobalProtectゲートウェイへのVPNトンネルを確立します。PAN-OS 5.0.xから、以下のVPNクライアントがGlobalProtectのVPNアクセスのサポート対象となっています（訳注）。 Ubuntu Linux 10.04 LTS VPNC CentOS 6 VPNC この文書は、VPNCクライアントがGlobalProtectゲートウェイに接続される際、どのようにスプリット トンネリングが動作するのかを説明します。   詳細 VPNCクライアントから接続することができるネットワークを定義するために、あるいはVPN接続上で送られるトラフィックのため、(スプリット トンネリングとしても知られている) アクセス ルートを、GlobalProtectゲートウェイのクライアントの設定(訳注1：PAN-OS 7.1以降では[エージェント] > [クライアントの設定])に追加する必要があります。参照： GlobalProtect Configuration Tech Note アクセス ルートがGlobalProtectゲートウェイに設定されている時、すべてのアクセス ルートの内の1つの集約ルートが、VPNCクライアントに送られます。DNSサーバーのアドレスが含まれている場合、ルートを集約する際にはそれも考慮に入れなければなりません。   例： アクセス ルートが 10.66.22.0/23 と 192.168.87.0/24 のネットワークを含む場合、サードパーティのVPNCクライアントに送られる集約ルートは、デフォルト ルート 0.0.0.0/0 で、以下のように表示されます。 > show global-protect-gateway gateway name test_vpnc   GlobalProtect Gateway: test_vpnc (0 users) Tunnel Type          : remote user tunnel Tunnel Name          : test_vpnc-N         Tunnel ID                 : 7         Tunnel Interface          : tunnel.1         Encap Interface           : ethernet1/3         Inheritance From          :         Local Address             : 10.66.24.87         SSL Server Port           : 443         IPSec Encap               : yes         Tunnel Negotiation        : ssl,ike         HTTP Redirect             : no         UDP Port                  : 4501         Max Users                 : 0         IP Pool Ranges            : 172.16.7.1 - 172.16.7.7;         IP Pool index             : 0         Next IP                   : 0.0.0.0         DNS Servers               : 4.2.2.2                                   : 0.0.0.0         WINS Servers              : 0.0.0.0                                   : 0.0.0.0         Access Routes             : 10.66.22.0/23; 192.168.87.0/24;         Access Route For Third Party Client: 0.0.0.0/0         VSYS                      : vsys1 (id 1)         SSL Server Cert           : SERVER_CERT         Auth Profile              : vpnc_auth         Client Cert Profile       :         Lifetime                  : 2592000 seconds         Idle Timeout              : 10800 seconds   アクセス ルートが 10.66.22.0/23 と 10.66.12.0/23 のネットワークを含む場合、サードパーティのVPNCクライアントに送られる集約ルートは 10.66.0.0/19 で、以下のように表示されます。 > show global-protect-gateway gateway name test_vpnc   GlobalProtect Gateway: test_vpnc (0 users) Tunnel Type          : remote user tunnel Tunnel Name          : test_vpnc-N         Tunnel ID                 : 7         Tunnel Interface          : tunnel.1         Encap Interface           : ethernet1/3         Inheritance From          :         Local Address             : 10.66.24.87         SSL Server Port           : 443         IPSec Encap               : yes         Tunnel Negotiation        : ssl,ike         HTTP Redirect             : no         UDP Port                  : 4501         Max Users                 : 0         IP Pool Ranges            : 172.16.7.1 - 172.16.7.7;         IP Pool index             : 0         Next IP                   : 0.0.0.0         DNS Servers               : 10.66.22.77                                   : 0.0.0.0         WINS Servers              : 0.0.0.0                                   : 0.0.0.0         Access Routes             : 10.66.22.0/23; 10.66.12.0/23;         Access Route For Third Party Client: 10.66.0.0/19         VSYS                      : vsys1 (id 1)         SSL Server Cert           : SERVER_CERT         Auth Profile              : vpnc_auth         Client Cert Profile       :         Lifetime                  : 2592000 seconds         Idle Timeout              : 10800 seconds   注：VPNCクライアントに送られる集約ルートが、デフォルト ルート (0.0.0.0/0) である場合、VPNCクライアントは以下に表示されているように、スプリット トンネリングの設定をする必要があります。   VPNCクライアントを開き、[ IPv4設定] > [ ルート ] ボタンをクリックします。   必要なアクセス ルートを追加し、「そのネットワーク上のリソースのためにのみこの接続を使用」のチェックボックスにチェックが入っていることを確認します。 GlobalProtectによって送られた集約ルートは 0.0.0.0/0 ですが、接続は以下に表示されているように、10.66.22.0/23 ネットワークに対してのみ許可されます。 Linux ホストのターミナルからの出力結果： t un0   Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00        inet addr:172.16.7.1 P-t-P:172.16.7.1 ask:255.255.255.255        UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1412 Metric:1        RX packets:0 errors:0 dropped:0 overruns:0 frame:0        TX packets:0 errors:0 dropped:0 overruns:0 carrier:0        collisions:0 txqueue1en:500        RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) VPNCクライアントに送られた集約ルートは 0.0.0.0/0 でしたが、192.168.87.0/24 のためのアクセス ルートは追加されませんでした。 tobby@VirtualBox:~$ ping 192.168.87.1 PING 192.168.87.1 (192.168.87.1) 56(84) bytes of data.   --- 192.168.87.1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2014ms   VPNCクライアントで、10.66.22.0/23 のために追加されたアクセス ルート tobby@VirtualBox:~$ ping 10.66.22.87 PING 16.66.22.87 (16.66.22.87) 56(84) bytes of data. 64 bytes from 10.66.22.87: icmp_req=1 ttl=61 time=6.87 ms 64 bytes from 10.66.22.87: icmp_req=2 ttl=61 time=2.02 ms   --- 16.66.22.87 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 2.021/4.450/6.879/2.429 ms   訳注：原文執筆時点の情報です。最新版の GlobalProtect(TM) Administrator's Guideご参照の上、都度現在のサポートバージョンをご確認ください。   著者：gchandrasekaran

※この記事は以下の記事の日本語訳です。 GlobalProtect Client Unable to Connect on Newly Installed Machine https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-Client-Unable-to-Connect-on-Newly-Installed/ta-p/60421     問題 新規インストールしたGlobalProtectクライアントが接続できない。   トラブルシューティング クライアント端末上でログを有効にするために、[ トラブルシューティング ] > [ ログ ] を選択し、"PanGP サービス"を選択してから"開始"ボタンをクリックします。   以下のようなログを見ることができるようになります： (T788) 10/14/14 09:14:09:488 Info ( 341): InitConnection ... (T788) 10/14/14 09:14:09:488 Info ( 349): Connecting to Pan MS Service end (T788) 10/14/14 09:14:14:474 Info ( 341): InitConnection ... (T788) 10/14/14 09:14:14:474 Info ( 349): Connecting to Pan MS Service end (T788) 10/14/14 09:14:19:481 Info ( 341): InitConnection ... (T788) 10/14/14 09:14:19:481 Info ( 349): Connecting to Pan MS Service end (T788) 10/14/14 09:14:24:003 Debug(  71): CTranslate: xxxxxxxxxxxx is 24 (T788) 10/14/14 09:14:24:003 Debug(  73): CTranslate: sid is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (T788) 10/14/14 09:14:24:003 Debug(  71): CTranslate: xxxxxxxxx is 24 (T788) 10/14/14 09:14:24:003 Debug(  73): CTranslate: sid is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (T788) 10/14/14 09:14:24:008 Debug( 297): CPanGASetting:OnBnClickedSave - resend credentials (T788) 10/14/14 09:14:24:488 Info ( 341): InitConnection ... (T788) 10/14/14 09:14:24:488 Info ( 349): Connecting to Pan MS Service end (T788) 10/14/14 09:14:29:474 Info ( 341): InitConnection ...   この問題を解決する方法が2つあります： 解決方法 1 PanGPSサービスの状態が実行中であることを、タスク マネジャーのサービス タブで確認します。   解決方法 2 PanGPSサービスが、タスク マネジャーのサービス タブ内に存在しない場合、GlobalProtectクライアントを再インストールします。     著者：mbutt

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 How to Configure GlobalProtect SSO with Pre-Logon Access using Self-Signed Certificates https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-GlobalProtect-SSO-with-Pre-Logon-Access-using/ta-p/56297     概要 本文書には、自己署名証明書を使用した"Pre-Logon"方法で、GlobalProtect SSOを設定する方法が記載されています。   手順 下記の設定例は、同じPalo Alto Networksデバイス上に、1つのポータルと1つのゲートウェイがある場合のものですが、複数のゲートウェイ設定に拡張することができます。ローカル データベース認証は今回の例のために使用されていますが、他の認証方法 (LDAP、Kerberos、Radiusなど) も適用することができます。 ルート認証機関 (CA) 証明書をPalo Alto Networksデバイス上で生成します。これは、GlobalProtectポータルとゲートウェイ用のサーバー証明書に署名するために使われます。クライアント コンピューターに導入される、コンピュータ証明書も同様です。 サーバー証明書とコンピューター証明書を生成します。各証明書は、手順1で作成したCA証明書によって署名される必要があります。 GlobalProtectに関連付けられたデバイスの証明書は、以下のように表示されます： 証明書プロファイルを作成します。これは、CA証明書と相互に確認する際に、コンピューター証明書が有効かどうかを確認するために使われます。 CA証明書を追加する際は、CA証明書をリストから選択してください。 GobalProtect ポータルを以下のように作成します： "ポータル設定"にて、"ネットワーク設定"と"認証"を設定します。"サーバー証明書"には、上記の手順3で作成したサーバー証明書を選択します。"証明書プロファイル"には、手順4で作成したプロファイルを選択します。 "クライアント設定"にて、設定ファイルを作成します。これは、クライアントが最初に接続にしにいく際や、ネットワークの再検出をする際に、GlobalProtectのクライアントに展開されます。 "接続方式"で"pre-logon"を選択し、クライアント用に"pre-logon"設定ファイルを作成します。"pre-logon"ユーザーを含むすべてのユーザーが同じ設定ファイルを取得できるように、"any"ユーザーの設定ファイルも作成します。"信頼されたルート CA"にて、手順1で作成したルートCAを追加します。この証明書は、接続しているエージェントに展開されます。 GlobalProtect ゲートウェイの設定例は以下のとおりです。GlobalProtect ポータルの設定で使われているものと同じ"サーバー証明書"と"証明書プロファイル"が使用されていることを確認します。 下記図はGlobalProtect ゲートウェイの設定を表しており、tunnel.1 (L3-Trust ゾーン)にてユーザーを終端し、内部の信頼されたネットワーク (192.168.144.0/24) に対してだけ有効なアクセス ルートを持つ192.168.200.0/24 のスコープを使用する、という設定を表しています。 次の手順は、ローカル コンピューター上の信頼された証明書に追加されることになる、コンピューター証明書をエクスポートすることです。"ファイル フォーマット"として"PKCS12"を使用し、パスフレーズを入力します。 クライアント コンピューター上で、上記でエクスポートしたコンピューター証明書をインポートします。下記図は、ローカル コンピューター上でのMMC証明書のスナップ インの使用方法を表しています。 これにより、"Certificate Import Wizard"が起動します。以下の手順に従って、インポートを完了させます。今回の例における証明書の場合は、"PKCS12"というフォーマットでエクスポートされていました。正しい証明書が見つけられていることを確認します。 ローカル コンピューターの個人証明書ストアに、その証明書がインストールされていることを確認します。 Syslogは、ユーザー資格情報を使ってエージェントが接続に成功している最初の接続を示しています。その後、コンピューターからログオフします。その後もコンピューターが続けて、"pre-logon"ユーザーとしてCA証明書によって有効だとされたコンピューター証明書を使って、GlobalProtectポータルとゲートウェイに問題なく接続できることを確認します。     著者：rkalugdan

※この記事は以下の記事の日本語訳です。 SSL 3.0 MITM Attack (CVE-2014-3566) (PAN-SA-2014-0005) aka Poodle https://live.paloaltonetworks.com/t5/Threat-Articles/SSL-3-0-MITM-Attack-CVE-2014-3566-PAN-SA-2014-0005-aka-Poodle/ta-p/61856     詳細 本脆弱性の詳細につきましては、以下のセキュリティ アドバイザリを参照してください。 Palo Alto Networks Product Vulnerability - Security Advisories  (英文)   本文書ではセキュリティ アドバイザリに補足する形で詳細を記載します。Palo Alto Networks は本脆弱性に対応するために、製品毎に別の変更を施しています。本文書で記載しているように、この攻撃はそれぞれの機能毎にその影響範囲が限られています。 注: GlobalProtect ポータル、GlobalProtect ゲートウェイ、キャプティブ ポータルにおいて、Palo Alto Networks はSSLv3を無効化するように取り組みをしています。このプロセスは2つ以上のメンテナンス リリースを経るかもしれません。追加情報があれば、都度本文書を更新してまいります。   管理ウェブ GUI サーバー Palo Alto Networks は、デバイスの管理サービスを専用のVLANに制限するか、もしくは信頼できるネットワークとしてセグメントを分け、可能な限り信頼されないホストに晒されないようにすることを推奨します。仮にそれができない場合は、ウェブGUIはSSLv3リクエストに応答することになります。 注: PAN-OS 5.0.16、6.0.8、6.1.2以降のバージョンにおいて、デバイスの管理用コネクションにSSLv3は使用しないようになっています。   GlobalProtect ポータル GlobalProtect ポータル ページはブラウザでアクセスした場合、CVE-2014-3566の影響を受ける場合があります。攻撃が成功した際に取得される情報は認証クッキーのみです（ユーザ名、パスワードは窃取されません）。 ポータル ページにおける認証クッキーはGlobalProtectクライアントをダウンロードするためだけに使用され、GlobalProtectのログインやVPN接続には使用されません。   GlobalProtect ゲートウェイ GlobalProtect ゲートウェイは実際にSSLv3リクエストに対して応答をします。ただし、CVE-2014-3566が成功するためには、攻撃者が用意したJavascriptやウェブ ソケット コードと共にブラウザがハイジャックされ、かつクッキーを含んだリクエストが被害者のサーバーに向けて発行され１バイトずつ復号化される必要があります。GlobalProtect エージェントはブラウザではないので、このような攻撃に対して影響を受けません。   キャプティブ ポータル キャプティブ ポータルはSSLv3リクエストに対して応答をしますが、キャプティブ ポータルは内部的にユーザを認証するものであり、設定が正しく成されていれば外部からアクセスはされません。ただし、内部に感染したクライアントが存在すれば、それが攻撃の起点になる可能性があります。   Panorama Palo Alto NetworksファイアウォールとPanorama間でのコネクションではSSLv3をサポートしないため、本脆弱性の影響を受けません。   著者: gwesson

※この記事は以下の記事の日本語訳です。 Addressed: Palo Alto Networks Product Security Regarding the June 5th OpenSSL Security Advisory https://live.paloaltonetworks.com/t5/Threat-Articles/Addressed-Palo-Alto-Networks-Product-Security-Regarding-the-June/ta-p/59677     更新: 本文書に書かれた問題は既に対応済みです。 この問題は、PAN-OS 6.0.4, 5.1.9, 5.0.14にて対応済みです。これらのバージョン、もしくはそれ以降のバージョンにすることで問題は回避されます。   要約 Palo Alto Networks PAN-OS ソフトウェアは、特定の限られたケースにおいて、マン・イン・ザ・ミドル (MITM) 攻撃に繋がる脆弱性CVE-2014-0224の影響を受ける可能性があります。これに対応するため、Palo Alto Networksは、全てのサポート対象のバージョンに対し、次に予定されているメンテナンス リリースにおいて弊社の製品で使われているOpenSSLソフトウェアにパッチを適用します。なお、GlobalProtectは影響を受けません。   注: 2014年6月5日に報告されたOpenSSLの脆弱性のうち、その他6つのCVEに関しては、弊社のソフトウェア プラットフォームは影響を受けません。   詳細 Palo Alto Networksの製品セキュリティ エンジニア チームは2014年6月5日に報告されたOpenSSLの脆弱性が弊社の製品に影響を及ぼすかどうか解析を行いました。記載されている7つのCVEのうち、CVE-2014-0224のみが弊社のソフトウェアに関連していることがわかりました。残りのCVEに関しては、弊社のソフトウェアは DTLS (Datagram Transport Layer Security)、及びアノニマス ECDH (Elliptic curve Diffie-Hellman) を使わないため影響はありません。CVE-2014-0224による影響も限られています。何故なら、影響を受けるのはクライアントとサーバーが同時に脆弱である場合であるためです。PAN-OSはクライアントとしては影響を受けますが、サーバーとしては影響を受けません。結果、マン・イン・ザ・ミドル (MITM) 攻撃の影響を受ける可能性があるのは、脆弱性のあるOpenSSLバージョン(OpenSSL 1.0.1 and 1.0.2-beta1)を使っている外部のサーバーに弊社のソフトウェアが接続をしにいった際に作られるセッションのみに限られます。   お客様の設定によって、MITMに対して脆弱なサービスは様々です。例えば、脆弱なOpenSSLサーバーを動かしているプロキシをSSLを用いて使うファイアウォールのサービスであったり、脆弱なOpenSSLサーバーを動かしているsyslogサーバーへSSLでログ転送するサービスであったり、脆弱なOpenSSLサーバーを動かしているディレクトリ サーバーに接続に行くユーザーIDエージェントなどがあります。GlobalProtectポータルとゲートウェイは脆弱でないため、GlobalProtectは影響を受けません。   これに対応するため、Palo Alto Networksは、全てのサポート対象のバージョンのPAN-OS、ユーザーIDエージェント、GlobalProtectに対し、次に予定されているメンテナンス リリースにおいて弊社の製品で使われているOpenSSLソフトウェアにパッチを適用します。お客様は、自身が運用するサーバーにおいて脆弱性のあるOpenSSLのバージョン(1.0.1 and 1.0.2-beta1)を使わないようにすることで、上記に書かれた問題を回避することができます。不明な点がありましたら、Palo Alto Networks サポートチームにお問い合わせ下さい。    OpenSSL アドバイザリ: https://www.openssl.org/news/secadv_20140605.txt  (英文)   著者: gwesson

※この記事は以下の記事の日本語訳です。 How to Configure GlobalProtect for Authentication Using Only Certificates（訳注1） https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-GlobalProtect-for-Authentication-Using-Only/ta-p/54910   概要 この文書は証明書のみを使用したGlobalProtectの認証の設定手順を記載します。ユーザーはログインのための入力を促されることはありません。   手順 [Device] > [証明書の管理] > [証明書プロファイル] で証明書プロファイルを作成します。 [ユーザー名フィールド]が'サブジェクト'かつ右隣のグレーアウトされた欄が"common-name'であることを確認しておいてください。[CA証明書]欄にCA証明書を追加します。 下図は作成した証明書の一例です。 GlobalProtectゲートウェイを設定します。 [認証プロファイル]をNoneとし、前述の手順1で設定した証明書プロファイルを[証明書プロファイル]設定します。 GlobalProtectポータルを設定します。 [認証プロファイル]をNoneとし、[クライアント証明書]と[証明書プロファイル]を選択します。 注：クライアント証明書をファイアウォールで生成するということは、該当のクライアント証明書をサポートする証明書基盤がネットワーク上で構築済みであることが前提とされます。あるいは[クライアント証明書]はマルチユーザー環境では必要なく、推奨されません。それぞれのユーザーが認証局から個別の証明書を受け取って使用する運用とするため、ユーザーの証明書を署名した認証局を設定した[証明書プロファイル]を使うほうが良いでしょう（訳注2）。 [クライアントの設定]タブにて[シングル サインオンの使用（SSOの使用）]のチェックを外します。 ルート証明書とクライアント証明書をクライアントPCのWindowsのローカルコンピュータの証明書ストア、またはMacOSのシステム キーチェーンにインストールします。 注：クライアント マシン証明書をパロアルトネットワークスのデバイスからエクスポートするときはPKCS12ファイル フォーマットを選択する必要があります。 クライアント証明書を クライアントPCのWindowsの現在のユーサーの証明書ストア、またはMacOSの個人用キーチェーンにインストールします。 Global Protectクライアントではユーザー名とパスワードを入力する必要がなくなります。 ファイアウォールで設定をコミットします。GlobalProtectクライアントは自動的にゲートウェイに接続します。該当のゲートウェイの[リモートユーザー]でクライアント証明書によるログインのユーザーが確認できます。   訳注1:原文のComment欄では、証明書認証でのGlobalProtect使用について、設定時の注意事項も含めてディスカッションが継続して行われております。原文もあわせてご参照ください。   訳注2:PAN-OS 5.0以降では認証そのものは[証明書プロファイル]でおこなわれ、[クライアント証明書]に設定した証明書はクライアント－ポータル/ゲートウェイの双方向認証のために、Windows の現在のユーザーの証明書ストア、またはMacOS の個人用キーチェーン端末の証明書ストアにインストールされます。詳細はGlobal Protect管理者ガイドを御覧ください。 PAN-OS 5.0からの挙動についてはGP Portal No Longer Prompts for Client Certificates after PAN-OS v5.0.x Upgrade をご参照ください 。     著者：pvermuri

※この記事は以下の記事の日本語訳です。 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

※この記事は以下の記事の日本語訳です。 How to Uninstall GlobalProtect Client Mac OS X https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Uninstall-GlobalProtect-Client-Mac-OS-X/ta-p/58933   概要 このドキュメントでは MAC 用 GlobalProtect のアンインストールに使用する 2 つの方法を説明します。   詳細 ターミナルを使ったアンインストール $ sudo /Applications/GlobalProtect.app/Contents/Resources/uninstall_gp.sh   pkg ファイルによるアンインストール インストールに使用した最初の .pkg ファイルを実行します。このファイルは GlobalProtect Portal ページからダウンロードできます。 Introduction ページで Continue を選択します。 Destination Select ページで "Install for all users of this computer" にチェックし、Continue をクリックします。   "GlobalProtect" のチェックを外して、"Uninstall GlobalProtect" にチェックし、Continue をクリックします。 "Install" をクリックします。   著者: sspringer

※この記事は以下の記事の日本語訳です。 GlobalProtect Gateway Certificate Error When Trying to Use GlobalProtect Agent 2.1.0 https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-Gateway-Certificate-Error-When-Trying-to-Use/ta-p/57043   問題 Palo Alto Networks ファイアウォールに GlobalProtect Agent のバージョン 2.1.0 で接続するときに、ポータルへの接続には成功するものの、ゲートウェイへの接続を行う際に証明書エラーが発生します。以前の Agent バージョンを使用した場合は問題なく接続されます。   原因 この問題は GlobalProtect バージョン2.1.0で追加された新規のチェックが原因となります。新規の検証チェックは GlobalProtect ポータルで構成されたゲートウェイ アドレスと証明書の CN (コモンネーム) が一致することを確認します。このチェックは以前のバージョンでは実装されていなかったため、この問題は発生しませんでした。 注： ゲートウェイ アドレスを FQDN で構成し、証明書にこの FQDN が登録されているとき、 PTR レコードが DNS に生成されるまで GlobalProtect Agent のバージョン 2.1.0 には証明書エラーが発生します。   解決方法 どの証明書プロファイルをゲートウェイの設定で使用しているか確認します。 Device > 証明書の管理 > 証明書 に移動し、手順1で確認した証明書プロファイルの CN をメモします。 GlobalProtect ポータルのクライアント設定にて、ゲートウェイのアドレスを手順2でメモした CN へ変更します。 変更を Commit し、 Agent でファイアウォールに再接続してください。   注意: ゲートウェイ証明書の Subject Alternative Name (SAN) 属性にホスト名 (DNS Name) が含まれている場合、上記の記事に示されているように証明書のコモンネームと一致している必要があります。   重要！この設定変更を行う前に、ファイアウォール上で使用されているDNSサーバが "GlobalProtect Portal" のホスト ネームをパブリック IP アドレスへ解決できること、また IP アドレスをホスト ネームに解決するための PTR レコードがあることを確認してください。ホスト ネームが内部 IP アドレスに解決される場合、外部インターフェイスからポータルにアクセスできなくなります。  

※この記事は以下の記事の日本語訳です。 GlobalProtect Portal and Gateway License Requirements https://live.paloaltonetworks.com/t5/Configuration-Articles/GlobalProtect-Portal-and-Gateway-License-Requirements/ta-p/57162   概要 GlobalProtect ポータルおよびゲートウェイが必要となるシナリオを列挙します。   GlobalProtect ポータル ライセンス   PAN-OS 7.0以前： 以下の状況でGlobalProtect ポータル ライセンスが必要となります。 HIPを使用 複数のゲートウェイを設定 内部ゲートウェイを設定 PAN-OS 7.0以降: GlobalProtect ポータル ライセンスは必要ありません。     GlobalProtect ゲートウェイ ライセンス   以下の状況でGlobalProtect ゲートウェイ ライセンスが必要となります。 HIPを使用 iOSまたはAndroid モバイル アプリケーションを使用 GlobalProtect ゲートウェイ ライセンスの要件はPAN-OS version 7.0による変更はありません。   ポータルおよびゲートウェイの高可用性（HA）実装では双方のデバイスに同一のライセンスのインストールが必要です。   参考   GlobalProtect Configuration Tech Note（英文） GlobalProtect Configuration for the IPsec Client on Apple iOS Devices （英文） GlobalProtect Configuration for the IPSec Client on Android Devices（訳注：2016/04/08現在、本記事は参照できません。）   著者：sdarapuneni

※この記事は以下の記事の日本語訳です。 How to Configure GlobalProtect https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-GlobalProtect/ta-p/58351   GlobalProtect (GP) を実装するための設定:   Palo Alto Networks firewall 上で GlobalProtect クライアントをダウンロードし、アクティベート実行 ポータル設定 ゲートウェイ設定 Trust ゾーンとGlobalProtect クライアント間のルーティング (場合によってはUntrust ゾーンとGlobalProtect クライアント間) Trust ゾーンとGlobalProtect クライアント間のトラフィックを許可するSecurity および NAT ポリシーの設定 オプション: GlobalProtect クライアントからインターネットにアクセスするためのNATポリシー (スプリット トンネリングが無効な場合) iOS および Android デバイスは接続するためにGlobalProtect アプリケーションを使用することができます。   ポータル設定   最初は証明書プロファイルを設定せずにテストされることを推奨します。これは初期設定で意図したとおりに動作しない場合、トラブルシュートを容易にすることを可能にします。正常に設定でき、基本的な認証が成功したら、証明書認証用の証明書プロファイルを追加します。   Portal のIPアドレスは外部のGP クライアントが接続するためのアドレスです。ほとんどの場合、外部インターフェイスを指定し、通常Gateway アドレスも同じIPアドレスとします。   GlobalProtect 接続方式: On-demand: VPN へのアクセスが必要なときに手動で接続する必要があります。 User-logon: ユーザーがマシンにログインするとすぐにVPN が確立されます。SSO を有効にすると、Windows のログオン情報からユーザー資格情報を自動的に取り出し、GP クライアントのユーザーを認証するために使用されます。 Pre-logon: マシンにログインする前にVPN が確立されます。この設定にはマシン証明書が必要になります。 Agent タブはユーザーがGP Agent上での実施可否に関する重要な情報が含まれています。"GlobalProtect の無効化を許可" で "with-comment"と設定した場合、コメントや理由を入力した後、ユーザーがGP Agent を無効化することができます。このコメントはユーザーが次回ログインしたときにシステム ログに表示されます。   "disabled" オプションを選択すると、ユーザーが任意でGP Agent を無効化することから防ぎます。   ゲートウェイ設定 初期設定の際は、基本設定のみを実施されることをお勧めします。全ての設定について確認されたあと、必要に応じてクライアント証明書による認証を追加できます。   サードパーティ製のVPN アプリケーションを使用するデバイスを認証するには、ゲートウェイのクライアントの設定にて " X-Auth サポートの有効化 " をチェックします。グループ名とグループ パスワードを設定する必要があります。   ほとんどの場合、静的な公開IPアドレスを持つファイアウォールのために、継承ソースは"None"に設定します。   ファイアウォールが接続してきたGP クライアントに割り当てるIP アドレスのプールとなるため、IP プール設定の情報は重要です。GP クライアントはローカル ネットワークの一部として考慮される場合であっても、ルーティングを容易にするため、LAN アドレス プールと同じサブネットをIP プールに使用することを推奨しません。送信元が異なるサブネットの場合、 社内 サーバーはゲートウェイにパケットを自動的に送り返します。GP クライアントがLANと同じサブネットからIP アドレスを発行された場合、内部LAN リソースはGP クライアントへの通信をファイアウォール (デフォルトGW) へ向けることはありません。   アクセス ルート アクセス ルートとはGP クライアントが接続することを期待されるサブネットです。ほとんどの場合、これはLAN ネットワークとなります。インターネット向けの通信を含む全ての通信をファイアウォールを通過するように強制するには、全ての通信を意味する "0.0.0.0/0" と設定する必要があります。     "0.0.0.0./0" が設定されている場合、セキュリティ ルールはGP クライアントがアクセスできる社内LANリソースを制御することができます。セキュリティポリシーがGP クライアント ゾーンからUntrust ゾーンへの通信を許可していない場合、GP クライアントからPalo Alto Networks ファイアウォールにSSL VPN経由で接続された際、クライアントは内部リソースのみアクセスすることができ、インターネットへの通信は許可されません。   GlobalProtect クライアントのゾーンとトンネルは他のインターフェイスと同じバーチャル ルーターに含まれている必要があります。

※この記事は以下の記事の日本語訳です。 How to Install a Chained Certificate Signed by a Public CA https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Install-a-Chained-Certificate-Signed-by-a-Public-CA/ta-p/55523   概要 Palo Alto Networks 次世代ファイアウォールを設定する際、信頼された公的な証明機関（CA）によって署名された証明書を以下の用途に使うことができます： Captive Portal ("CP") ページ レスポンス ページ GlobalProtect ("GP") ポータル 多くの公的CAはチェーン証明書を使用します。チェーン証明書では、証明書がルート証明書自身によって署名されているのではなく、一つ以上の中間証明書によって署名されています。これらは主に同じCAによって所有され運用されますが、こうすることによって柔軟性を持たせ、何か問題が起きたときに証明書を失効しやすくなります。   手順 1. 証明書のリクエスト ファイアウォールにインストールされているPAN-OSのバージョンによって、秘密鍵とCSRはOpenSSLなどのサードパーティ プログラムを使用して生成する必要があります。 もしPAN-OS 5.0を使用しているのであれば、以下のドキュメントを参照してください。 How to Generate a CSR(Certificate Signing Request) and Import the Signed Certificate   2. 証明書の連結 証明書がルートCAによって署名されない場合、クライアントの信頼済み鍵ストアに中間証明書が既に存在しなければ、中間証明書がクライアントに送信されなければなりません。これを実現するために、CP、GP、またはレスポンスページの証明書に中間証明書が続く形で署名された各証明書を連結します。以下の図は中間証明書が二つの場合の例ですが、中間証明書が一つだけの場合や、複数の場合でも同様のやり方で実現できます。     各証明書を取得する手順は以下の通りです： CAから送られてきた"サーバー証明書"を開きます。 ウィンドウズにおいては証明書のダイアログ ボックスには"全般"、"詳細"、"証明のパス"の三つのタブが存在します。 "証明のパス"をクリックし、一番下から一つ上の証明書をクリックします。 その証明書を開き、詳細タブをクリックします。そしてテキストファイルにコピーします。 そのファイルをBase-64 エンコード X.509 (.CER) フォーマットの証明書として保存します。 同様の手順を一番上のルート証明書以外の全ての証明書に対して行います。 それぞれの .CER 証明書ファイルをプレーン テキスト エディタ (メモ帳など)で開きます。 サーバー証明書を先頭に、各証明書を間を開けずに貼り付けていきます。 拡張子を .TXT または .CER にして保存します。 注: ファイル名に空白文字を含めることはできません。空白文字が存在するとインポートに失敗する恐れがあります。   3. 証明書のインポート 前述の手順で連結した証明書をファイアウォールにインポートします。 PAN-OS 4.1以前のバージョンでは, 秘密鍵をこの証明書と共にインポートする必要があります。詳細は上記手順1を参照してください。OpenSSLでCSRを生成する際に秘密鍵が生成されます。 PAN-OS 5.0においては、秘密鍵は既にファイアウォール上に存在します。証明書のインポートをするためには、以下のドキュメントに書かれた手順を参照してください。 How to Generate a CSR and Import the Signed CA Certificate  

※この記事は以下の記事の日本語訳です。 GlobalProtect Client not Connecting https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-Client-not-Connecting/ta-p/53185   GlobalProtect 1.2 以上   問題 GlobalProtect クライアントで接続ができません。   以下のログが PanGPA.log 内で出力されます: P 195-T519 Oct 09 18:02:17:24315 Info ( 83): Failed to connect to server at port:4767 P 195-T519 Oct 09 18:02:17:24325 Info ( 460): Cannot connect to service, error: 61 P 195-T519 Oct 09 18:02:17:24330 Debug( 742): Unable to connect to service   原因 これは、PanGPA サービスの接続が同じ端末上の PanGPS サービスへ実施される際に発生する問題です。   解決策 PanGPA サービスは localhost の 4767ポートで通信を待ち受けている必要があります。確認するには以下のコマンドを実施します。   MACの場合 : netstat -an | grep 4767 tcp4 0 0 127.0.0.1.4767 *.* LISTEN   Windowsの場合 : netstat -an | find "4767" TCP    127.0.0.1:4767         0.0.0.0:0              LISTENING   4767ポートでの待ち受けが確認できない場合、サービスは正しく起動していません。PanGPS.log の内容を確認したり、OS上で競合状態等が発生してないかを確認します。   もし4767ポートでの待ち受けが確認できた場合、TELNETコマンドで接続性を確認します。(telnet 127.0.0.1:4767)  TELNET接続に失敗する場合、端末上のファイアーウォール機能が通信を破棄していないか確認します。ファイアーウォール機能を一時的に無効にしてテストを実施することも検討します。