【Fortigate】IPSec + SD-WAN機能の動作確認 FortiOS 7.0.3

前回は、FortiGate の SD-WAN 機能で WAN 回線を負荷分散する設定と動作を確認しました。実際の構成では、拠点からデータセンタへ IPsec で接続し、その IPsec トンネルを SD-WAN のメンバーにする使い方もよくあります。今回は、FortiGate から Azure へ2本の IPsec トンネルを張り、両方を SD-WAN のメンバーにして、性能の良い（レイテンシの低い）トンネルへ通信を振り分ける手順と動作を確認します。

検証構成

FortiGate は2本の ISP 回線（wan1 = port3、wan2 = port4）を持ち、それぞれから Azure の仮想ネットワークゲートウェイへ IPsec トンネル（VPN_ISP1、VPN_ISP2）を張ります。LAN 側（port2）の端末 10.0.200.100 から、Azure 上の仮想マシン 172.16.1.4 へ通信します。

事前設定

対向の VPN 接続先には Azure を使います。Azure との IPsec 接続の基本は、AzureとのVPN（IPSec）接続と動作確認 を参考にしてください。そちらの記事はトンネル1本でしたが、今回は2本張るので、Azure 側の構成をいくつか変えます。

Azure 仮想ネットワークゲートウェイの設定

仮想ネットワークゲートウェイは、アクティブ/アクティブ モードで作ります。アクティブ/アクティブでは、ゲートウェイの2つのインスタンスがそれぞれパブリック IP アドレスを持ち、両方が同時にトンネルを受けます。

あとは、1つ目のトンネルを作ったときと同じ手順で、ローカルネットワークゲートウェイと接続を作ります。ローカルネットワークゲートウェイは、FortiGate の2つの WAN（トンネルの接続元）に合わせて2つ作ります。

仮想ネットワークゲートウェイ ›› 接続 にも、ISP1 経由と ISP2 経由の2つの接続を登録します。この時点では、まだ FortiGate 側の設定がないので状態は「不明」です。

FortiGate の IPsec 設定

参考記事と同じ手順で、VPN ›› IPsec トンネル から2つのトンネル（VPN_ISP1、VPN_ISP2）を作ります。VPN_ISP1 は wan1（port3）、VPN_ISP2 は wan2（port4）にバインドし、それぞれの接続先を Azure ゲートウェイの2つのパブリック IP アドレスにします。この時点では、トンネルはまだダウンのままです。

赤のアイコンと「非アクティブ」は、トンネルがまだ確立していないことを表します。

IPsec 用の SD-WAN ゾーンを作る

2本のトンネルをメンバーにする SD-WAN ゾーンを作ります。ネットワーク ›› SD-WAN ›› SD-WANゾーン で 新規作成 ›› SD-WANゾーン をクリックし、virtual-wan-link-IPSec という名前で作ります。メンバーはあとで追加するので、ここでは空のままにします。

次に、新規作成 ›› SD-WANメンバー をクリックし、トンネルインタフェースをこのゾーンのメンバーにします。VPN_ISP1 を追加したら、VPN_ISP2 も同じように追加します。

しばらくすると、2本のトンネルがアップします。SD-WAN ゾーンの一覧で、virtual-wan-link-IPSec の下にトンネルインタフェースが登録されていることを確認できます。

緑のアイコンは、ゾーンとトンネルインタフェースがアップしていることを表します。virtual-wan-link と SASE は既定で用意されているゾーンで、今回は使いません。

スタティックルートを作る

VPN の対向先のサブネット 172.16.1.0/24 へのスタティックルートを作ります。出力インタフェースには、個々のトンネルではなく SD-WAN ゾーン virtual-wan-link-IPSec を指定します。

ファイアウォールポリシーを作る

LAN から SD-WAN ゾーン（virtual-wan-link-IPSec）へのファイアウォールポリシーを作ります。宛先の Azure_172.16 は、172.16.1.0/24 を登録したアドレスオブジェクトです。端末のアドレスのまま Azure へ届けるため、NAT は無効にします。

端末（10.0.200.100）から Azure 上の仮想マシン（172.16.1.4）へ ping を打ち、疎通を確認します。

C:\Users\（伏せています）>ping 172.16.1.4 Pinging 172.16.1.4 with 32 bytes of data:1Reply from 172.16.1.4: bytes=32 time=13ms TTL=127Reply from 172.16.1.4: bytes=32 time=13ms TTL=127Reply from 172.16.1.4: bytes=32 time=12ms TTL=127Reply from 172.16.1.4: bytes=32 time=13ms TTL=127 Ping statistics for 172.16.1.4:    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:    Minimum = 12ms, Maximum = 13ms, Average = 12ms

4回とも応答があり、IPsec 経由で端末と仮想マシンの間が通信できています。

SD-WAN ルール

ここまでで、SD-WAN ゾーンとポリシーを作り、IPsec 経由で端末と仮想マシンの間が疎通できるところまで確認できました。ここからは、パフォーマンス SLA で2本のトンネルの状態を監視し、性能の良いトンネルへ振り分ける SD-WAN ルールを作ります。

パフォーマンス SLA を作る

ヘルスチェックの宛先は、Azure 上の仮想マシン 172.16.1.4 にします。ネットワーク ›› SD-WAN ›› パフォーマンスSLA で 新規作成 をクリックします。

リンクステータスは既定値のままです。500ms ごとにチェックし、5回続けて失敗するとそのインタフェースを非アクティブと判断します。

登録はできましたが、172.16.1.4 へのヘルスチェックに応答がなく、どちらのトンネルもダウンのままです。

赤のアイコンは、ヘルスチェックが失敗していることを表します。端末からの ping は通るのに、ヘルスチェックが通らないのは、送信元のアドレスが違うためです。

パフォーマンス SLA のプローブは、FortiGate 自身が送信元になって送ります。トンネルインタフェースに IP アドレスを付けていない場合、プローブの送信元は LAN 側（10.0.200.0/24）のアドレスになりません。Azure 側は、ローカルネットワークゲートウェイのアドレス空間（10.0.200.0/24）宛ての通信だけをトンネルに戻すので、プローブへの応答が FortiGate に返ってきません。この事象と対処は、Fortinet のナレッジ Technical Tip: SD-WAN performance SLA for IPsec interface shows down にまとめられています。

対処として、SD-WAN メンバーごとにプローブの送信元アドレスを指定します。今回はトンネルが2本あるので、ループバックインタフェースを2つ作り、それぞれのトンネルの送信元にします。Azure 側では、その送信元への応答をトンネルに戻せるよう、ローカルネットワークゲートウェイのアドレス空間にループバックのアドレスを追加します。

ループバックインタフェースを作る

ISP1 用に 1.1.1.1/24、ISP2 用に 2.2.2.2/24 のループバックインタフェースを作ります。ネットワーク ›› インターフェース で 新規作成 ›› インターフェース をクリックします。

SD-WAN メンバーの送信元アドレスを指定する

CLI で、SD-WAN メンバーに送信元アドレスを指定します。show の結果から、edit 3 と edit 4 がトンネルインタフェースのメンバーだとわかります。

FG1

FG1 # config system sdwan
FG1 (sdwan) # config members 
FG1 (members) # show
config members
    edit 1
        set interface "port3"
    next
    edit 2
        set interface "port4"
    next
    edit 3
        set interface "VPN_ISP1"
        set zone "virtual-wan-link-IPSec"
    next
    edit 4
        set interface "VPN_ISP2"
        set zone "virtual-wan-link-IPSec"
    next
end
FG1 (members) # edit 3
FG1 (3) # set source 1.1.1.1
FG1 (3) # next
FG1 (members) # edit 4
FG1 (4) # set source 2.2.2.2
FG1 (4) # end
FG1 (sdwan) # end
FG1 #

Azure のローカルネットワークゲートウェイにアドレスを追加する

ヘルスチェックは、ISP1 側は 1.1.1.1、ISP2 側は 2.2.2.2 から届きます。Azure がこれらへの応答をトンネルに戻せるよう、ローカルネットワークゲートウェイの 構成 で、アドレス空間に 1.1.1.1/32 と 2.2.2.2/32 を追加して保存します。

パフォーマンス SLA の状態を確認する

ネットワーク ›› SD-WAN ›› パフォーマンスSLA で IPSec の状態を見ると、ヘルスチェックがアップしています。

緑のアイコンは、ヘルスチェックが成功していることを表します。このときのレイテンシは、VPN_ISP1 が 11.47ms、VPN_ISP2 が 13.71ms でした。

パケットをトレースすると、VPN_ISP1 と VPN_ISP2 のそれぞれから、ループバックのアドレスを送信元にして ICMP を送受信していることがわかります。

FG1

FG1 # dia sniffer packet any "host 172.16.1.4 and icmp" 4
Using Original Sniffing Mode
interfaces=[any]
filters=[host 172.16.1.4 and icmp]
0.599226 VPN_ISP1 out 1.1.1.1 -> 172.16.1.4: icmp: echo request
0.599266 VPN_ISP2 out 2.2.2.2 -> 172.16.1.4: icmp: echo request
0.610109 VPN_ISP1 in 172.16.1.4 -> 1.1.1.1: icmp: echo reply
0.612036 VPN_ISP2 in 172.16.1.4 -> 2.2.2.2: icmp: echo reply

SD-WAN ルールを作る

パフォーマンス SLA IPSec の結果から、最も性能の良いインタフェースを選ぶ SD-WAN ルールを作ります。ネットワーク ›› SD-WAN ›› SD-WANルール で 新規作成 をクリックします。

作ったルールを一覧で見ると、メンバーのうち VPN_ISP1 に選択中の印が付いています。レイテンシが低い VPN_ISP1 が、発信インタフェースとして選ばれています。

動作確認

端末（10.0.200.100）から Azure 上の仮想マシン（172.16.1.4）へ連続して ping を打ち、パケットをトレースします。

FG1

FG1 # dia sniffer packet any "host 172.16.1.4 and icmp and host 10.0.200.100" 4
Using Original Sniffing Mode
interfaces=[any]
filters=[host 172.16.1.4 and icmp and host 10.0.200.100]
1.394440 port2 in 10.0.200.100 -> 172.16.1.4: icmp: echo request
1.394464 VPN_ISP1 out 10.0.200.100 -> 172.16.1.4: icmp: echo request
1.406401 VPN_ISP2 in 172.16.1.4 -> 10.0.200.100: icmp: echo reply
1.406415 port2 out 172.16.1.4 -> 10.0.200.100: icmp: echo reply
2.450010 port2 in 10.0.200.100 -> 172.16.1.4: icmp: echo request
2.450032 VPN_ISP1 out 10.0.200.100 -> 172.16.1.4: icmp: echo request
2.462930 VPN_ISP2 in 172.16.1.4 -> 10.0.200.100: icmp: echo reply
2.462945 port2 out 172.16.1.4 -> 10.0.200.100: icmp: echo reply

ICMP echo request は、SD-WAN ルールで選ばれた VPN_ISP1（ISP1 側）から送られています。戻りの echo reply は VPN_ISP2（ISP2 側）から届いています。アクティブ/アクティブの Azure は、戻りの通信にどちらのトンネルを使うかを自分で決めるためです。今回は戻りの経路は制御していません。

では、ISP1 側の回線をダウンさせます。

FG1

FG1 # dia sniffer packet any "host 172.16.1.4 and icmp and host 10.0.200.100" 4
Using Original Sniffing Mode
interfaces=[any]
filters=[host 172.16.1.4 and icmp and host 10.0.200.100]
1.051686 port2 in 10.0.200.100 -> 172.16.1.4: icmp: echo request
1.051709 VPN_ISP1 out 10.0.200.100 -> 172.16.1.4: icmp: echo request
1.063551 VPN_ISP2 in 172.16.1.4 -> 10.0.200.100: icmp: echo reply
1.063563 port2 out 172.16.1.4 -> 10.0.200.100: icmp: echo reply
2.072118 port2 in 10.0.200.100 -> 172.16.1.4: icmp: echo request
2.072144 VPN_ISP1 out 10.0.200.100 -> 172.16.1.4: icmp: echo request
2.084252 VPN_ISP2 in 172.16.1.4 -> 10.0.200.100: icmp: echo reply
2.084267 port2 out 172.16.1.4 -> 10.0.200.100: icmp: echo reply
3.085930 port2 in 10.0.200.100 -> 172.16.1.4: icmp: echo request
3.085958 VPN_ISP1 out 10.0.200.100 -> 172.16.1.4: icmp: echo request
3.097661 VPN_ISP2 in 172.16.1.4 -> 10.0.200.100: icmp: echo reply
3.097675 port2 out 172.16.1.4 -> 10.0.200.100: icmp: echo reply
4.101497 port2 in 10.0.200.100 -> 172.16.1.4: icmp: echo request
4.101522 VPN_ISP1 out 10.0.200.100 -> 172.16.1.4: icmp: echo request
4.113638 VPN_ISP2 in 172.16.1.4 -> 10.0.200.100: icmp: echo reply
4.113652 port2 out 172.16.1.4 -> 10.0.200.100: icmp: echo reply
5.117265 port2 in 10.0.200.100 -> 172.16.1.4: icmp: echo request
5.117289 VPN_ISP1 out 10.0.200.100 -> 172.16.1.4: icmp: echo request
10.132916 port2 in 10.0.200.100 -> 172.16.1.4: icmp: echo request
10.132947 VPN_ISP2 out 10.0.200.100 -> 172.16.1.4: icmp: echo request
10.145373 VPN_ISP2 in 172.16.1.4 -> 10.0.200.100: icmp: echo reply
10.145390 port2 out 172.16.1.4 -> 10.0.200.100: icmp: echo reply
11.148546 port2 in 10.0.200.100 -> 172.16.1.4: icmp: echo request
11.148565 VPN_ISP2 out 10.0.200.100 -> 172.16.1.4: icmp: echo request
11.161286 VPN_ISP2 in 172.16.1.4 -> 10.0.200.100: icmp: echo reply
11.161296 port2 out 172.16.1.4 -> 10.0.200.100: icmp: echo reply

強調した2行が、VPN_ISP1 から VPN_ISP2 への切り替わりのポイントです。5.117 秒に VPN_ISP1 から送った echo request には応答がなく、次の request は 10.132 秒に VPN_ISP2 から送られ、応答も返っています。

この間、端末からの request そのものが出ていません。Windows の ping は、応答を既定で4秒待ってから次を送るので、端末は応答待ちをしていたと考えられます。失われた ping は1回分で、切り替えはこの約5秒の間に終わっています。SLA の設定は 500ms 間隔で5回失敗するとダウンと判断するので、検知にはおよそ2.5秒かかる計算です。

ネットワーク ›› SD-WAN ›› パフォーマンスSLA で IPSec の状態を見ると、VPN_ISP1 がダウンしています。

赤のアイコンの VPN_ISP1 はヘルスチェックが失敗し、緑の VPN_ISP2 だけが成功しています。ネットワーク ›› SD-WAN ›› SD-WANルール を見ると、発信インタフェースが VPN_ISP2 に変わっています。

うまくいかないとき

まとめ

2本の IPsec トンネルを SD-WAN ゾーンにまとめ、パフォーマンス SLA とベストクオリティのルールで、レイテンシの低いトンネルを選べました。ISP1 側を落とすと、失われた ping は1回で、通信は VPN_ISP2 に切り替わりました。設定した項目をまとめます。

関連記事：【Fortigate】SD-WAN機能（WAN回線分散）の動作確認／AzureとのVPN（IPSec）接続と動作確認／【Fortigate】WAN回線冗長（link-monitor設定）
その他の Fortigate の記事は Fortigate 設定まとめ から参照できます。