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

前回、SD-WAN機能によりWAN回線の負荷分散の設定と動作を確認しました。SD-WAN機能の基本的な説明は下記記事を参照ください。

  >> 参考記事 :  SD-WAN機能(WAN回線分散)の動作確認

実際のケースでは、拠点からデータセンタへIPSecで接続し、そのIPSecトンネルインタフェースをSD-WANインタフェースにするパターンもあるかと思います。

今回は、Fortigateから2本のIPSecトンネルを張り、それぞれをSD-WANインタフェースのメンバーとし、パフォーマンスの良いインタフェースへ通信を振り分ける手順と動作を確認していきます。

スポンサーリンク

事前設定

対向のVPN接続先は、Azureを使用します。AzureとのIPSec接続は、下記の記事を参考にしてください。

  >> 参考記事 :  AzureとのVPN(IPSec)接続と動作確認

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

参考記事では、1つのIPSecトンネルのみの接続でした。今回は、2つのIPSecトンネルを張るため、仮想ネットワークゲートウェイ の構成にて、 アクティブ/アクティブモードを使用します。

あとは、1つ目のトンネルを作成した手順と同様に、2つ目のトンネルを作成します。

ローカルネットワークゲートウェイもFortigateの2つのトンネル接続先として2つ作成します。

仮想ネットワークゲートウェイ >> 接続 もISP1経由とISP2経由の2つを登録します。

Fortigate IPSec設定

参考記事どおり、VPN >> IPSecトンネルより、2つのトンネル (VPN_ISP1VPN_ISP2)を作成します。まだ、トンネルはダウンのままです。

IPSec用のSD-WANゾーン作成

IPSecトンネル2つをメンバーとするSD-WANゾーンを作成します。ネットワーク >> SD-WAN >> SD-WANゾーン より新規作成 >>SD-WANゾーンをクリックします。

virtual-wan-link-IPSecという名前のSD-WANゾーンを作成します。

下記のとおり作成されます。このvirtual-wan-link-IPSecトンネルインタフェースをメンバ追加します。

ネットワーク >> SD-WAN >> SD-WANゾーン より新規作成 >>SD-WANメンバーをクリックします。

インタフェースでVPN_ISP1、SD-WANゾーンはvirtual-wan-link-IPSecを選択し、OKをクリックします。VPN_ISP2も同様に作成します。

しばらくすると、2つのトンネルがアップします。下記のとおり、SD-WANゾーンにトンネルインタフェースがメンバとして登録されていることが確認できます。

スタティックルート作成

VPN対向先のローカルサブネットである172.16.1.0/24向けのスタティックルートを作成します。出力インタフェースは、SD-WANゾーンであるvirtual-wan-link-IPSecです。

ネットワーク >> スタティックルートより、

ファイアウォールポリシー

LANからSDWANゾーン(virtual-wan-link-IPSec)向けのファイアウォールポリシーを作成します。宛先で指定しているAzure_172.16は、予め172.16.1.0/24のサブネットを登録したアドレスオブジェクトです。NATは無効化します。

端末(10.0.200.100)からAzure上の仮想マシン(172.16.1.4) へ疎通を確認します。

スポンサーリンク

SD-WANルール

上記にて、SD-WANゾーンとポリシーを作成して、IPSecで端末〜仮想マシン間が疎通できるところまで確認できました。

これからIPSecトンネルをSLAパフォーマンスにてヘルスチェックし、パフォーマンスの良いインターフェースへ振り分けるSD-WANルールを作成します。

IPSecトンネルのSLAパフォーマンスの設定

ヘルスチェック先は、Azure上の仮想マシンである172.16.1.4とします。

ネットワーク >> SD-WAN >> パフォーマンスSLAより新規作成をクリックします。

  • 名前:任意の名前 IPSecとします。
  • プローブモードアクティブを選択します。
  • プロトコルPing を選択します。
  • サーバ:ヘルスチェック先として、172.16.1.4 とします。
  • 参加インタフェース:指定を選択し、トンネルインタフェース(VPN_ISP1VPN_ISP2)を選択します。

下記のように登録されましたが、172.16.1.4向けのヘルスチェックの応答がないようで、ダウンのままです。

これは、下記のTIPSにあるとおり、Fortigate自身が送信元デバイスとして、ヘルスチェックを送信していることから、送信元アドレスがIPSec対象のローカルサブネットのインタフェースと異なることが原因となります。

  >> 参考記事 :  Technical Tip: SD-WAN performance SLA for IPsec interface shows down

The root cause of the issue is, for performance SLA monitor, FortiGate itself act as the source device and it will take the IPsec VPN outgoing interface (WAN) interface IP as source.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-SD-WAN-performance-SLA-for-IPsec-interface-shows/ta-p/191897

SD-WANメンバーの設定で、送信元アドレスを指定することで回避されると記載があります。

今回は、2つのトンネルを張っていることから、ループバックアドレスを2つ作成し、それぞれのトンネルの送信元として、指定してみます。

ループバックアドレスの作成

ISP1用に1.1.1.1/24 、ISP2用に2.2.2.2/24を作成します。

ネットワーク >> インタフェース >> 新規作成 >> インタフェースをクリックし、作成します。

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

TIPSにあるとおり、CLIにて送信元アドレスを指定します。edit3edit4がIPSecトンネルインタフェースであることが確認できます。

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 VPN側のローカルネットワークゲートウェイの追加

FortigateからISP1は1.1.1.1 、ISP2は2.2.2.2からIPSec接続があるため、Azure側もローカルネットワークゲートウェイに1.1.1.1と2.2.2.2を追加する必要があります。

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

ネットワーク >> SD-WAN >> パフォーマンスSLAよりIPSecのモニタを確認すると、ヘルスチェックがアップしています。

パケットをトレースすると、下記のとおり、VPN_ISP1VPN_ISP2のぞれぞれのインタフェースからICMPを送受信していることが確認できます。

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ルールの作成

IPSecのSLAパフォーマンスで、最もパフォーマンスの良いインタフェースを選択するよう、SD-WANルールを設定します。

ネットワーク >> SD-WAN >> SD-WANルールより新規作成

  • 名前:任意の名前。今回はIPSecとします。
  • 送信元アドレスall 
  • 宛先アドレスAzure_172.16(172.16.1.0/24のサブネットを登録したアドレスオブジェクト)
  • プロトコル番号ANY
  • 発信インタフェースベストクオリティを選択
  • 優先するインタフェース:IPSecトンネルインタフェース(VPN_ISP1VPN_ISP2)を選択
  • 計測されたSLA:IPSecを選択
  • クオリティ基準レイテンシを選択

下記のように登録されます。下記では、VPN_ISP1が最もパフォーマンスが良い(レイテンシが低い)インタフェースとして選出されています。

動作確認

端末(10.0.200.100)からAzure上の仮想マシン(172.16.1.4) へ連続Pingし、パケットをトレースします。

下記のように、ISP1側からICMP echoが送信されています。戻りのICMP replyは ISP2側から受信しています。(戻りは、Azure側の制御となるため、今回は考慮していません)

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

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

下記の黄枠がISP1→ISP2の切り替わりのポイントです。デバッグ上は約5秒間の通信断となります。

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

ネットワーク >> SD-WAN >> パフォーマンスSLAよりIPSecのモニタを確認すると、VPN_ISP1がダウンしています。

ネットワーク >> SD-WAN >> SD-WANルールよりSD-WANルールを確認すると、VPN_ISP2が発信インタフェースであることが確認できます。

コメント