This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPSec VPN link goes down periodically, and does not re-establish itself (ASL 3.020)

I'm experiencing that my VPN connection drops dead after a few days, and does not manage to bring itself up again (which is what IPSec *should* do). It appears that the Pluto processes on each side get confused by not seeing the packet responses that they expect, or something to that effect. In other words, the two endpoints seem to get "out-of-sync" somehow.

When the connection actually is up and working, I get the message "main mode message is part of an unknown exchange" constantly reported in the logs. What does this mean? I suspect it has something to do with these problems.

As I have noted in other postings in this forum, I have configured several ASLASL connections between different locations, and they have all worked fine (using the same version).

By the way, these two networks are connected by means of an ADSL line, in case that matters.

Here's a snippet from the logs on both sides --

"Left" side:

Mar 18 19:20:50 shadowgate Pluto[22695]: "to-oslo_1" #83: max number of retransmissions (2) reached STATE_MAIN_R1
Mar 18 19:20:52 shadowgate Pluto[22695]: packet from 217.xx.xx.xx:500: Main Mode message is part of an unknown exchange
Mar 18 19:21:00 shadowgate Pluto[22695]: "to-oslo_1" #85: responding to Main Mode
Mar 18 19:21:02 shadowgate Pluto[22695]: packet from 217.xx.xx.xx:500: Main Mode message is part of an unknown exchange
Mar 18 19:21:22 shadowgate Pluto[22695]: packet from 217.xx.xx.xx:500: Main Mode message is part of an unknown exchange
Mar 18 19:21:30 shadowgate Pluto[22695]: "to-oslo_1" #84: max number of retransmissions (2) reached STATE_MAIN_R1
Mar 18 19:21:32 shadowgate Pluto[22695]: packet from 217.xx.xx.xx:500: Main Mode message is part of an unknown exchange
Mar 18 19:21:40 shadowgate Pluto[22695]: "to-oslo_1" #86: responding to Main Mode
Mar 18 19:21:41 shadowgate Pluto[22695]: packet from 217.xx.xx.xx:500: Main Mode message is part of an unknown exchange
Mar 18 19:24:41 shadowgate Pluto[22695]: packet from 217.xx.xx.xx:500: Main Mode message is part of an unknown exchange
Mar 18 19:24:50 shadowgate Pluto[22695]: "to-oslo_1" #89: max number of retransmissions (2) reached STATE_MAIN_R1
Mar 18 19:24:52 shadowgate Pluto[22355]: "to-oslo_1" #7: max number of retransmissions (20) reached STATE_MAIN_I1.  No acceptable response to our first IKE message

"Right" side:

Mar 18 19:21:27 astaro-oslo Pluto[2205]: packet from 217.xx.x.xx:500: Main Mode message is part of an unknown exchange
Mar 18 19:21:29 astaro-oslo Pluto[2205]: "to-bergen_2" #778: responding to Main Mode
Mar 18 19:21:29 astaro-oslo Pluto[2205]: "dmz-inbound_1" #2: IPsec SA expired (LATEST!)
Mar 18 19:21:29 astaro-oslo Pluto[2205]: | no phase 1 state where one should be
Mar 18 19:21:29 astaro-oslo Pluto[2205]: | no phase 1 state where one should be
Mar 18 19:21:29 astaro-oslo Pluto[2205]: "to-bergen_2" #3: IPsec SA expired (LATEST!)
Mar 18 19:21:29 astaro-oslo Pluto[2205]: | no phase 1 state where one should be
Mar 18 19:21:29 astaro-oslo Pluto[2205]: | no phase 1 state where one should be
Mar 18 19:21:29 astaro-oslo Pluto[16882]: ERROR: pfkey write() of SADB_X_DELFLOW message 31 for flow %hold failed. Errno 14: Bad address
Mar 18 19:21:29 astaro-oslo Pluto[16882]: |   02 0f 00 0b  0e 00 00 00  1f 00 00 00  f2 41 00 00
Mar 18 19:21:29 astaro-oslo Pluto[16882]: |   03 00 15 00  00 00 00 00  02 00 00 00  0a c9 ff 03
Mar 18 19:21:29 astaro-oslo Pluto[16882]: |   00 20 00 00  01 00 00 00  03 00 16 00  00 00 00 00
Mar 18 19:21:29 astaro-oslo Pluto[16882]: |   02 00 00 00  0a 0a 90 fe  34 fb ff bf  00 00 00 00
Mar 18 19:21:29 astaro-oslo Pluto[16882]: |   03 00 17 00  00 00 00 00  02 00 00 00  ff ff ff ff
Mar 18 19:21:29 astaro-oslo Pluto[16882]: |   00 00 00 00  d8 7a 09 08  03 00 18 00  00 00 00 00
Mar 18 19:21:29 astaro-oslo Pluto[16882]: |   02 00 00 00  ff ff ff ff  ac e6 ff bf  ff ff ff ff
Mar 18 19:21:36 astaro-oslo Pluto[2205]: packet from 217.xx.x.xx:500: Main Mode message is part of an unknown exchange
Mar 18 19:21:46 astaro-oslo Pluto[2205]: packet from 217.xx.x.xx:500: Main Mode message is part of an unknown exchange
Mar 18 19:21:59 astaro-oslo Pluto[2205]: "to-bergen_2" #777: max number of retransmissions (2) reached STATE_MAIN_R1

Occasionally, the line also goes down with "no route to host" messages, indicating that some network error occured (although briefly). Shouldn't IPSec be able to reconnect even in such an event?

Mar 12 04:04:03 astaro-oslo Pluto[32748]: ERROR: asynchronous network error report on eth1 for message to 217.xx.x.xx port 500: compainant 217.xx.x.xx, errno 113 No route to host, origin ICMP type 11 code 0 (not authenticated)

Mar 12 07:17:51 astaro-oslo Pluto[32748]: "to-bergen_2" #5958: ERROR: asynchronous network error
report on eth1 for message to 217.xx.x.xx port 500: compainant 217.xx.xx.xx, errno 113 No route to host, origin ICMP type 3 code 1 (not authenticated)

As always, any help whatsoever is greatly appreciated.


Best regards,

// Martin

[ 04 April 2002: Message edited by: Martin Andersen ]



This thread was automatically locked due to age.
  • hi there, 
    this seems to me that, the ike session is no longer there, this is why it can not establish a new ipsec connection.

    What lifetimes did you use in IKE and IPSec?

    How does the IPSec setup in general look like.

    kind regards
    polluxxx
  • Hi Martin,

    I've configured VPN connectivity using ASL and I've established the VPN. I'm facing the problem, that VPN is disconnecting ever 2 hours (After restarting the VPN Setup).

    My configuration is checked with the remote VPN Gateway Server and the IKE rekey lifetime is same with the other end. 

    What could be the exact problem in this VPN Setup. Is there any config issues will be there in my setup.

    For me also the same error is coming in the VPN LiveLog what U mentioed.
  • I am having the same problem and suspect it has to do with the Security Association lifetime. I read somewhere there is a limit to the lifetime that must be set, but can not find the document. I would be interested to find out the solution you get.

    Regards,

    Patrick in Toronto