在設置 IPSec 隧道時，從瞻博網路防火牆收到格式錯誤的有效負載到 libreswan

我有一個 CentOS 系統，其 libreswan 在具有靜態 IP 的路由器後面，並且我一直在嘗試使用位於遠端位置的具有瞻博網路防火牆的伺服器設置 IPSec 隧道。遠端伺服器上的 IPSec VPN 設置是通過防火牆完成的。我已經嘗試了幾乎所有可能的設置組合，但每次都會遇到“格式錯誤的有效負載”的相同錯誤。以下是 CentOS shell 螢幕上顯示的通常日誌：

002 "GeojitOMS" #6: initiating Main Mode
104 "GeojitOMS" #6: STATE_MAIN_I1: initiate
003 "GeojitOMS" #6: ignoring unknown Vendor ID payload [2c9d7e81995b9967d23f571ac641f9348122f1cc1200000014060000]
003 "GeojitOMS" #6: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
003 "GeojitOMS" #6: received Vendor ID payload [Dead Peer Detection]
003 "GeojitOMS" #6: ignoring Vendor ID payload [HeartBeat Notify 386b0100]
002 "GeojitOMS" #6: enabling possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-02/03
002 "GeojitOMS" #6: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "GeojitOMS" #6: STATE_MAIN_I2: sent MI2, expecting MR2
003 "GeojitOMS" #6: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03 sender port 500: I am behind NAT+peer behind NAT
002 "GeojitOMS" #6: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "GeojitOMS" #6: STATE_MAIN_I3: sent MI3, expecting MR3
003 "GeojitOMS" #6: next payload type of ISAKMP Hash Payload has an unknown value: 210 (0xd2)
003 "GeojitOMS" #6: malformed payload in packet
010 "GeojitOMS" #6: STATE_MAIN_I3: retransmission; will wait 500ms for response
010 "GeojitOMS" #6: STATE_MAIN_I3: retransmission; will wait 1000ms for response
010 "GeojitOMS" #6: STATE_MAIN_I3: retransmission; will wait 2000ms for response
010 "GeojitOMS" #6: STATE_MAIN_I3: retransmission; will wait 4000ms for response
003 "GeojitOMS" #6: discarding duplicate packet; already STATE_MAIN_I3

嘗試了 libreswan 上的所有設置組合後，我想知道這是否與 CentOS 本身與瞻博網路不兼容的版本有關。這是 libreswan 和核心的版本：

[root@localhost xyz]# rpm -qa libreswan
libreswan-3.15-5.el7_1.x86_64
[root@localhost xyz]# uname -r
3.10.0-327.4.5.el7.x86_64

UDP 的 500 和 4500 埠在 CentOS iptables 上是開放的。此外，允許埠上的 beetel 路由器上的所有上行和下行流量。這是我的最終連接設置，但仍未解決：

我的本地子網：10.0.0.0/24

遠端子網：192.168.11.0/28

VPN 假設將本地機器與遠端子網上的兩個盒子連接，即 192.168.11.11 和 192.168.11.12，我認為這是通過子網配置的，除非 libreswan 中有辦法在同一連接中提及這兩個特定伺服器。/etc/ipsec.d/connection.conf：

conn Connection
   auto=start
   leftid=1.2.3.4 //Some pre-defined id for local machine
   left=10.0.0.16 //LAN IP of local machine
   #leftnexthop=xxx.yyy.zzz.www // Public static IP on router
   leftsubnet=10.0.0.0/24 //local subnet
   rightid=1.2.3.5 //Some pre-defined id for remote server
   right=www.zzz.yyy.xxx //Public IP of the remote server 
   rightsubnet=192.168.11.0/28 //Remote subnet
   #rightnexthop=192.168.11.11 //Remote server IP in remote LAN? not sure
   authby=secret
   ike=3des-sha1;modp1024
   phase2=esp
   phase2alg=3des-sha1
   #pfs=no
   forceencaps=yes
   compress=yes
   #ikev2=propose
   dpdaction=restart

機密文件 /etc/ipsec.secrets: 1.2.3.4 1.2.3.5: PSK “sharedkey”

嘗試使用“conn”中變數的不同組合以及禁用“nat_traversal”。但無論使用什麼組合，我仍然得到同樣的錯誤。這些設置中是否缺少任何內容，或者瞻博網路和 libreswan 或特定版本的 libreswan 之間是否存在兼容性問題？

我發現這裡的 libreswan 文件對與瞻博網路的互操作很有幫助。

我感覺到你的痛苦。眾所周知，VPN 很難做到恰到好處。看似最小的事情可能會使連接不穩定和/或無用。因此，我無法準確確定您在上面發布的哪個設置是錯誤的或缺失的，因此我將對可能引起問題的幾行進行評論。

phase2=esp phase2alg=3des-sha1 #pfs=no

即使它們是正確的，我也沒有成功嘗試指定這些 - 連接從未成功。當我讓這些值自動協商時，它神奇地起作用了。

壓縮=是

不應啟用壓縮，因為它是一個安全漏洞。

---

作為參考，我已經使用以下（混淆的）配置成功實現了 libreswan<–>Juniper 隧道。在此配置中，以下是正確的：

1. 左==本地（libreswan）和右==遠端（杜松）。
2. 作業系統為 CentOS 7.2
3. libreswan 包是libreswan-3.15-5.el7_1.x86_64
4. 本地 libreswan 在 NAT 之後。瞻博網路 NAT 狀態未知。
5. 我得到的唯一瞻博網路輔助資訊：

• 預共享密鑰
• 階段 1 == “pre-gp2-aes256-sha-24h”
• 階段 2 == “g2-esp-aes128-sha”

6. nat_traversal=yes在/etc/ipsec.conf

配置文件：

conn MyConnection
       ike=aes256-sha1;modp1024
       esp=aes128-sha1
       authby=secret
       keyingtries=0

       left=10.111.111.111
       leftsourceip=10.111.111.111
       leftsubnet=10.111.111.0/24

       right=1.2.3.4
       rightsubnet=10.222.222.0/24
       rightnexthop=%defaultroute

       compress=no
       auto=start

引用自：https://serverfault.com/questions/758105