0

I'm setting up an IPSec connection from an Westermo MRD310 to our company Cisco ASA5510.

We've had many successful setups using this method, creating a tunnel network between a remote location and our internal network. This time I'm trying to do this setup over a GPRS speed network (that's what you get way up in the north of Sweden). But it won't go through.

Does anyone have information about what fails in the following log, or have information about minimum transfer rates for establishing an IPSec tunnel. Also, any information on what could decrease transfer rate requirements would be appreciated.

I use a subscription with public, static IP-address to avoid NAT:ing and unexpected address changes. However as the GPRS is the initiator, static IP shouldn't be a requirement for this, am I right?

<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
Niclas Lindqvist
  • 189
  • 1
  • 10

3 Answers3

1

I have experienced something very similar to this when using a 3G dongle. We gave all our remote users these 3G dongles so they could VPN into our system while on a customers site. In low signal areas (specifically GPRS areas), we were getting frequent drop outs from the VPN, however the internet connection from dongle seemed fine.

What we eventually determined after a VERY long and frustrating investigation was that the GPRS connection was dropping momentarily and reconnecting, and the dongle provider was issuing a different DHCP IP address. Looking at the firewall logs, it saw this change of IP address and thought it was a man in the middle attack, and terminated the VPN connection. I don't know if your firewall looks at this, but it might be worth looking into.

Unfortunately there's nothing we can do about this, but at least we know why it's dropping.
For some reason I can't explain, just knowing why the problem occurs is kind of comforting, even though I am powerless to fix it.

Ben Pilbrow
  • 11,995
  • 5
  • 35
  • 57
  • Hi, Thanks for your answer, i suppose the connection _could_ be dropping momentarily.. Though I am not getting any noticeable reconnection-delay from the remote connection while using it so to speak. We have a special subscription with the provider, giving us a static, public IP address, so i shouldn't be getting new onces. Sorry I forgot to mention this in my post. I'll try to find something in my logs about this though. – Niclas Lindqvist Jun 22 '10 at 04:33
1

OK guys. After restarting my company firewall (due to an error in ASDM I couldn't start the ASDM interface once firewall uptime exeeded 1 year), I could read the log message comming in to the ASA 5510.

Turns out all it was, was a misprinted IP-address in the peer-to-peer VPN-tunnel setup in the ASA. Changed it to the right IP address and swosh, everything started working!

I'm afraid this might stamp me for the future as a novice in this area. But heck, I'm not fooling anyone as it is..

Thanks for the help and ideas, but sometimes, human error is the root of all bad.

Niclas Lindqvist
  • 189
  • 1
  • 10
0

When you say you have done this successfully before have you made use of this style VPN connection over this Cellular Provider's data network while using the specific APN that this connection uses?

Speed should not be an issue, at least not at the 30-60kps that GPRS supports. It will be slow but it should work fine. What's far more likely to be happening is that the cell provider has a double NAT (for some reason, beats me as to why) or one that is specifically configured not to support VPN traffic (much more likely, they used to do this a lot in order to force you to use a business tariff).

Another possibility - especially given the location - is that they provider is using some form of accelerator to boost "normal" internet traffic and that mechanism is modifying some packets in a way that causes the IKE handshake to fail.

Helvick
  • 19,579
  • 4
  • 37
  • 55
  • Hi, thanks for your answer. Yes indeed, we have used the same provider and the same APN. It's a special subscription, providing a public, static IP address, no NAT:ing going on. Are these "accelerators" normal? Do you have an example of one of these where I can read up on what it does and perhaps contact the provider about it? – Niclas Lindqvist Jun 22 '10 at 04:37
  • See the section in this Vodafone document on VPN's about Network Generic Optimisers - http://www.vodafone.nl/Vodafone/wg20/pdf/IPSec-PPTP_VPN_Devices_in_GPRS_Environment___version_1.pdf – Helvick Jun 22 '10 at 21:55
  • Thanks for your time and help Helvick! I really hope that's not what's going on over here, but who knows. Perhaps I should talk to my service provider about this. However, one would hope these things have changed over time, since the document is from late 2003. For reference, page 13 in document above says: "In addition the optimiser mayprovide optimisation to the TCP layer to cope with the specifics of a wireless connection [...] As the consequence there may be some problems when using TCP encapsulation for ESP. There is one known issue between the Cisco VPN and NGOs." – Niclas Lindqvist Jun 23 '10 at 07:08