Fortigate IPSEC Aggregate + OSPF + SDWAN 實作

參考資料 

 https://docs.fortinet.com/document/fortigate/6.2.16/cookbook/25967/equal-cost-multi-path 

 https://docs.fortinet.com/document/fortigate/6.4.0/administration-guide/779544/ipsec-aggregate-for-redundancy-and-traffic-load-balancing 

 

 前言 

 延續前一篇技術分享 Fortigate IPSEC + OSPF + SDWAN 實作 ，在該篇中OSPF不但能自動交換路由，同時也能 Fail Over 與 Load Balance 的特性，在內部交換與上網時的彈性線路切換，這在Fortigate上稱為 ECMP 的機制 (Equal-Cost Multi-Path)，但在Fortigate中還有另一個方式可以做到 IPSEC Fail Over 與 Load Balance 的功能，就是所謂的 IPSEC Aggregate ，此篇帶大家來看看怎麼搞，並分析其優劣。 

 

 環境說明 

 

 設計概念： 三個Site透過 IPSEC Aggregate +OSPF+SDWAN 來達成多線路OSPF動態路由，任一條線路故障時可透過其他線路接續連線，並透過SDWAN來監測線路品質狀況，同時由於資訊安全控管的原則希望能統一由同一個Gateway進出。 

 

 Firmware Ver. ：   Fortigate-VM 7.0.15 

 

 

 

 

 WAN IP 

 LAN Subnets 

 WAN IPSEC IP 

 

 

 SiteA 

 

 WAN1  10.1.1.1 

 WAN2  10.1.2.1 

 Port4  (to Internet) 

 

 

 192.168.11.254/24 

 192.168.12.254/24 

 192.168.13.254/24 

 

 

 AtoB   172.17.1.1 

 AtoC   172.17.1.6 

 

 

 

 SiteB 

 

 WAN1  10.1.1.2 

 WAN2  10.1.2.2 

 

 

 192.168.21.254/24 

 192.168.22.254/24 

 192.168.23.254/24 

 

 

 BtoA   172.17.1.2 

 BtoC   172.17.1.3 

 

 

 

 SiteC 

 

 WAN1  10.1.1.3 

 WAN2  10.1.2.3 

 

 

 192.168.31.254/24 

 192.168.32.254/24 

 192.168.33.254/24 

 

 

 CtoB   172.17.1.4 

 CtoA   172.17.1.5 

 

 

 

 

 

 

 

 設定過程 

 我們直接接續前一篇的設定繼續做，有問題的人請參照前一篇技術分享 Fortigate IPSEC + OSPF + SDWAN 實作 。 

 ※ 以下設定皆以一台 SiteC 為範例，請對照該台設定相關對應設定至 SiteB & SiteA 。 

 移除 SD-WAN IPSEC設定 

 Delete SD-WAN Performance SLA 

 

 Delete SD-WAN Members 

 

 移除 OSPF IPSEC設定 

 Delete IPSEC Interface，完成後 要Apply !!   (鍵人我不知道忘了多少次 ......) 

 

 建立IPSEC Aggregate 

 在Console輸入下列指令 

 config vpn ipsec phase2-interface 

edit C1toA1 

set auto-negotiate enable 

next

edit C1toB1 

set auto-negotiate enable 

next

edit C2toA2 

set auto-negotiate enable 

next

edit C2toB2 

set auto-negotiate enable 

end

config vpn ipsec phase1-interface 

edit C1toA1 

set aggregate-member enable 

next

edit C1toB1 

set aggregate-member enable 

next

edit C2toA2 

set aggregate-member enable 

next

edit C2toB2 

set aggregate-member enable 

end 

 

 

 VPN => IPSEC Turnnels => Create New => IPSEC Aggregate 

 

 建立 Aggregate，名稱取為 CtoA ，將 C1toA1 、 C2toA2 選起來 

 

 建立第二個 Aggregate CtoB 如法炮製 

 

 完成後如下圖 

 

 設定 IPSEC Aggregate Interface IP 

 完成Aggregate後發現，IPSEC Interface的IP都被移除了，把它們設回去 

 

 

 

 完成如下圖 

 

 設定OSPF Interface 

 

 

 完成如下圖，記得 要Apply !!   (鍵人我不知道忘了多少次 ...... Again ...... ) 

 

 設定SD-WAN 

 新增 SD-WAN Member 

 

 把 CtoA 、 CtoB 加入 OSPF_SDWAN Zone 

 

 

 完成如下圖 

 

 重建 SD-WAN Performance SLA 

 

 

 Performance SLA 完成如下圖 

 

 設定至此全部完成 

 

 ※  以防有人忘記了，在此我們沒有建立Firewall Policy的原因是上一篇我們已經制定好了 

 路由的部分全部交由OSPF處理， SiteB 、 SiteC 請不要設定任何Static Route進入SD-WAN。 

 

 

 狀態確認 

 OSPF 狀態 

 get router info ospf neighbor

get router info routing-table ospf 

 

 

 get router info ospf route 

 

 

 get router info routing-table all 

 

 

 

 IPSEC 狀態 

 

 

 

 

 ※ 比較過後，是不是看到流量分配的比之前更平均了 ? 

 

 

 連線測試 

 

 從 SiteC PC 連續Ping 8.8.8.8，透過Sniffer可知道是走 CtoA 

 

 將 CtoA 斷線，流量改走  CtoB 

 

 將 CtoA 恢復，流量又回到 CtoA 

 

 有此可證明Fail Over正常運作 

 

 Pros and Cons 

 所以，一路看下來，整體設定變得更簡潔、流量分配更平均，這樣設定應該是更好的選擇 ...... 吧 ? 

 讓我們來看看 IPSEC Aggregate的問題 

 問題1 

 回到上面的Fail Over測試，其實鍵人我不是只單純做了 CtoA 斷線測試，我其實是優先做 C1toA1 的斷線測試 

 

 

 看到了嗎 ? IPSEC Aggregate下，因為IPSEC斷線偵測比較慢，所以Aggregate還是很盡責地將封包分給兩條IPSEC所以會導致掉封包，等到IPSEC斷乾淨了之後才恢復順暢(如下圖) 

 

 你要說這個問題會很嚴重嗎 ? 也不見得，但是相較於沒有Aggregate以OSPF的切換機制來說是慢得多了 

 

 問題2 

 還記得我們最初為什麼要嘗試把OSPF去結合SD-WAN嗎 ? 就是因為要去監測OSPF線路品質是很困難的事情，所以雖然這樣設定SD-WAN完全沒有生效，但能藉由SD-WAN Performance SLA去監測OSPF線路品質還是一件很棒的事。 

 但一旦IPSEC Aggregate之後，SD-WAN Performace SLA監測機制就失去意義了，下圖是以 SiteA 的角度來看 C1toA1 斷線 

 

 看到了嗎 ? 上圖只知道 AtoC 有掉包，但卻無法直觀的得知是由於 C1toA1 斷線所造成的 

 再來請看下圖，這是實務上容易發生的，當整個 SiteC WAN1斷了的時候， C1toA1 & C1toB1 會同時斷線。 

 

 但在IPSEC還沒切乾淨網路還沒恢復通順的期間，SD-WAN Performance SLA有可能會變成這樣 

 

 對，就像上圖，顯示上 SiteA 、 SiteB 都斷了，但其實沒斷還能夠連線，偵測要等恢復通順才會回來，那這樣就大大的降低了利用SD-WAN Performance SLA監測的意義與正確性。 

 優勢 

 說完了問題，IPSEC Aggregate還是有優勢的地方 

 記得一開始前言的地方，我有提到沒有Aggregate的時候，Fortigate是透過OSPF ECMP的方式來達成Fail Over & Load Balance的，預設的ECMP Policy是基於 Source-IP-Base 去作分流，也就是如下圖 

 

 也因為ECMP是Source-IP-Base的關係，單一Source IP的 流量無法超過單一線路頻寬 ，假設你WAN1、WAN2皆為100M/100M，在ECMP 單一Source IP 最大流量就是100M。 

 但再看一次上面那張圖，反而佐證了透過IPSEC Aggregate Fortigate會去拆分封包分別丟入兩個IPSEC Turnnel 

 

 所以我們可以確定，在IPSEC Aggregate下，單一Source IP的流量 可以超過單一條線路頻寬 ，也就是WAN1、WAN2皆為100M/100M，在IPSEC Aggregate下單一Source IP 最大流量可達 200M。 

 優劣比較 

 綜合以上優劣，僅以下表呈現鍵人我的推薦程度，✅較為推薦，❌較不推薦 

 

 

 

 　 

 IPSEC 

 IPSEC Aggregate 

 

 

 動態路由 

 ✅ 

 ✅ 

 

 

 Fail Over 

 ✅ 

 ✅ 

 

 

 Load Balance 

 ✅ 

 ✅ 

 

 

 線路監控 

 ✅ 

 ❌ 

 

 

 即時切換 

 ✅ 

 ❌ 

 

 

 整合頻寬 

 ❌ 

 ✅ 

 

 

 

 如果是鍵人我，我會選擇 IPSEC 不作 Aggregate，這樣才能充分發揮OSPF的優勢 

 但在某些不是這麼Critical的Site，線路頻寬小且無法升速的區域 (比方說偏鄉地區)，IPSEC Aggregate依然是個不錯的選擇