VTI unnumbered with 3rd party

[George_Liu]

實作 VTI unnumbered with 3rd party (FortiGate 60C, Juniper SSG5)，以下是簡略的 memo 留存。(只記錄我方重點步驟，其餘留default，或二端匹配之VPN設定)

VTI unnumbered
1. GaIA - add vpn tunnel 1 type unnumbered local peer peergwname dev eth0
2. GaIA - set static-route xx.xx.xx.xx/yy nexthop gateway logical vpnt1 on
3. SmartConsole - Create a empty Group object. (I.E. VPN_Empty)
4. SmartConsole - Create a Interoperable Devices - IPv4 Address
5. SmartConsole - Modify Interoperable Devices - Topology - VPN Domain - Manually defined - VPN_Empty
5. SmartConsole - Create a community with two firewall peers.

[HeikoAnkenbrand]

You found detail  informations here:

Site to Site VPN Administration Guide R80.10

[HeikoAnkenbrand]

Tip:
-use IKEv1
-use same ProxyID
- on ssg side:
- add gateway
- add VPN tunnel Interface
- add route
- add VPN role

[Neville_Kuo]

需注意corexl問題,在R77.30之前route based vpn不支援。

[Dawei_Ye]

通过static route priority能做出来两条route based vpn是Active/Standby的效果吗？

[Neville_Kuo]

當然可以,還可以做route monitor,或者配合dynamic routing做出漂亮的流量工程。

[Dawei_Ye]

拜读过N大的Route-based vpn with OSPF.
最近在测试route-based vpn ,当中需要用到pbr，好像pbr没办法通过priority来切换。
还在测试中……

[Neville_Kuo]

如果您的PBR的next hop是多個IP,那我們的經銷夥伴測試過了,看來是不行,CP的routing功能不強。

[Dawei_Ye]

嗯，我们有两条VPN Tunnel，想通过pbr中next hop优先级来做active/standby。
看样子只能用dynamic routing了？

[Neville_Kuo]

如果需求只是這樣,那您就更應該考慮用dynamic routing了,試試用簡單的RIP,兩個interface設定不同cost,就可以達到您要的效果了,在小範圍裡它算最好上手的routing protocol了,當然記得policy要allow RIP,如果用OSPF更好。

PBR對securexl有反效果,所以對效能也有不好影響,我個人不建議也不喜歡。

[Neville_Kuo]

在R80.30的新功能可以試試,我還沒玩過:

Advanced Routing

• Multihop Ping and Multiple ISPs in Policy-Based Routing
• Multihop Ping in Static Routes
• BFD in Static Routes
• VSX VSID in Netflow

但是Public cloud的R80.30不知道釋出了沒有。

[Dawei_Ye]

上周部署AWS暂时还没有R80.30。
之前的问题后面用了BGP来解决。但是后面发现AWS上，在HA切换后Route-based VPN会起不来，导致BGP路由学不到。
还在和TAC沟通中。

[George_Liu]

unnumber vti 不支持 route ping monitor，最近測試發現的，現在準備試看看 vti number 能不能實現這個需求。

[Neville_Kuo]

喬治哥:

基本上您的需求把vti介面設IP就對了,我們有個客戶跑了3條route based vpn,都有做route monitoring。

這個情況很正常,因為unnumber其實是和實體介面"借"了一個IP過來,如果要做route monitoring,對底層的OS而言,它會不知道要帶實體介面或者vti去ping next hop的,因為IP都是同一個。

假設Route based vpn架構單純(只有兩個點),懶得幫vti介面想IP,卻又要讓某些需要NAT traversal的應用(如IPsec或VOIP)封包通過的話,直接用unnumber很適合,因為您的目的只是為了有IP可以去轉換而已,但是如果像我們常會遇到Dynamic routing, route monitor,或vti有多個next hop的需求時, unnumber是行不通的。

所以後來我都不用unnumber interface了,即使架構簡單。

[George_Liu]

受益了。

[George_Liu]

To Dawei

實作 vti number + static route ping monitor + static route priority 可達到您要的 active /standby 線路需求。

[Dawei_Ye]

乔治哥，

确实static route应该是可以的。
后续我们使用了N大建议的OSPF，但是我这边是在AWS上测试，发现一个很奇怪的现象：
由于我是通过Route-based VPN建立的OSPF，在AWS上ClusterXL切换最长可能要40+s，正好大于了OSPF的dead timer.

所以，几乎每次都会切到另外一个neighbor，再切回来。
而且我们发现，如果过了Dead Time,ClusterXL切换还没完成的话，有很大概率会发生主线路的route-based VPN不通的情况。

大概需要30分钟，甚至更长，才能恢复。
这时由于priority和cost的设置，路由会切回active线路。

[Neville_Kuo]

在公有雲上要想想別的辦法了,傳統的clusterxl機制不再,改成用API的方式,所以時間會比以前長很多,這好像是沒有辦法的事。

[Dawei_Ye]

对的。API的方式，没法改变。
不过，我说的30分钟不是clusterXL failover的时间，正常failover的时间在40-60s左右。

但是VPN这个问题，我现在只能开SR请TAC帮忙了。不知道能不能解决。

[Dawei_Ye]

今天突然发现sk104418中提到：
Route Based VPN (with VTI) is not supported over cluster solution.

……

[Neville_Kuo]

恭喜,那TAC也可以關了。

[Cyber_Serge]

I want to mention that the new Check Point Maestro does not support VTI. It can be found under sk148074 Check Point Maestro Known Limitation. Would have saved me days of work if I read it earlier