動態路由
- Fortigate IPSEC + iBGP實作
- Fortigate IPSEC + OSPF + SDWAN 實作
- Fortigate IPSEC Aggregate + OSPF + SDWAN 實作
Fortigate IPSEC + iBGP實作
參考資料
https://docs.fortinet.com/document/fortigate/7.4.4/administration-guide/763341/basic-bgp-example
環境說明
Site A : Fortigate 60D Firmware v6.0.17
WAN IP : 10.1.1.101
LAN IP : 192.168.101.0/24、192.168.102.0/24、192.168.103.0/24
IPSEC IP : 172.17.10.101
Site B : Fortigate 60D Firmware v6.0.17
WAN IP : 10.1.1.201
LAN IP : 192.168.201.0/24、192.168.202.0/24、192.168.203.0/24
IPSEC IP : 172.17.10.101
設定步驟
預先設定
首先先將Site A、Site B的WAN、LAN Interface IP設定好，為了後面Policy設定方便我將LAN綁成一個Zone
建立IPSEC VPN
IP指向對方的WAN IP、Local & Remote Address 設定為 0.0.0.0/0
設定IPSEC介面IP
對應Site A、Site B的設定，設定其Interface IP Address、Remote IP，並允許Ping (方便偵錯)
順便檢查一下上一動建立IPSEC的Static Route與 Policy
檢查都ok的話，IPSEC應該就已經起來了
此時互相Ping對方的IPSEC Interface IP應該就會通了
設定iBGP
Site A、Site B 設定相同的AS，Router ID設定不同的ID，Neighbors設定對方的IPSEC IP，最後鍵入自己的LAN Subnets
至CLI設定BGP介面來源
<< Site A >>
config router bgp
config neighbor
edit 172.17.10.201
set update-source IPSEC
end
<< Site B >>
config router bgp
config neighbor
edit 172.17.10.101
set update-source IPSEC
end
確認一下BGP設定
show router bgp
確認Neighbors
get router info bgp neighbors
確認BGP路由
get router info bgp network
確認整體路由
get router info routing-table all
連線測試
從Site A Firewall測試ping Site B VLAN 3 Interface IP
將NB接到Site A LAN，Ping Site B VLAN 3 Interface IP
將NB接到Site B LAN，Ping Site B VLAN 2 Interface IP
結語
以上實作透過Fortigate IPSEC VPN來進行iBGP動態路由，不過通常一般企業內部其實鮮少會使用BGP來進行路由交換，僅在此紀錄一下設定與測試的過程，並提供有需要的朋友參考。
Fortigate IPSEC + OSPF + SDWAN 實作
參考資料
前言
上一篇分享了 Fortigate IPSEC + iBGP 的動態路由，但畢竟一般企業中鮮少使用BGP，大多反而是使用OSPF，OSPF不但能自動交換路由，同時也能 Fail Over 與 Load Balance，此篇實作帶大家一起來看看 Fortigate IPSEC + OSPF + SDWAN 有沒有搞頭。
環境說明
設計概念： 三個Site透過 IPSEC+OSPF+SDWAN 來達成多線路OSPF動態路由，任一條線路故障時可透過其他線路接續連線，並透過SDWAN來監測線路品質狀況，同時由於資訊安全控管的原則希望能統一由同一個Gateway進出。
Firmware Ver. ： Fortigate-VM 7.0.15
| WAN IP |
LAN Subnets |
WAN1 IPSEC IP |
WAN2 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 |
A1toB1 172.17.1.1 A1toC1 172.17.1.6 |
A2toB2 172.17.2.1 A2toC2 172.17.2.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 |
B1toA1 172.17.1.2 B1toC1 172.17.1.3 |
B2toA2 172.17.2.2 B2toC2 172.17.2.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 |
C1toB1 172.17.1.4 C1toA1 172.17.1.5 |
C2toB2 172.17.2.4 C2toA2 172.17.2.5 |
設定過程(1)
設定Interface
以下設定皆以一台SiteC為範例，請對照該台設定相關對應設定至SiteB，第一階段我們先忽略SDWAN，先把IPSEC+OSPF設起來。
先把 WAN1、WAN2、LAN Interface設定好如下圖
為了方便設定，我將 LAN Interface綁成一個Zone，並且不要Block內部流量互通
設定IPSEC
至 VPN => IPSEC 建立 WAN1 IPSEC VPN，我以 C1toB1 來命名
Remote IP設定SiteB WAN1 IP，指定Pre-shared Key
本地Interface就選剛剛做好的LAN Zone，Local & Remote Subnets 都鍵入 0.0.0.0/0
Wizard會建立一堆討厭的東西，晚一點砍掉
建立SiteC WAN2 IPSEC VPN C2toB2
建好兩條VPN之後，至Policy砍掉Wizard自動建立的Policy
至Static Route砍掉Wizard自動建立的路由
至Network Interface，來進行 C1toB1、C2toB2 Interface設定
如下圖設定自己(SiteC)與對方(SiteB)的預先定義IP，Netmask設定 /32，開啟Ping
設定完後如下圖
我們將兩個IPSEC VPN綁成一個Zone (VPN_Zone)，並且不要Block內部流量讓裡面介面能互通(後面會用到)
設定Firewall Policy
建立Firewall Policy，允許LAN Zone與VPN Zone互通，不要NAT
設定好後Firewall Policy如下圖
至此完成了SiteC IPSEC設定，※請依照上面步驟去完成SiteB IPSEC的步驟
當 SiteC、SiteB Firewall Policy設定完成後，你應該可以發現IPSEC Turnel已經起來了
如果還沒起來，可以透過IPSEC介面，點擊 Bring Up
從SiteC去Ping SiteB 的 IPSEC IP，已經可以Ping的到，但是SiteB的LAN Ping不到，這是正確的
下圖可知 IPSEC Interface 的路由已經起來了所以Ping的到，因為沒有LAN Subnet的路由所以Ping不到，這個部分就是要靠OSPF上場了。
設定OSPF
至 Network => OSPF，指定Router ID、Area ID、要自動交換路由的網段 ※(需要包括IPSEC介面的路由)
Interfaces將IPSEC介面加入，Network Type 選擇 "Point to Point"
※請依照上面步驟去完成SiteB OSPF設定
完成後至CLI Console，輸入下列指令可查詢OSPF Neighbor、OSPF路由
get router info ospf neighbor
get router info routing-table ospf
輸入下列指令顯示完整路由
get router info routing-table all
或者可由 Dashboard => Network => Routing，確認路由
連線測試
我們在SiteB放一台PC (192.168.21.4)、SiteC放一台PC (192.168.31.5)
Ping ok
Traceroute 確認路由
設定過程(2)
比照上述 SiteC <=> SiteB 設定過程，來完成 SiteA <=> SiteB、SiteC <=> SiteA 的設定。
設定IPSEC
設定IPSEC Turnel
設定Interface
設定IPSEC Interface IP、並把新增的IPSEC加入VPN_Zone
設定Firewall Policy
Firewall Policy由於一開始是由Zone來設定的，所以完全不需要調整
IPSEC應該就起來了
設定OSPF
將新增的IPSEC介面加入
完成後至CLI Console，查詢OSPF Neighbor、OSPF路由
get router info ospf neighbor
get router info routing-table ospf
輸入下列指令顯示OSPF路由詳細資訊
get router info ospf route
Fail Over測試
我測試的方式如下
1. 由SiteB PC連續Ping SiteC PC，先確定是走哪一條IPSEC
透過packet sniffer確認是由C1toB1過來的
2. 將C1toB1 IPSEC手動斷線，觀察是否會走另一條IPSEC
確認由C1toB1切到C2toB2
3. 將C2toB2再度手動斷線，觀察流量是否會透過SiteA過來
確認由C2toB2切到C1toA1，流量從SiteA過來了
如此一來就驗證了OSPF運作ok 👍
SDWAN設定過程
ok，OSPF運作ok了，那說好的SDWAN呢 ? 這邊哪來的SDWAN ?
別急，現在我們就來把VPN_Zone改接成SDWAN
把IPSEC從Zone移除
至Network => VPN_Zone將IPSEC移出Zone
設定SD-WAN Zone
Network => SD-WAN => Create New => SD-WAN Zone
在此建立一個OSPF_SDWAN的Zone
將剛剛移除Zone的四條IPSEC VPN新增至SD-WAN Member
到Interface也可以看到SD-WAN Zone
建立Firewall Policy
建立 LAN <=> SDWAN、SDWAN <=> LAN的 Firewall Policy，一樣皆不要做NAT。
在此要建立一條 SDWAN <=> SDWAN，使其IPSEC VPN可內部互通
OSPF設定
不需異動
用Console看一下OSPF Neighbor，看起來沒問題，路由也都有正確交換
設定SD-WAN Performance SLA
分別針對SiteB、SiteA設定線路SLA，檢查的對象就設為對方的Interface IP
Fail Over測試
再做一次Fail Over測試
1. 由SiteB PC連續Ping SiteC PC，先確定是走哪一條IPSEC
ok，目前是走 C1toB1
2. 將C1toB1 IPSEC手動斷線
流量改走C2toB2
3. 將C2toB2再度手動斷線
流量改走C2toA2
驗證了OSPF運作ok
統一上網出口
最後，我們來將 SiteA、SiteB、SiteC 設定為統一透過 SiteA 出去上網
設定SiteA Interface & SD-WAN
將SiteA Port4 接到Internet，設定SD-WAN Interface Gateway，並把Port4加入Default SD-WAN Zone
設定SiteA SD-WAN Rule
設定出Internet走Default SD-WAN Zone
設定SiteA Static Route
設定Default Route進Default SDWAN
設定SiteA OSPF Inject Static Route
設定SiteA Firewall Policy
設定 OSPF_SDWAN Zone、SiteA LAN 出Internet Firewall Policy，此處需開啟NAT
確認SiteA Default Route
確認一下上面設定進SDWAN的Static Route
get router info routing-table all
確認SiteC Default Route
可以發現OSPF自動生成了SiteC 的Default Route
到此，設定大功告成
來看一下 SiteC 的SDWAN Rule，沒有 !! 這是正確的
來看一下 SiteC 的Static Route，沒有 !! 這是正確的，因為路由我們全靠OSPF
※熟知SD-WAN設定的人應該知道※
SD-WAN設定至少要包含四個步驟
- SD-WAN線路設定
- SD-WAN Rule設定
- Static Route 指向SD-WAN
- Firewall Policy
SiteC 我們只做了 1. 跟 4. ，但卻沒有做 2. 跟 3.，也就是說其實針對LAN的部分Fortigate SD-WAN功能根本沒生效，我們只是因為需要SD-WAN Performance SLA來監測OSPF線路的狀態，所以硬把SDWAN Interface當作是上面的Zone來使用，也就是說其實理論上這樣設定是有問題的，但其實這樣設定有其好處。
有用過OSPF的MIS應該就能體會，這應該是最困擾所有MIS的事情，就是你根本不知道OSPF裡面的狀態，鍵人我就曾碰過兩地間的OSPF其中一條線路掉包很嚴重，但一直很難查出來的窘境，讓我們繼續看下去...
Internet連線測試
由SiteC PC持續發動Traceroute 8.8.8.8
確認是走A1toC1
將A1toC1斷線，改走A2toC2
將A2toC2斷線，流量改走SiteB A1toB1 過來
運作完美 ദ്ദി ༎ຶ‿༎ຶ )
OSPF Load Balance 測試
來驗證OSPF Load Balance是否正常，鍵人我將兩台PC都放到SiteC，透過這兩台PC分別Ping SiteA不同的Interface。
192.168.31.2走A1toC1去192.168.12.254，192.168.31.5走A2toC2去192.168.13.254，由此證明 IPSEC OSPF Load Balancing ok。
透過這兩台PC分別Ping Internet 8.8.8.8。
192.168.31.2走A1toC1去 8.8.8.8，192.168.31.5走A2toC2去 8.8.8.8，由此證明 IPSEC SDWAN Load Balancing ok。
結語
我中間有提到過，有用過OSPF的MIS應該就能體會，監測OSPF線路品質是最困擾所有MIS的事情，就是你根本不知道OSPF裡面的狀態好壞，鍵人我就曾碰過兩地間的OSPF其中一條線路掉包很嚴重但很難查出來的窘境，經過實作發現Fortigate 目前SD-WAN在IPSEC OSPF的搭配上雖然可以運作，但其實針對LAN的部分SD-WAN功能根本沒生效，也就是說其實理論上這樣設定是有問題的，我們只是因為需要SD-WAN Performance SLA來監測OSPF線路的狀態，所以硬把SDWAN Interface當作是上面的Zone來使用。
但透過SD-WAN下能夠監測OSPF線路品質，利用SD-WAN Performance SLA 的偵測機制確實可以大大的幫助OSPF線路狀況的研判與監測，且還是可以自動交換路由，依然提供給大家參考。
Fortigate IPSEC Aggregate + OSPF + SDWAN 實作
參考資料
https://docs.fortinet.com/document/fortigate/6.2.16/cookbook/25967/equal-cost-multi-path
前言
延續前一篇技術分享 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依然是個不錯的選擇