我的 GPRS 連接對於 IPSec 連接是否太慢？

我正在建立從 Westermo MRD310 到我們公司 Cisco ASA5510 的 IPSec 連接。

我們已經使用這種方法進行了許多成功的設置，在遠端位置和我們的內部網路之間創建了一個隧道網路。這次我嘗試通過 GPRS 速度網路進行此設置（這就是您在瑞典北部獲得的方式）。但它不會通過。

是否有人在以下日誌中有關於失敗的資訊，或者有關於建立 IPSec 隧道的最低傳輸速率的資訊。此外，任何關於什麼可以降低傳輸速率要求的資訊都將不勝感激。

我使用具有公共靜態 IP 地址的訂閱來避免 NAT:ing 和意外的地址更改。但是，由於 GPRS 是發起方，因此靜態 IP 不應該是這個要求，對嗎？

<83>Jun 21 23:00:57 ipsec__plutorun: Starting Pluto subsystem...  
<27>Jun 21 23:00:57 ipsec_setup: ...Openswan IPsec started  
<84>Jun 21 23:00:57 pluto[5860]: Starting Pluto (Openswan Version 2.4.12 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEKBzdY{wM]@) 
<84>Jun 21 23:00:57 pluto[5860]: Setting NAT-Traversal port-4500 floating to on 
<84>Jun 21 23:00:57 pluto[5860]:    port floating activation criteria nat_t=1/port_fload=1 
<84>Jun 21 23:00:57 pluto[5860]:   including NAT-Traversal patch (Version 0.6c) 
<86>Jun 21 23:00:57 ipsec__plutorun: Unknown default RSA hostkey scheme, not generating a default hostkey 
<84>Jun 21 23:00:57 pluto[5860]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0) 
<84>Jun 21 23:00:57 pluto[5860]: no helpers will be started, all cryptographic operations will be done inline 
<84>Jun 21 23:00:57 pluto[5860]: Using KLIPS IPsec interface code on 2.6.25-uc0 
<84>Jun 21 23:00:57 pluto[5860]: Changing to directory '/etc/config/cacerts' 
<84>Jun 21 23:00:57 pluto[5860]: Changing to directory '/etc/config/aacerts' 
<84>Jun 21 23:00:57 pluto[5860]: Changing to directory '/etc/config/ocspcerts' 
<84>Jun 21 23:00:57 pluto[5860]: Changing to directory '/etc/config/crls' 
<84>Jun 21 23:00:57 pluto[5860]:   Warning: empty directory 
<27>Jun 21 23:00:57 ipsec_setup: Starting Openswan IPsec 2.4.12...  
<84>Jun 21 23:00:58 pluto[5860]: loading secrets from "/etc/config/ipsec.secrets" 
<84>Jun 21 23:01:01 pluto[5860]: added connection description "SPMVPN" 
<84>Jun 21 23:01:01 pluto[5860]: listening for IKE messages 
<84>Jun 21 23:01:01 pluto[5860]: adding interface ipsec0/hso0 85.117.XXX.XX:500 
<84>Jun 21 23:01:01 pluto[5860]: adding interface ipsec0/hso0 85.117.XXX.XX:4500 
<84>Jun 21 23:01:01 pluto[5860]: forgetting secrets 
<84>Jun 21 23:01:01 pluto[5860]: loading secrets from "/etc/config/ipsec.secrets" 
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: initiating Main Mode 
<27>Jun 21 23:01:02 ipsec__plutorun: 104 "SPMVPN" #1: STATE_MAIN_I1: initiate  
<27>Jun 21 23:01:02 ipsec__plutorun: ...could not start conn "SPMVPN"  
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106  
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: ignoring Vendor ID payload [FRAGMENTATION c0000000] 
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: enabling possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-02/03 
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 
<84>Jun 21 23:01:02 pluto[5860]: "SPMVPN" #1: STATE_MAIN_I2: sent MI2, expecting MR2 
<84>Jun 21 23:01:13 pluto[5860]: "SPMVPN" #1: ignoring informational payload, type INVALID_COOKIE 
<84>Jun 21 23:01:13 pluto[5860]: "SPMVPN" #1: received and ignored informational message 
<84>Jun 21 23:01:32 pluto[5860]: "SPMVPN" #1: ignoring informational payload, type INVALID_COOKIE 
<84>Jun 21 23:01:32 pluto[5860]: "SPMVPN" #1: received and ignored informational message 
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #1: max number of retransmissions (2) reached STATE_MAIN_I2 
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #1: starting keying attempt 2 of an unlimited number 
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: initiating Main Mode to replace #1 
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106  
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: ignoring Vendor ID payload [FRAGMENTATION c0000000] 
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: enabling possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-02/03 
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 
<84>Jun 21 23:02:12 pluto[5860]: "SPMVPN" #2: STATE_MAIN_I2: sent MI2, expecting MR2 
<84>Jun 21 23:02:22 pluto[5860]: "SPMVPN" #2: ignoring informational payload, type INVALID_COOKIE 
<84>Jun 21 23:02:22 pluto[5860]: "SPMVPN" #2: received and ignored informational message 
<84>Jun 21 23:02:42 pluto[5860]: "SPMVPN" #2: ignoring informational payload, type INVALID_COOKIE 
<84>Jun 21 23:02:42 pluto[5860]: "SPMVPN" #2: received and ignored informational message 

好了朋友們。重新啟動公司防火牆後（由於 ASDM 中的錯誤，一旦防火牆正常執行時間超過 1 年，我就無法啟動 ASDM 介面），我可以閱讀進入 ASA 5510 的日誌消息。

事實證明，這只是ASA**的對等 VPN 隧道設置中的一個錯誤列印的 IP 地址。**將其更改為正確的 IP 地址並嗖嗖，一切都開始工作了！

恐怕這可能會給我作為該領域新手的未來留下印記。但是，見鬼，我並沒有像現在這樣愚弄任何人..

感謝您的幫助和想法，但有時，人為錯誤是所有壞事的根源。

在使用 3G 加密狗時，我遇到了與此非常相似的情況。我們為所有遠端使用者提供了這些 3G 加密狗，以便他們可以在客戶站點上通過 VPN 訪問我們的系統。在低信號區域（特別是 GPRS 區域），我們經常從 VPN 中退出，但是來自加密狗的網際網路連接似乎很好。

經過漫長而令人沮喪的調查後，我們最終確定的是 GPRS 連接暫時斷開並重新連接，並且加密狗提供商正在發布不同的 DHCP IP 地址。查看防火牆日誌，它看到了這個IP地址的變化，並認為是中間人攻擊，並終止了VPN連接。我不知道您的防火牆是否會考慮這一點，但它可能值得研究。

不幸的是，我們對此無能為力，但至少我們知道它為什麼會下降。

出於某種原因，我無法解釋，只是知道問題發生的原因是一種安慰，即使我無能為力解決它。

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