R75, R77 台
RC4 暗号方式のために HTTPS 接続ができない
R75 台では TLS 暗号方式がデフォルトで RC4 になっています。ですが現在ののブラウザでは RC4 は非対応になっているため、デフォルトのままではどのブラウザを使っても HTTPS 接続ができません。つまり、初期設定ウィザードすら表示することができません。
回避策としては、Check Point 機器にコンソール接続して TLS 暗号方式として RC4 を使用しないように設定変更します。設定方法については以下のサポート情報を確認してください。
ただし、上の回避策を実施したとしても IE 以外では HTTPS アクセスできません。
R75.40 の Gaia ポータルにはアップグレード用の画面がある
R77.30 以降では、Gaia ポータルの CPUSE の画面で各種パッチやアップグレード/クリーンインストールのパッケージをインポートしたり適用したりすることができます。一方、R75.40 では、Gaia ポータルに Upgrade という画面があり、アップグレード用パッケージのインポートや適用はこの画面で行う必要があります。R75.40 では CPUSE の画面でアップグレード用パッケージのインポートをしようとするとインポートに失敗します。
初期設定ウィザード後に SmartDashboard にてログインが失敗する
初期設定ウィザード実施後に、初めて SmartDashboard にて管理サーバにログインしようとしたときに、以下のようなエラーメッセージが表示されてログインできない場合があります。
- Connection cannot be initiated. Please make sure the server ‘x.x.x.x’ is up and running and that you are defined as a GUI Client.
このとき、CLI で cpca_client lscert コマンドで証明書情報を表示しようとすると以下のような内容になり、証明書情報が表示できません。
> cpca_client lscert
Operation failed. rc=-1.R77.30、R75.40 のとあるアプライアンスでこの事象を確認していますが、原因は、内部認証局の初期設定時に作成される証明書の有効期限が関係していて、2018年1月24日以降に初期設定ウィザードを実行した場合にこの事象が発生する場合があります。
回避策としては、システムの日付設定を一時的に2018年1月23日以前に設定した後で、内部認証局の初期化をすることです。（CLI で日付設定後は save config を実行します。）
内部認証局の初期化は cpconfig コマンドから実施します。cpconfig のメニューの中から「Certificate Authority」の番号を指定すると内部認証局を初期化できます。
> cpconfig
This program will let you re-configure
your Check Point products configuration.
Configuration Options:
----------------------
(1) Licenses and contracts
(2) Administrator
(3) GUI Clients
(4) SNMP Extension
(5) PKCS#11 Token
(6) Random Pool
(7) Certificate Authority
(8) Certificate's Fingerprint
(9) Disable Check Point SecureXL
(10) Check Point CoreXL
(11) Automatic start of Check Point Products
(12) Exit
Enter your choice (1-12) :7
Configuring Certificate Authority...
====================================
The Internal CA will now be initialized
with the following name: hostname
Is it OK (y/n) [y] ? y
Initializing the Internal CA...(may take several minutes)
Internal Certificate Authority created successfully
Certificate was created successfully
Certificate Authority initialization ended successfully
Trying to contact Certificate Authority. It might take a while...
hostname was successfully set to the Internal CA
Doneなお、システム日付設定を2018年1月23日以前に設定していない場合は内部認証局の初期化は失敗します。
内部認証局を初期化できたら以下の手順を実施します。
cpstop/cpstartを実行し Check Point サービスを再起動- 日付設定を正しい日付に戻す（設定後
save configを実行） - 再度
cpstop/cpstartを実行し Check Point サービスを再起動
この後、cpca_client lscert コマンドで証明書情報が表示できることを確認してください。
証明書情報が表示できていれば、SmartDashboard でログインができるはずなのでその確認をしてください。
Check Point クラウドサーバのドメインが古くてアクセスできない
これは R75.40 のとあるアプライアンスで判明した事象です。
ライセンスのオンラインアクティベートを試してみたところ、ネットワーク接続性の問題で Check Point クラウドサーバにアクセスできないとのエラーになりました。設定・環境上は問題ないはずだったのでパケットキャプチャしてみたところ、Check Point のドメインに関する DNS クエリに対する戻りパケットとして DNS サーバから「そのドメイン見つからなかったぞい」というパケットが来ていました。
どうやら Check Point 機器内部で持っている Check Point クラウドのドメインが古いか何かの理由で名前解決できなかったようです。これはもうどうしようもないですね。検証でライセンスが必要な場合はサポートから評価ライセンスをもらってください。
Deployment Agent のバージョンが古い場合は手動アップデートが必要
バージョンが古い機器の場合、Deployment Agent も古いバージョンになっている場合があります。Deployment Agent のバージョンが一定以上であれば、機器がインターネット接続できる環境にあれば Deployment Agent をオンラインで自動アップデートしたり、JHF やアップグレード用のパッケージを Gaia ポータル上でインポートしたりできますが、古いバージョンではそれができません。
Deployment Agent が古いバージョンの場合は手動でアップデートする必要があります。アップデートするためにはアップデート用のデータを入手して機器に格納し、インストールコマンドを実行する必要があります。アップデート用のデータはサポートから提供してもらう必要があるため、サポートに問い合わせをしてください。
R75.40 では Gaia バックアップ/リストアは CLI でのみ対応
R75.40 では Gaia ポータルに System Backup の画面があるにもかかわらず、Gaia ポータル上からのバックアップ/リストアには対応しておらず、CLI からの実行のみ対応しています。
R75.40 のとあるアプライアンスで Gaia ポータルにてリストアを実行したところ、リストアは実行できるものの、中途半端な結果となり正常にリストアできませんでした。その後、CLI でリストアしたところ正常にリストアできました。
この結果から、R75.40 ではバックアップ/リストアは CLI での実施を推奨します。
R80 台
R77.30 から R80.40 にデータ移行後 FWM が起動しない
R77.30 機器で R80.40 向けに migrate export した管理サーバデータを R80.40 機器で migrate import 後、R80.40 機器で FWM サービスが起動しない事象に遭遇したことがありました。
その際、以下のページに記載の対応をすることで解決できました。
R81 台
R81 については以下の記事にまとめています。
共通
アップグレードしても Factory Default 先のバージョンは変わらない
アプライアンスでバージョンアップをしたい場合、現在の設定値を引き継ぎつつバージョンアップする「アップグレード」と、設定値を完全に初期化しつつバージョンアップする「クリーンインストール」の 2 つの方法があります。
「アップグレード」方式でバージョンアップした場合、Gaia ポータルから実施できる Factory Default の初期化先バージョンはアップグレード前のバージョンのままとなっています。
検証などでバージョンアップ後にバージョンを元に戻す予定がある場合などは、アップグレード方式で行うとバージョンダウンを簡単に行うことができます。
Full High Availability クラスタのプライマリ機のホスト名は変更できない
Check Point 機器のホスト名変更や IP アドレス変更は、管理サーバ（SmartConsole）上でのオブジェクトの設定にも影響するため慎重、かつマニュアルの手順に従って行う必要があります。
管理サーバとゲートウェイが分かれている分散構成の場合は、面倒ではあるもののホスト名の変更は可能です。
ただ、スタンドアロン構成における冗長化である Full High Availability クラスタ を構成している場合は、プライマリ機のホスト名変更ができません。
プライマリ機の「ホスト名変更ができない」の意味としては、SmartConsole 上でのオブジェクトの名前変更ができません。
Full High Availability クラスタにおける機器ホスト名変更は、SmartConsole 上ではクラスタオブジェクト配下のメンバーオブジェクトの名前変更になりますが、メンバーオブジェクトの名前変更をするためには、先に SIC 認証のリセットをする必要があります。
ここで、セカンダリ機に対しては SIC 認証のリセットができますが、プライマリ機に対しては SIC 認証のリセットができません。このためプライマリ機についてはホスト名変更ができません。
この仕様は、Full High Availability クラスタ構成の既存機器をリプレイスする際のキッティング方法に影響します。通常、Check Point 機器をリプレイスする際は、管理サーバデータベースを既存機器からエクスポートし、そのデータを新機器にインポートすることでデータを移行します。
この時、クラスタオブジェクト及びメンバーオブジェクトの名前は既存機器と同じになるため、新機器のホスト名は既存機器と同じにする必要があります。
この仕様から、プライマリ機のホスト名を新機器では変えたい場合、既存機器のエクスポートデータをインポートするという方法を採ることができません。
スタンドアロン構成でログサーバ機能を無効化するとエラーになる
ゲートウェイ機能と管理サーバ機能が1台の機器にインストールされたスタンドアロン構成の場合、SmartConsole のスタンドアロン機器オブジェクトのプロパティ設定で Logging and Status（ログサーバ機能）を無効化することはできません。無効化しようとするとエラーとなり設定を変更できません。
リンクダウン時間が短いとリンクダウントラップが飛ばない
Gaia の SNMP 設定で linkUpLinkDown を設定している場合、リンクダウンとリンクアップ時にトラップが飛びます。
しかしリンクダウン後、一定時間内に復旧しリンクアップした場合、リンクダウントラップは飛びません。体感では大体30秒程ダウン状態が続かなければリンクダウントラップは飛びません。
これは仕様となります。
Trap User 設定をしていない場合リンクダウン・アップのトラップが飛ばない
Gaia の SNMP 設定で linkUpLinkDown を設定している場合、リンクダウンとリンクアップ時にトラップが飛びます。
しかし、Enable Traps で linkUpLinkDown を設定しただけではリンクダウン・アップのトラップは飛びません。追加的に Trap User の設定をする必要があります。
Trap User の設定では、SNMP V3 ユーザを指定する必要があります。したがって、SNMP v3 ユーザも必然的に設定する必要があります。これは、実際に運用で SNMP v3 を使っておらず v2c を使用している場合においても設定する必要があります。
なお、設定する SNMP v3 ユーザの設定内容は適当なダミー設定で問題ありません。
参考資料
