FortiGate

【禁断の異機種間HA】FortiGate-60F/60EでHAを組んでみた!

こんにちは。takiです。

タイトルの通り今回もやってみた系の記事となります。

経緯としては、FortiGateのHAで検索すると様々な記事で「同モデル、同バージョンのFortiOSでないとHAは組めない」と書かれていました。

しかし、Fortinet社の公式ドキュメントを見てもそのような記載はなく、実際の所どうなんだろうと疑問に思ったので今回実機を使って検証を行ってみました。

前提条件

※本記事では実機を用いた独自の検証結果をもとに記載しており、メーカーの見解と異なる可能性があります。

※本記事を基に環境を作成された際に発生するいかなる不具合・故障について、弊社グループでは一切の責任を負いかねます。

今回行った検証環境は以下の通りです。

プライマリ機:FortiGate-60F/FortiOS7.0.8 build0418

セカンダリ機:FortiGate-60E/FortiOS7.0.8 build0418

図 1 環境構成図

手順

初めに各機のインターフェース設定は下図の通りです。

図 2 プライマリ機:FGT-60F

図 3 セカンダリ機:FGT-60E

インターフェースの用途はそれぞれ以下の通りです。

インターフェース名 用途
WAN1 トラフィック用
internal1 HAハートビート用
internal2 HAハートビート用
internal3 管理予約インターフェース

 

HA設定を行います。

「システム」>「HA」に移動し、以下のように設定します。

設定後は以下のように表示されます。

同様にセカンダリ側も設定します。

セカンダリ機にするため、プライオリティを100(プライマリ機では200)とします。

設定後、HAの同期が始まるため以下のようになり、セカンダリ機に管理アクセスが行えなくなります。

プライマリ機側では60Eが認識されてます。

セカンダリ機に管理アクセスするために、プライマリ機側から管理インターフェースの設定を行います。

(※今回の環境では、管理予約インターフェースに設定するIPアドレスのセグメントがWAN1インターフェースと同じなため、HAを組んでからの設定となります。)

設定後、セカンダリ機の管理予約インターフェースに設定したIPアドレス「172.23.61.165」にHTTPSでアクセスします。

ログイン後、HAの設定を確認するとセカンダリ機側でもHAが認識されています。

※コンフィグが同期されたため、60Eのテーマが変わっています。

結果

今回の検証では異なるモデル同士でもHAを組むことが出来ました。

60Fをプライマリ、60Eをセカンダリとしており、下図がセカンダリ機のHA画面になります。

(※60Eの画面のため型番名が両方とも60Eになっています)

ステータスが「未同期」となっていますが、これは60Eと60Fではインターフェース名が異なるため、system.interfaceの部分でどうしてもHAが未同期となってしまいます。

(※60Eのinternal6,7が、60Fではa,b表記の為)

参考までに60Fと60Eのデータシートのリンクは貼っておきます。

・FortiGate-60F

https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/ja_jp/FGT60FDS.pdf

・FortiGate-60E

https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/ja_jp/FGT60EDS.pdf

HAのステータスを確認するコマンド、「get system ha status」の結果は以下の通りです。

FGT-60F # get sys ha status

HA Health Status: OK

Model: FortiGate-60F

Mode: HA A-P

Group: 128

Debug: 0

Cluster Uptime: 0 days 21:42:21

Cluster state change time: 2022-11-22 17:35:30

Primary selected using:

<2022/11/22 17:35:30> FGT60FXXXXXXXXX is selected as the primary because its override priority is larger than peer member FGT60EXXXXXXXXX.

ses_pickup: enable, ses_pickup_delay=disable

override: enable

Configuration Status:

FGT60FXXXXXXXXX(updated 1 seconds ago): in-sync

FGT60EXXXXXXXXX(updated 1 seconds ago): out-of-sync

System Usage stats:

FGT60FXXXXXXXXX(updated 1 seconds ago):

sessions=19, average-cpu-user/nice/system/idle=1%/0%/0%/98%, memory=41%

FGT60EXXXXXXXXX(updated 1 seconds ago):

sessions=1644167169, average-cpu-user/nice/system/idle=41%/0%/0%/0%, memory=31%

HBDEV stats:

FGT60FXXXXXXXXX(updated 1 seconds ago):

internal1: physical/1000auto, up, rx-bytes/packets/dropped/errors=5385302922/23653106/0/0, tx=241558566769/162849068/0/0

internal2: physical/1000auto, up, rx-bytes/packets/dropped/errors=29401951/74046/0/0, tx=29907830/74051/0/0

FGT60EXXXXXXXXX(updated 1 seconds ago):

MONDEV stats:

FGT60FXXXXXXXXX(updated 1 seconds ago):

wan1: physical/1000auto, up, rx-bytes/packets/dropped/errors=427859171/2873803/0/0, tx=439919144/1802764/0/0

FGT60EXXXXXXXXX(updated 1 seconds ago):

Primary     : FGT-60F         , FGT60FXXXXXXXXX, HA cluster index = 0

Secondary   :                 , FGT60EXXXXXXXXX, HA cluster index = 1

number of vcluster: 1

vcluster 1: work 169.254.0.1

Primary: FGT60FXXXXXXXXX, HA operating index = 0

Secondary: FGT60EXXXXXXXXX, HA operating index = 1




FGT-60F #

フェイルオーバーも可能です。

モニターインターフェースであるプライマリ機のWAN1インターフェースを手動で抜線します。

60FのWAN1がリンクダウンし、60Eのロールがプライマリになっているのが確認できます。

不安定な動作

ここまではうまくいっていましたが、何回か動作を確かめているうちに以下の不安定な事象が発生しました。

①60Eがセカンダリの時のみ、NTP時刻同期が出来なくなる。
➁セカンダリ機の管理画面のセッションが頻繁に切れる(60F/60Eともに)。

 

①については、通常Active-Passive構成のセカンダリ機の時刻同期はプライマリ機に問い合わせされますが、60Eがセカンダリの場合のみなぜか時刻同期が出来なくなります。

プライマリ機である60FのNTPは時刻同期が出来ています。

HAを切り替えて60Eをプライマリにすると時刻同期が出来、セカンダリとなった60Fでも時刻同期が出来ているため、特有の事象と思われます。

 

②については、60F/60Eのどちらがセカンダリであろうと管理インターフェースに設定したIPアドレスに対して、HTTPSのアクセスを行うとセッションが頻繁に切れて、ログイン画面に戻ってしまいます。

これに関しては体感となりますが、ログインしてから30秒~1分ほどでログイン画面に戻されます。

アイドルタイムアウトは60分に設定しているので、通常は何も操作していない状態でも60分はログイン画面に戻されないはずです。

まとめ

同バージョン/異同モデルの構成でHAを組んでみました。

HA自体は組めて、コンフィグ同期、フェイルオーバーも動作することが確認できました。

しかしながら、前章でも記述したようにNTPの時刻同期と管理画面のセッションタイムアウトが頻繁に発生してしまうため、運用で使用するには難しいと思われます。

また、今回の構成がたまたまHAが組めただけの可能性もあり、別のバージョンや別のモデル同士(100Fと100E)ではうまくいくかは分かりません。(※同様に別の構成であればさらにうまくいく可能性もありますが、、)

最後に、今回の記事はやってみた系の記事となりますので、上記の具体的な原因については深堀が出来ておりません。今後、機会があれば詳細なログ調査を記事にしようかと思います。

記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。

当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。

LogStare CollectorでのCloudTrail管理イベントログの取得方法とログレポート前のページ

DNSキャッシュポイズニングやってみた次のページ

ピックアップ記事

  1. Zabbixヒストリデータのレポート生成について
  2. 自社製品をAMIにしてAWSマーケットプレイスへ出品
  3. IoT機器「Raspberry pi」とLogStare Collectorで温…
  4. ログフォワーダー「okurun.jar」について

関連記事

  1. NW機器

    FortiGateにおけるCEF形式ログ送信設定

    当記事では、FortiGateにおけるCEF形式でのログ送信方法につい…

  2. Azureマーケットプレイスへの出品

    AWS/Azure

    Azureマーケットプレイスに自社製品を出品する手順と注意点

    弊社では「LogStareCollector」をAWSマーケットプレイ…

  3. NW機器

    OpenSSLの脆弱性(CVE-2022-0778)に対する各UTM/IPS/WAFの対応状況につい…

    セキュアヴェイルの新入社員となりました新社会人 0x90 がOpenS…

  4. NW機器

    FortiGateにおける複数のSyslogサーバへログ転送を行う設定について

    当記事では、FortiGateにおける複数のSyslogサーバへログ転…

  5. NW機器

    FortiGateのVDOM毎にログの転送先syslogサーバ指定を行う設定について

    当記事では、FortiGateのVDOM毎にログの転送先syslogサ…

  6. FortiGate

    FortiGateのGARP(Gratuitous ARP)の送信タイミングについて検証してみた!

    こんにちは、takiです。直近の案件で別チームがUTMのリプレ…

ナレッジステアはセキュアヴェイルグループが運営しています

ネットワーク管理者向けセキュリティセミナー

無料で使えるシステム監視・ログ管理ソフト

  1. NW機器

    SonicWall UTMにSyslog送信設定を追加する方法について
  2. 実践記事

    DNSキャッシュポイズニングやってみた
  3. SNMPを触ってみた

    ログ分析・監視テクニック

    SNMPとは?新入社員が生まれてはじめて触ってみた!
  4. NW機器

    PaloAltoのIPsec IKEv1 Phase1におけるトラブルシューティ…
  5. NW機器

    Nutanix Prism ElementにおけるSNMP監視/REST API…
PAGE TOP