RRAS L2TP/IPsec 被 NAT 擋掉報 Error 789,Registry 機碼該改哪條?

Yu Liu 20 信譽點數
2026-08-07T04:50:00.27+00:00

各位好,最近排查 Remote worker 用 L2TP/IPsec 連 RRAS 會吐 Error 789 的問題。

抓包看了一下發現是因為 Client 跟 Server 兩端都在 NAT 後面,Server 側把 UDP 4500 的 NAT-T (NAT-Traversal) Packet 直接 drop 掉了。查了資料好像是 Windows 機制預設把 NAT 穿透的 UDP encapsulation 關掉導致的。

想確認一下這狀況是在 Server 端(或 Client 端)的 Registry 加上 AssumeUDPEncapsulationContextForOnNatPage 這個 DWORD 嗎?路徑跟數值設定(例如設成 2)有沒有什麼坑需要注意?再麻煩經驗分享,感謝!

Windows for business | Windows 365 商務版
0 則留言 沒有留言

1 個回答

排序依據: 最舊
  1. Brian Huynh 3,815 信譽點數 Microsoft 外部員工
    2026-08-12T07:00:59.83+00:00

    您好 Yu Liu,感謝您在 Microsoft Q&A 社群發帖。

    在 Windows 系統的預設安全性機制中,當 VPN 伺服器或 VPN 用戶端位於 NAT (網路位址轉換) 裝置後方時,IPsec 預設不會建立 NAT-T (NAT-Traversal) 的安全性關聯 (Security Association, SA)。這是為了避免在某些舊型 NAT 設備上因 IPsec 封包封裝 (UDP Encapsulation) 導致潛在的安全性風險或路由異常。因此,當兩端都在 NAT 後方時,Windows 會直接拒絕或丟棄 UDP 4500 的 NAT-T 封包,導致 L2TP/IPsec 在 IKE/Phase 1 階段協商失敗並回報 Error 789。

    正確的 Registry 設定機碼名稱為 AssumeUDPEncapsulationContextOnSendRule (請注意:在 Windows Vista / Windows Server 2008 及後續的所有 Windows 版本中,請統一使用此名稱,舊版的 AssumeUDPEncapsulationContextForOnNat 已不適用)。

    1. 機碼路徑與數值設定
    • 註冊表路徑 (Registry Path): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
    • 數值名稱 (Value Name): AssumeUDPEncapsulationContextOnSendRule
    • 資料類型 (Type): DWORD (32-bit) Value
    • 數值資料 (Value Data):
      • 0 (預設值):禁止與位於 NAT 裝置後方的伺服器建立 IPsec SA。
      • 1:僅當伺服器位於 NAT 後方,而用戶端直接連線至網際網路 (非 NAT) 時允許建立 SA。
      • 2:當伺服器與用戶端兩端皆位於 NAT 後方(或其中任意一端位於 NAT 後方)時允許建立 SA。

    針對您目前的架構 (Client 與 Server 兩端都在 NAT 後),數值必須設定為 2。

    1. 設定範例 (PowerShell / CMD)

    注意事項: 修改 Windows 註冊表前,請務必先備份現有機碼。此外,此機碼修改後必須重新啟動電腦 (Reboot) 才能生效,單純重啟 IPsec Policy Agent (PolicyAgent) 服務可能無法讓底層 IPsec.sys 驅動程式重新載入該 context。

    您可以開啟系統管理員身分的 Command Prompt 執行以下指令:

    
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v "AssumeUDPEncapsulationContextOnSendRule" /t REG_DWORD /d 2 /f
    
    

    或使用 PowerShell (系統管理員) 執行:

    
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name "AssumeUDPEncapsulationContextOnSendRule" -Value 2 -Type Dword
    
    
    1. 常見注意事項與關鍵細節 (坑點)
    • 設定位置 (Client 與 Server 端): 官方建議並最佳的做法是在 Client 端與 RRAS Server 端皆加上此 Registry 機碼並設為 2。特別是 RRAS Server 位於 NAT/防火牆後方時,Server 端必須允許 UDP Encapsulation 才能回應 Client 端的 NAT-T 請求。
    • 路由器 / 防火牆 Port Forwarding: RRAS 前端的 NAT 路由器/防火牆必須將外部的 UDP 500 (IKE) 與 UDP 4500 (IPsec NAT-T) 正確 Port Forwarding 至 RRAS 伺服器的內部 IP 位址,並確認防火牆未阻擋 ESP (IP Protocol 50) 協定或已開啟 IPsec Passthrough。
    • 預先共用金鑰 (Preshared Key, PSK) / 憑證比對: 若完成 Registry 修改並重啟後仍出現 Error 789,請檢查 RRAS 與 Client 端的 L2TP IPsec 預先共用金鑰 (PSK) 是否完全一致,或 Client 端的 IPsec Policy Agent 服務 (PolicyAgent) 是否正常執行。

    診斷資訊請求

    若完成上述 Registry 修改並重啟 Server 及 Client 後問題依然存在,為了進一步定位原因,您可以提供以下資料:

    1. 在 Client 端開啟系統管理員身分 Command Prompt 啟用 RRAS/L2TP 追蹤日誌:
      
         netsh ras set tracing state=enabled
      
      
      重試連線後,日誌將產出於 C:\Windows\Tracing 目錄下 (請特別關注 PPP.log 與 RASTLS.log)。
    2. 在 Client 與 Server 端的 事件檢視器 (Event Viewer) -> Windows 記錄 (Windows Logs) -> 系統 (System) 中,尋找來源為 RemoteAccess 或 RasClient 的 Event ID 20227 或 20221 詳細錯誤內容。

    我會持續追蹤此討論串以確保您的問題得到解決。如果此解答對您有所幫助,請考慮將其標記為 「接受解答 (Accept Answer)」,這將有助於社群中遇到相同 NAT-T 與 Error 789 問題的其他工程師快速找到解決方案!

    相關 Microsoft Learn 官方說明文件:

    此回答有幫助嗎?

    0 則留言 沒有留言

您的回答

答案可由問題作者標示為「已接受」,而由仲裁者標示為「推薦」,這可協助使用者知道答案解決了作者的問題。