FortiGateのSD-WAN機能(Fortinetの製品名ではSecure SD-WAN)は、複数のWAN回線を1つのゾーンにまとめ、遅延・ジッター・パケットロスの実測値に応じて通信ごとに経路を選ぶ機能です。追加ライセンスなしで全機種が使えます。つまずくのは画面操作ではなく、メンバー登録前に消す設定、ヘルスチェックの既定値、SLAを見ないルールの3点です。この記事では4階層の構成を軸に、CLIの設定例、切替時間の計算、Microsoft 365のブレイクアウト、FortiOS 8.0の新機能、機種とライセンスの選び方を、公式ドキュメント(FortiOS 7.6.7・8.0.1)に沿って整理します。
まとめ
- FortiGateのSD-WANはゾーン → メンバー(WAN回線) → パフォーマンスSLA → SD-WANルールの4階層。CLIは
config system sdwanの配下に収まる。 - メンバーにする回線を参照しているスタティックルートとポリシーを先に外す(7.6.5以降の一部の2WANポート機は出荷時からSD-WAN構成済み)。
- SLAの既定しきい値はレイテンシ5ms・ジッター5ms・パケットロス0%。回線とプローブ先によっては平常時から超えるので、実測値から決め直す。
- SLAの合否を見るのはLowest Cost (SLA)とMaximize Bandwidth (SLA)だけ。ManualとBest QualityはSLAの合否を見ない(Manualは回線の生死だけ、Best Qualityは遅延などの実測値が最良の回線を選ぶ)。
- Microsoft 365のブレイクアウトは、ISDBの
Microsoft-Office365だけではExchange OnlineとTeamsが漏れる。 - 機種はファイアウォールスループットではなくThreat Protectionスループットで選ぶ(50Gはファイアウォール5Gbpsに対しThreat Protection 1.1Gbps)。
- FortiOS 8.0.0で回線ごとの月間通信量クォータ、8.0.1でヘルスチェックのMTU検知が加わった。版ごとの判断はFortiOS 8.0の新機能とアップグレード判断で扱っている。
FortiGate SD-WANを構成する4階層|ゾーン・メンバー・SLA・ルール
FortiGateのSD-WANは下から積み上がる4階層です。この対応を先に押さえると、GUIのどの画面が何を設定しているのかが一度で分かります。
| 階層 | 役割 | CLI | GUIの場所 |
|---|---|---|---|
| ゾーン | メンバーの論理グループ | config zone | SD-WAN > SD-WANゾーン |
| メンバー | SD-WANに入れる回線 | config members | SD-WAN > SD-WANゾーン |
| パフォーマンスSLA | 回線品質の実測と判定 | config health-check | SD-WAN > パフォーマンスSLA |
| SD-WANルール | 通信ごとの経路選択 | config service | SD-WAN > SD-WANルール |
メンバーにできるのは物理ポートだけではありません。FortiOS 7.6.7の管理ガイドは、VLANインターフェース、LAG、IPsecトンネル、GREトンネル、FortiExtenderのインターフェースも挙げています。回線(アンダーレイ)と拠点間トンネル(オーバーレイ)は別ゾーンに分けると、ポリシーとルールを用途別に書けます。両者の関係はオーバーレイネットワークの仕組みとアンダーレイとの違いで整理しています。
ファイアウォールポリシーはこの4階層の上に乗ります。個々のメンバーはポリシーで直接使えないので、宛先インターフェースにはゾーンを指定します。ポリシーを回線の本数分だけ複製する必要はありません。
SD-WANの設定手順|メンバー登録からSLA・ルール・CLI確認まで(FortiOS 7.6系)
メンバー登録の前提|既存参照の削除と7.6.5以降の出荷時設定
GUI:ネットワーク > SD-WAN > SD-WANゾーン。インターフェースをメンバーに追加しようとして拒否される場合、そのインターフェースはスタティックルートかファイアウォールポリシーから参照されています。wan1に既定ルート(0.0.0.0/0)が向いたままではメンバーにできません。参照を削除してからメンバーに追加し、そのあとでSD-WANゾーン宛の既定ルートを引き直します。参照を消した瞬間に通信が切れるので、リモートから作業するならコンソール経路を確保してから始めます。
例外があります。FortiOS 7.6.5以降、WANポートを2つ持つ一部の機種は、工場出荷時の設定でwan1・wan2がDHCPになり、ゾーン「sd-wan」のメンバーに入っています。ヘルスチェック「Default_Ping」(宛先1.1.1.1と9.9.9.9)と、lanからsd-wanへの既定ポリシーも作成済みです。この機種では参照の削除は不要で、既存のゾーン名が virtual-wan-link ではなく sd-wan になる点だけ注意します。ネットで拾ったCLI例のゾーン名をそのまま貼ると、存在しないゾーンを参照してエラーになります。
config system sdwan
set status enable
config zone
edit "virtual-wan-link"
next
end
config members
edit 1
set interface "wan1"
set zone "virtual-wan-link"
set gateway 192.168.1.1
next
edit 2
set interface "wan2"
set zone "virtual-wan-link"
set gateway 192.168.2.1
next
end
end
固定IPの回線は gateway(回線側の次ホップ)を必ず入れます。DHCPで既定ゲートウェイを受け取っている回線は、GUIでこの欄が自動で埋まります。コスト(cost、既定0)はLowest Cost (SLA)で使う値で、小さいほど優先されます。
パフォーマンスSLAの既定値の落とし穴と実測ベースのしきい値設計
GUI:ネットワーク > SD-WAN > パフォーマンスSLA。パフォーマンスSLAは、各メンバー経由でプローブを送り、回線の品質を測る仕組みです。プローブ先のサーバは2つまで指定でき、2つ指定すると両方に届かないときだけ失敗と判定されます。片方のサーバの障害で回線をDeadにしないよう、運営者の異なるサーバを2つ指定します。
config system sdwan
config health-check
edit "HC-Internet"
set server "1.1.1.1" "8.8.8.8"
set protocol ping
set interval 500
set failtime 5
set recoverytime 5
set members 1 2
config sla
edit 1
set latency-threshold 100
set jitter-threshold 30
set packetloss-threshold 2
next
end
next
end
end
既定値が厳しすぎます。CLIリファレンスでは、7.6も8.0もレイテンシ5ms、ジッター5ms、パケットロス0%が既定です。5msは、モバイル回線や遠いプローブ先ではまず超え、光回線でもプローブ先によっては平常時から超える値です。既定のまま有効にすると、回線によってはSLA違反が常態化し、ルールが期待どおりに動きません。平常時のRTTとジッターを数日測り、そこに許容できる劣化幅を足した値(上の例ではレイテンシ100ms、ジッター30ms、ロス2%)を先に決めてから入れます。遅延の目安と原因の切り分けはレイテンシーの目安と改善方法にまとめています。
測り方にも癖があります。7.6.7の管理ガイド(SD-WAN transition timers)によると、パケットロスは直近100プローブの固定窓で計算され、遅延とジッターは probe-count(既定30プローブ)の移動窓で計算されます。間隔500msなら、ロス率は直近50秒の値です。しきい値2%は「100回中2回落ちたら違反」を意味し、瞬断1回では違反になりません。逆に既定の0%は1回落ちただけで違反になります。
切替までの時間は次の式で決まります。
| 状態の遷移 | 計算式 | 既定値での時間 |
|---|---|---|
| Alive → Dead | failtime × interval | 5 × 500ms = 2.5秒 |
| Dead → Alive | recoverytime × interval | 5 × 500ms = 2.5秒 |
| In-SLA → Out-of-SLA | failtime × interval | 2.5秒 |
| Out-of-SLA → In-SLA | 待ち時間なし | しきい値を下回った時点 |
回線の断と復旧が繰り返されて経路が行ったり来たりするなら、recoverytime を大きくしてDeadからAliveへの戻りを遅らせます。7.6.4以降の recoverytime が遅らせるのはこの判定だけで、SLA違反からの戻り(Out-of-SLAからIn-SLA)には効きません。しきい値の付近で揺れる回線は、しきい値自体に余裕を持たせて抑えます。同じガイドの例はinterval 2000ms・recoverytime 60で、復旧判定に120秒かけています。
プローブモード3種とプロトコルの選択
プローブの送り方は、Performance SLA overviewによると active・passive・prefer passive の3つです。
| モード | 測り方 | 必要な設定 |
|---|---|---|
| active | プローブを送って測る | プロトコルとサーバ |
| passive | 実通信のTCPセッションから測る | ポリシーで passive-wan-health-measurement |
| prefer passive | 通信があれば実通信、3分間無ければプローブ | 上の両方 |
従量課金のモバイル回線ならプローブの通信量を減らせるprefer passive、それ以外はactiveで十分です。ただし、passiveとprefer passiveで要るポリシー側の passive-wan-health-measurement を有効にすると、そのポリシーではNPへのオフロード(auto-asic-offload)が無効になります(Passive WAN health measurement)。プロトコルはGUIで選べるのがping・HTTP・DNSの3つで、CLIではTCPエコー、UDPエコー、HTTPS、TWAMP、TCP接続なども指定できます。SaaS宛ての応答時間を見たいならHTTPに切り替えます。ただし、プロトコルをHTTPかHTTPSにするとチェック間隔は自動で120,000ms(2分)に引き上げられ、failtime 5のままならDead判定まで10分かかります。回線断の検知にはpingのヘルスチェックを別に残します。
SD-WANルールの評価順とストラテジー4種の使い分け
GUI:ネットワーク > SD-WAN > SD-WANルール。ルールは上から順に評価され、最初に一致したルールが使われます。どれにも一致しない通信は暗黙のルール(既定のロードバランスはsource-ip-based)に落ちます。ストラテジーは4種類で、SLAの合否を見るかどうかが最大の違いです。
| ストラテジー | 選択ロジック | SLA状態 | 向いている通信 |
|---|---|---|---|
| Manual | 指定した優先順で固定 | 見ない | 経路を固定したい基幹通信 |
| Best Quality | 指標(遅延など)が最良の回線 | 見ない | 音声・映像 |
| Lowest Cost (SLA) | SLAを満たす回線のうち最低コスト | 見る | 一般通信・回線費の削減 |
| Maximize Bandwidth (SLA) | SLAを満たす全回線へ分散 | 見る | 大量転送 |
前出のtransition timersの節は「ManualとBest QualityのルールはSLA状態(In-SLA/Out-of-SLA)を考慮しない」と明記しています。Best Qualityは遅延などの実測値(link-cost-factor)を比べて最良の回線を選び、先に設定したメンバーに既定で10%の優位(link-cost-threshold)を与えます。「SLAを割ったら予備回線へ逃がす」設計なら、選ぶのはLowest Cost (SLA)です。品質が保たれている限り安い回線を使い、割ったら専用線に逃がす動きが1つのルールで書けます。
SD-WANゾーン宛のスタティックルートとポリシーの書き換え
メンバー登録が終わったら、SD-WANゾーン宛の既定ルートを入れます。ゲートウェイはメンバー側で定義済みなので、ルートはゾーンを指すだけです。FortiOS 6.2の解説によく出てくる set virtual-wan-link enable は、7.6では使いません。
config router static
edit 1
set dst 0.0.0.0 0.0.0.0
set distance 1
set sdwan-zone "virtual-wan-link"
next
end
ファイアウォールポリシーは、送信元をinternal、宛先インターフェースをSD-WANゾーンにします。
設定直後の動作確認に使うCLI診断コマンド3種
GUIの緑色表示だけで判断せず、CLIで実測値とルールの適用結果を見ます。
# 各メンバーの遅延・ジッター・ロスとSLAの判定
diagnose sys sdwan health-check
# SD-WANルールがどのメンバーを選んだか
diagnose sys sdwan service
# メンバーの状態(up/down、優先度)
diagnose sys sdwan member
health-check でパケットロスが100%なら、プローブ先の障害より先に固定IP回線のgateway設定漏れを疑います。SLAは満たしているのに想定と違う回線に流れる場合は、service の出力で一致したルールIDを確認します。上位のルールの条件が広いと、下位のルールにはそもそも到達しません。
ローカルブレイクアウトの設定|Microsoft 365を拠点から直接出す
ローカルブレイクアウトは、クラウドサービス宛ての通信をデータセンター経由で折り返さず、拠点のFortiGateから直接インターネットへ出す設計です。Microsoft 365のようにセッション数が多く遅延に敏感なサービスで効果が出ます。宛先の指定方法はISDBとアプリケーションの2通りあり、仕組みが違います。
ISDB(Internet Service)を宛先にするルールとMicrosoft 365のエントリ
ISDBはアプリケーション識別ではなく、サービスごとの宛先IPレンジとポートの集合です。FortiGuardから更新が配信されるので、Microsoft 365の接続先IPが変わってもリストを手で直す必要がありません。
config system sdwan
config service
edit 1
set name "M365-Breakout"
set mode sla
set internet-service enable
set internet-service-name "Microsoft-Office365" "Microsoft-Outlook" "Microsoft-Skype_Teams"
config sla
edit "HC-Internet"
set id 1
next
end
set priority-members 1
next
end
end
エントリの範囲に注意します。FortinetのTechnical Tip(Microsoft Office 365のISDBグループの違い)によると、Microsoft-Office365 が含むのは「SharePoint Online and OneDrive for Business」と「Microsoft 365 Common and Office Online」の範囲だけです。Exchange Onlineは Microsoft-Outlook、Teamsは Microsoft-Skype_Teams に分かれています。Microsoft-Office365 だけを指定すると、メールと会議がブレイクアウトされずに本社経由のまま残ります。Microsoftが「Optimize」に分類した遅延に敏感な宛先だけを直接出したいなら、Microsoft-Office365.Published.Optimize を使います。
アプリケーション指定のルール|アプリケーション制御が前提
宛先に「アプリケーション」を指定するルールには、7.6.7の管理ガイド(Application steering using SD-WAN rules)が挙げる前提が3つあります。
- 既定ではSD-WANルールでアプリケーションを選べない。
config system globalでset gui-app-detection-sdwan enableにする。 - ファイアウォールポリシーでアプリケーション制御を有効にしていないと動かない。
- 最初のセッションはどのルールにも一致しない。IPSエンジンが識別したあとで宛先IP・ポート・プロトコルの組が学習され、次のセッションから一致する。学習エントリは8時間ヒットが無いと消える。
宛先IPが多いサービスでは、まだ学習していないIP宛ての通信が想定外のルールに流れます。ISDBにあるサービスはISDBで指定し、アプリケーション指定はISDBに無いサービスやカテゴリ単位で振りたい場合に限ります。暗号化された通信の識別にはSSLインスペクションが要る場合があり、その副作用はFortiGateのSSL検査とHSTSでアクセスできない問題で扱っています。
どちらの方法でも、SD-WANルールがするのは経路選択だけです。直接出す通信は本社の検査装置を通らなくなるので、FortiGate側でIPS・アプリケーション制御を効かせるポリシーを必ず併せて用意します。
回線冗長とフェイルオーバー|切り替わらないときに見る場所
「回線が落ちたのに切り替わらない」ケースの多くは、ONUとのリンクは上がったままISP側で通信だけが止まっている状態です。リンクダウンが起きないのでルートも残ります。パフォーマンスSLAはプローブの到達性で回線の生死を判定するためにあります。切り替わらないときは次の順で確認します。
- ヘルスチェックにメンバーが入っているか(
set membersの指定漏れ)。入っていないメンバーは監視対象外のまま生き続ける。 - ストラテジーがManualではないか。Manualは回線がDeadになるまで切り替わらない。Best Qualityは実測値が最良の回線へ移るが、SLAのしきい値は見ず、先に設定したメンバーには既定で10%の優位(
link-cost-threshold)が付くので、わずかな劣化では移らない。 - ルールが参照するSLAのIDと、health-check側のSLAのIDが一致しているか。
- プローブ先が両回線から到達できるか。同じサーバ1台に頼ると、そのサーバの障害で両回線が同時にDead判定になる。
拠点間VPNを冗長化するなら、回線ごとにIPsecトンネルを張って両方をSD-WANメンバーにし、トンネル単位でSLAを測ります。多拠点のハブ&スポークでは、スポーク同士の通信が出たときだけショートカットトンネルを張るADVPNを併用します。拠点とクラウドのVPCをIPsecで結ぶ場合も考え方は同じで、クラウド側の設計から相談したいときはAWS・Google Cloud・Azureのインフラ構築支援で対応しています。
FortiOS 7.6.3以降・8.0で変わった設計前提
日本語で読めるFortiGate SD-WANの設定情報は、Fortinet公式の設定ガイドPDF(FortiOS 7.2、2022年8月版)を含めて7.4以前のものが中心です。4階層の考え方は変わっていませんが、その後に拠点設計へ直接響く変更が入っています。版の現況は、7.6系が7.6.7、8.0系が8.0.1(リリースノート初版2026年9月15日、build 0245)です。
SSL-VPNトンネルモード廃止(7.6.3)
FortiOS 7.6.3のリリースノートのとおり、7.6.3でSSL-VPNトンネルモードが廃止され、GUIからもCLIからも消えました。代わりはTCP 443でも張れるIPsec VPNですが、設定は自動で移行されないので、アップグレード前に移しておかないとSSL-VPNのリモートアクセスがその時点で使えなくなります。同じ7.6.3から、旧SSL-VPN WebモードはAgentless VPNに改称され、メモリ2GBの一部機種では使えなくなりました。対象は7.6.7のリリースノートで40F・50G・60F・61F・70G・90G/91Gの各シリーズ(FGR-60Fは2GB版のみ)です。どちらも8.0で始まった変更ではありません。アップグレード全体の判断はFortiOS 8.0の新機能とアップグレード判断に任せます。
回線ごとの月間通信量クォータ(8.0.0)
上限付きのモバイル回線を常用の1本として使う拠点で効くのが、8.0.0で追加された月間通信量クォータです。メンバーごとに上限(GB単位)と課金の起算日を持たせ、上限を超えたらそのメンバーのコストや重みを自動で変えて、ほかの回線へ通信を逃がします。
config system sdwan
config members
edit 2
set quota-limit 50
set billing-start-day 1
set overage enable
set overage-cost 10
next
end
end
ガイドの例では、2GBを超えた回線のコストを10に上げて残りの期間を別回線へ寄せ、次の起算日にクォータとコストが戻ります。消費量は diagnose sys sdwan bill member 2 で確認します。7.6系にはこの機能が無いので、容量制限のある回線を負荷分散や優先側に入れている拠点では、8.0へ上げる理由の1つになります。
ヘルスチェックのMTU検知(8.0.1)
ICMPのヘルスチェックは小さなパケットを使うため、経路のMTUが小さくても「Alive」と判定されます。その裏で、大きなパケットの実通信だけが落ちる、という障害が起きます。8.0.1から、pingのヘルスチェックにもパケットサイズ(packet-size、0〜10000バイト)を指定でき、probe-dont-fragment enable でDFビットを立てられるようになりました。8.0.0まではパケットサイズを指定できるのはTWAMPだけで、範囲も124〜1024バイトでした。
PPPoEはヘッダの分だけMTUが小さくなり、RFC 2516はMRUを1492より大きく交渉してはならないと定めています。PPPoE回線と光回線のIPoEを混在させる拠点では、DFビット付きのプローブでパケットサイズを1つずつ上げ、Aliveを保てた最大の値に20バイト(IPv4ヘッダ)を足した値を実効MTUとして記録しておくと、切替後にだけ大きな通信が落ちる事故を事前に見つけられます。
SD-WAN機器としてのFortiGate選定|機種とライセンス
SD-WAN専用機が不要な理由と既存FortiGateの流用条件
FortinetのOrdering Guide(Secure SD-WAN)のFAQは、SD-WANは全FortiGateモデルで追加費用なしに有効にできると答えています。すでに設置しているFortiGateが、設定を変えるだけでSD-WAN機器になります。UTMとSD-WANが1台に同居するので、拠点に筐体・電源・保守契約が増えません。UTMとファイアウォールの違いから整理したい場合はUTMの機能とファイアウォールとの違いを参照してください。
流用できるかどうかは、ブレイクアウトさせる通信に検査をかけた状態の性能で決まります。カタログのファイアウォールスループットは検査なしの上限値です。
機種帯ごとのThreat Protectionスループット(2026年10月版)
Fortinet Product Matrix(2026年10月版)のエントリー帯の数値です。
| 機種 | Firewall(1518byte) | Threat Protection | IPsec VPN(512byte) |
|---|---|---|---|
| FG/FWF-50G | 5Gbps | 1.1Gbps | 4.5Gbps |
| FG-60F | 10Gbps | 700Mbps | 6.5Gbps |
| FG/FWF-70G | 10Gbps | 1.3Gbps | 7.1Gbps |
| FG-90G | 28Gbps | 2.2Gbps | 25Gbps |
50Gはファイアウォール5Gbpsに対し、Threat Protectionは1.1Gbpsで約4.5分の1です。1Gbpsの光回線を2本束ねる拠点で全通信を検査するなら、50Gと70Gでは足りず90Gの帯になります。60FはファイアウォールでGシリーズの50Gを上回る一方、Threat Protectionは50Gより低い点も、置き換え時の判断材料になります。拠点の実トラフィックのうち検査対象になる量を先に見積もり、その値で機種を決めます。
ライセンス|FortiCareに含まれるものとFortiGuardが要るもの
経路制御はライセンス不要で、ブレイクアウトに使うISDBとアプリケーション制御のシグネチャもFortiCareの保守契約に含まれます(7.6.7の管理ガイド FortiGuard節)。有償のFortiGuardサービスが要るのは、ブレイクアウト通信を検査するIPS・アンチウイルス・Webフィルタの側です。
運用ツールまで含めて買うなら、2026年のサービスブリーフ(SD-WAN and SASE Services Bundles)が案内しているSD-WAN Service Bundleが調達単位になります。
| SKU | 対象 | 価格の目安 |
|---|---|---|
| 1329 | FortiGate 6xG以上・FortiSASEユーザー付き | 本体定価の50% |
| 1337 | 6xF以下とEシリーズ | 本体定価の50% |
| 1387/1389(アドオン) | UTPなどのバンドル購入済み | 本体定価の35% |
中身はFortiGuard SLA Databaseや速度テストを含む監視サービス、Overlay-as-a-Service、SASE接続などで、1329/1337はFortiCare Premiumも含みます。拠点が少なく、オーバーレイの構築をFortiOS 7.2.4以降に標準で入っているFabric Overlay Orchestratorで済ませるなら、バンドルは必須ではありません。
FortiGateを選ぶ基準と、選ぶべきでない場面
FortiGateのSD-WANが有利なのは、拠点にUTMを置く前提があり、検査とWANの経路制御を1台にまとめたい場合です。2024年のGartner Magic Quadrant for SD-WANでは5年連続のリーダーです(SD-WAN単独のMQは2024年9月30日公開の版が最新)。
次の条件に当てはまるなら、FortiGate SD-WANは選びません。
- 回線・SD-WAN・運用をまとめて外部に任せたい:キャリアのマネージドSD-WANのほうが運用要員を置かずに済む。FortiGateはSLAとルールの設計を自社か保守ベンダーが持つ前提の製品。
- 拠点にハードウェアを置きたくない:クラウド側で完結させるなら、SASE型に寄せるほうが素直。考え方はSASEの構成要素とゼロトラスト・SSEとの違いで整理している。
- 拠点間トンネルの片端が他社機のまま:ADVPNは両端がFortiGateであることが前提で、片端が他社機の区間は通常のIPsecとして組むことになる。
インターネットに面する機器である以上、脆弱性対応の運用も前提です。FortiOSでは悪用済みの脆弱性が繰り返し公表されており、拠点から直接インターネットへ出す設計はパッチ適用の体制とセットで考えます。直近の悪用状況はFortiGateの悪用済みCVE一覧と影響確認・修正版・回避策で追っています。
よくある質問
FortiGateのSD-WANに追加のライセンスは必要ですか?
経路制御は全モデルで追加費用なしに使えます。ブレイクアウトに使うISDBとアプリケーション制御のシグネチャもFortiCareの保守契約に含まれます。有償なのは、ブレイクアウト通信を検査するIPSやアンチウイルスなどのFortiGuardサービスと、監視・オーバーレイ管理をまとめたSD-WAN Service Bundleです。
SD-WANのインターフェースメンバーに追加できないのはなぜですか?
そのインターフェースがスタティックルートかファイアウォールポリシーから参照されているためです。wan1に向いた既定ルートや、wan1を宛先にしたポリシーを削除してからメンバーに追加します。リモート作業ではコンソール経路を確保しておきます。FortiOS 7.6.5以降の一部の2WANポート機は、出荷時からゾーン「sd-wan」にwan1・wan2が入っているため、この作業は要りません。
回線が劣化してもフェイルオーバーしません。どこを見ればよいですか?
ストラテジーがManualなら、回線がDeadになるまで切り替わりません。Best Qualityは実測値が最良の回線を選びますが、SLAのしきい値は見ません。しきい値を割ったら切り替えたいならLowest Cost (SLA)にします。そのうえで diagnose sys sdwan health-check で対象メンバーが監視されているか、SLAのIDがルールとhealth-checkで一致しているかを見ます。
パフォーマンスSLAのしきい値は何を基準に決めますか?
既定はレイテンシ5ms・ジッター5ms・パケットロス0%ですが、回線とプローブ先によっては平常時からレイテンシ5msを超えます。各回線の平常時のRTTとジッターを数日測り、許容できる劣化幅を足した値にします。パケットロスは直近100プローブで計算されるので、2%なら100回中2回の欠落で違反です。
FortiGateでMicrosoft 365をローカルブレイクアウトするには、何を宛先に指定しますか?
SD-WANルールの宛先にISDB(Internet Service)を指定します。Microsoft-Office365 はSharePoint・OneDriveと共通の宛先だけなので、Exchange Online用の Microsoft-Outlook とTeams用の Microsoft-Skype_Teams も並べます。遅延に敏感な宛先だけを出すなら Microsoft-Office365.Published.Optimize を使います。直接出す通信にもIPSなどの検査をかけるポリシーを併せて用意します。