我的 GPRS 连接对于 IPSec 连接来说是否太慢了?

我的 GPRS 连接对于 IPSec 连接来说是否太慢了?

我正在建立从 Westermo MRD310 到我们公司 Cisco ASA5510 的 IPSec 连接。

我们已经使用这种方法成功设置了许多设备,在远程位置和我们的内部网络之间创建了隧道网络。这次我尝试通过 GPRS 速度网络(瑞典北部的地区就是这样的)进行设置。但无法通过。

有谁知道以下日志中失败的原因,或者有关于建立 IPSec 隧道的最低传输速率的信息吗?此外,任何关于如何降低传输速率要求的信息都将不胜感激。

我使用订阅公共静态 IP 地址以避免 NAT 和意外的地址更改。但是,由于 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 

答案1

使用 3G 加密狗时,我遇到过类似的事情。我们为所有远程用户提供了这些 3G 加密狗,以便他们在客户站点时可以通过 VPN 接入我们的系统。在信号较弱的区域(特别是 GPRS 区域),VPN 经常中断,但加密狗的互联网连接似乎没问题。

经过非常漫长而令人沮丧的调查,我们最终确定 GPRS 连接会暂时断开并重新连接,而加密狗提供商发出了不同的 DHCP IP 地址。查看防火墙日志,它看到了 IP 地址的更改,并认为这是中间人攻击,并终止了 VPN 连接。我不知道您的防火墙是否会检查这一点,但可能值得调查一下。

不幸的是我们对此无能为力,但至少我们知道为什么速度下降了。
由于某些我无法解释的原因,即使我无力修复它,但只要知道问题发生的原因就足以让我感到欣慰。

答案2

好的,伙计们。重启我公司的防火墙后(由于 ASDM 中的错误,一旦防火墙正常运行时间超过 1 年,我就无法启动 ASDM 界面),我可以读取进入 ASA 5510 的日志消息。

原来它只是一个点对点 VPN 隧道中 IP 地址打印错误在 ASA 中设置。将其更改为正确的 IP 地址,然后,一切开始正常工作!

我担心这可能会让我成为这个领域的新手。但是,我并没有欺骗任何人。

感谢您的帮助和想法,但有时,人为错误是一切坏事的根源。

答案3

当您说您之前已经成功完成此操作时,您是否在使用此连接所使用的特定 APN 通过此移动运营商的数据网络使用过这种样式的 VPN 连接?

速度不应该是个问题,至少在 GPRS 支持的 30-60kps 下不是问题。速度会很慢,但应该可以正常工作。更有可能发生的是,移动运营商有双重 NAT(出于某种原因,我不知道为什么)或专门配置为不支持 VPN 流量(更有可能的是,他们过去经常这样做,以迫使您使用商业资费)。

另一种可能性(尤其是考虑到位置)是,提供商正在使用某种形式的加速器来增强“正常”互联网流量,并且该机制正在以导致 IKE 握手失败的方式修改某些数据包。

相关内容