我們的客戶有 6 個使用 IPsec 的網站。資料不時停止從遠端 Fortigate VPN 伺服器流向本地 MikroTik IPsec VPN 用戶端，可能是每週一次，有時每月一次。
為了示範問題的症狀，我附上了一張圖表。在圖表“Installed SAs”標籤上，您會注意到來源 IP 位址 xx186.50 嘗試與 xx7.3 通信，但目前位元組為 0。 xx186.50 是客戶端的遠端 Fortigate IPsec 伺服器，xx7.73 是基於 MikroTik 的 IPsec 端點。從遠端到我們的數據似乎並不總是流動的。
第 1 階段和第 2 階段始終已建立，但流量始終拒絕從遠端流向我們。
隨著時間的推移，我們嘗試了各種方法，例如重新啟動、設定時鐘、涉足配置、重新檢查和重新檢查配置，但問題似乎完全是隨機的。有時隨機的事情可以修復它。在某個階段，我有一個理論，如果隧道是從他們這邊啟動的，那麼它就可以工作，但是擺弄「發送初始聯繫」並沒有任何區別。
我們已經與客戶就此進行了多次交談，但他們有更多的國際 IPsec VPN，只有我們的 MikroTik 配置失敗。
強化日誌：
http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=11654
看看 Fortigate 的知識庫，SPI 似乎不同意，而 DPD 會有所作為。但我已經嘗試了這方面DPD的每一種組合，但沒有效果。我想在另一端啟用 DPD，但由於更改控製而無法啟用，而且還因為客戶說它在所有其他網站上的工作配置完全相同。編輯 DPD 已啟用
顯示無流量的本機 VPN 用戶端圖：
我包含了一個日誌文件，顯示“收到有效的 RU-THERE，已發送 ACK”MikroTik 日誌文件的連續循環：
echo: ipsec,debug,packet 84 位元組從 xx7.183[500] 到 xx186.50[500]
echo: ipsec,調試,封包套接字名稱 xx7.183[500]
echo: ipsec,debug,packet 從 xx7.183[500] 發送封包
echo: ipsec,debug,packet 發送封包到 xx186.50[500]
echo: ipsec,調試,封包 src4 xx7.183[500]
echo: ipsec,調試,封包 dst4 xx186.50[500]
echo: ipsec,debug,packet 1次84位元組訊息將會傳送到xx186.50[500]
echo: ipsec,調試,封包 62dcfc38 78ca950b 119e7a34 83711b25 08100501 bc29fe11 00000054 fa115faf
迴聲： ipsec，調試，封包 cd5023fe f8e261f5 ef8c0231 038144a1 b859c80b 456c8e1a 075f6be3 53ec3979
回顯：ipsec，調試，封包 6526e5a0 7bdb1c58 e5714988 471da760 2e644cf8
echo: ipsec,debug,packet sendto 訊息通知。
echo：ipsec，調試，封包收到有效的 RU-THERE，已發送 ACK
我收到了來自 IPsec 專家和 MikroTik 本身的各種建議，暗示問題出在遠端。然而，由於其他 5 個站點正在運作且用戶端的防火牆處於變更控制之下，情況變得非常複雜。該設定也始終有效多年，因此他們聲稱這不可能是他們這邊的配置錯誤。這個建議似乎有道理，但由於變更控制，我無法實施。我可能只改變客戶端：
確保 IPSec 回應方同時設定了「passive=yes」和「send-initial-contact=no」。
這不起作用。
2013 年 12 月 9 日編輯
我將貼上 Fortigate 配置的其他螢幕截圖以及我們認為是 Mikrotik 一側的快速模式選擇器。
讓我重申一下，我不認為這是配置問題。我推測這是一個定時問題，A 方或 B 方試圖過於積極地發送訊息，導致訊息協商（例如 SPI）不同步。
編輯 2013 年 12 月 11 日
可悲的是我不得不放棄這個問題。令人高興的是一切正常。為什麼它起作用仍然是一個謎，但為了進一步說明我們所做的，我內嵌了另一張圖片。
我們透過以下方式修復了它：
- 關閉客戶端的 PPPoE。
- 安裝全新的路由器（路由器 B）並在邊境進行測試。它在邊境發揮了作用。
- 在邊界關閉新路由器 B。然後，無需進行任何更改，客戶端的端點路由器 A 就開始工作。因此，只需在邊界中添加重複的路由器並再次使該路由器離線即可使原始路由器正常工作。
因此，將此修復添加到我們已完成的事情清單中：
- 重啟。曾經有效過一次。
- 使用新 IP 建立新隧道。這有效過一次，但只有一次。更改 IP 後，客戶端端點再次上線。
- 更改時間伺服器。
- 擺弄每一個可能的設定。
- 等待。有一次，一天之後，它就來了。這一次，即使過了幾天，也沒有任何進展。
因此，我假設 Fortigate 或 MikroTik 方面存在不相容性，這種情況只會在非常隨機的情況下發生。我們唯一無法嘗試的是升級 Fortigate 上的韌體。也許存在隱藏的損壞配置值或配置者不可見的計時問題。
我進一步推測該問題是由導致 SPI 不匹配的時序問題引起的。我的猜測是 Fortigate 不想「忘記」舊的 SPI，就好像 DPD 不起作用一樣。它只是隨機發生，據我所知，只有當端點 A 是 Fortigate 並且端點 B 是 MikroTik 時。不斷積極嘗試重新建立連線「保留」舊的 SPI 值。
當再次發生這種情況時，我會添加到這篇文章中。
編輯 2013 年 12 月 12 日
正如預料的那樣，事情又發生了。您可能還記得，我們設定了 6 個 MikroTik 用戶端 IPsec 端點路由器一模一樣連接到一台 Fortigate 伺服器。最近的事件又是針對隨機路由器的，而不是我最初在這裡發布的那個。考慮到我們安裝了這個重複路由器的最後一個修復，我採取了這個快捷方式：
- 停用路由器 A，該路由器不想再接收來自 Fortigate 的封包。
- 將路由器 A 的 IPsec 設定複製到靠近網路邊界的臨時路由器。
- 立即停用新建立的配置。
- 重新啟用路由器 A。
- 它會自動開始工作。
看看@mbrownnyc 評論，我相信我們遇到了 Fortigate 的問題，即使 DPD 已開啟，Fortigate 也不會忘記過時的 SPI。我將調查我們客戶的韌體並將其發布。
這是一個新圖表，與上一個圖表非常相似，但只是顯示了我的“修復”：
答案1
可能不是問題的原因，但可能對其他使用者有用。我們在 Mikrotik 和 Sonicwall 之間使用 VPN 時遇到了稍微類似的問題。流量會隨機停止，需要刷新 SA。
最後我們意識到 Sonicwall 正在為每個網路策略建立一個單獨的 SA（從您的螢幕截圖來看，您似乎有 2 個策略/子網路通過 VPN）。我不知道這個“SA-per-policy”設定是硬編碼的還是可配置的，因為我沒有權限訪問 Sonicwall。
我們的 Mikrotik 使用策略的「要求」等級（預設值，如螢幕截圖所示）。這會導致路由器與遠端對等方建立單一 SA。當為該對等點發送任何策略的流量時，它將使用相同的 SA，無論來源/目標子網路為何。
這基本上意味著只要我們只使用一個子網，它就可以工作。一旦我們的 Mikrotik 嘗試發送第二個子網路的流量，它就會透過現有 SA 發送（就 Sonicwall 而言，這是針對特定子網對的），Sonicwall 會抱怨，SA 序號將超出重重一擊，一切都停止了。 （在我們的案例中，客戶最終遇到「重播」錯誤）
最後，就像將策略等級更改為“唯一”一樣簡單，因此兩端為每個唯一的子網路對使用唯一的 SA。在那之後，隧道裡的人都非常高興。
答案2
我知道您已經檢查過這一點（就像我遇到類似但完全不同的間歇性問題時所做的那樣），但請確保您沒有路由器 A 共享的重複 IP 位址。當您的高階路由器對路由器 A 進行 arp 查找並感到困惑時，這會給您帶來間歇性問題。您可能認為路由器上的 dup Ips 會給出一致的錯誤，但事實並非如此。