Hi All,

Just to add to the below problem, I too am facing the same issue. Morning, I switch ON my target and evrything works like a charm. Then after a couple  of times, ipv6 isec STOPS working

It hangs in the 2009-08-11 09:00:44: INFO: isakmp.c:1079:isakmp_ph1begin_i(): initiate new phase 1 negotiation: <=>2001:db8:0:1:20f:20ff:fefe:91db[500]
2009-08-11 09:00:44: INFO: isakmp.c:1085:isakmp_ph1begin_i(): begin Aggressive mode.
2009-08-11 09:00:44: INFO: isakmp.c:1198:isakmp_ph1begin_r(): respond new phase 1 negotiation: <=>2001:db8:0:1:20f:20ff:fefe:91db[500]
2009-08-11 09:00:44: INFO: isakmp.c:1202:isakmp_ph1begin_r(): begin Aggressive mode.
2009-08-11 09:00:44: INFO: vendorid.c:231:check_vendorid(): received Vendor ID: DPD
2009-08-11 09:00:44: NOTIFY: oakley.c:2486:oakley_skeyid(): couldn't find the proper pskey, try to get one by the peer's address.

followed by
2009-08-11 09:01:15: ERROR: isakmp.c:2288:isakmp_chkph1there(): phase2 negotiation failed due to time up waiting for phase1.
ESP 2001:db8:0:1:20f:20ff:fefe:91db[0]->2001:db8:0:1:215:99ff:fe41:704c[0]
2009-08-11 09:01:15: INFO: isakmp.c:2290:isakmp_chkph1there(): delete phase 2 handler.
2009-08-11 09:01:29: INFO: isakmp.c:2213:isakmp_post_acquire(): request for establishing IPsec-SA was queued due to no phase1 found.

This is happening ONLY for ipsec ipv6.

Could any of you let me know what's that which I am doing wrong?

With Regards,
Zakir Ahmed
"And fear Almighty, and know that you are to meet him in the hereafter"

--- On Fri, 7/8/09, Diego Rivera <diego.rivera@rbxglobal.com> wrote:

From: Diego Rivera <diego.rivera@rbxglobal.com>
Subject: Re: [Ipsec-tools-devel] Intermittent VPN behavior
To: "Timo Teräs" <timo.teras@iki.fi>
Cc: ipsec-tools-devel@lists.sourceforge.net, timo.teras@gmail.com
Date: Friday, 7 August, 2009, 7:24 PM

Comments below...

Timo Teräs wrote:
Diego Rivera wrote:
  I do have an interesting question though.  My DNS problem is due to bind9 wanting to reach another nameserver that would be accessible only over the VPN, the required policies being up, but racoon being unsuccessful at bringing up a phase2 tunnel after successfully bringing up phase1.

That sounds like bug still. Phase2 should establish. Care to share logs?
Sure - I'll collect some today and provide them.  Looking more carefully though it appears that my problem is that phase1 is intermittently not coming up.  As I mentioned, I keep getting messages about " give up to get IPsec-SA due to time up to wait" when the tunnels fail to come up, which makes no sense to me since all 3 sites are configured identically (though I may be misunderstanding what the message means).  Any thoughts as to why that would be happening on 3 identically configured boxes?  Also - if it's a timing issue, how do I narrow the timings such that this timeout happens faster and a new attempt at building the phase1 tunnel is made ASAP?  That might be a way to facilitate things...

The problem isn't all of the above - the problem is that the attempt to connect over the VPN results in no timeout.  The packets seem to hang in limbo indefinitely, hence the problem with DNS - it never gets timed out so it just hangs there.  This causes that programs such as SSH and even the shell will attempt to use DNS resolution to identify the incoming connection for security purposes.  Thus, the box becomes inaccessible for administration.  The dependency between nameservers is inevitable.

Perhaps there's a way to configure the kernel's IPSec stack to timeout such connection attempts instead of swallowing them indefinitely as it is right now?

Err, it is the correct behaviour to drop the DNS packets if there's no
SA. The application code should have timeout code.
The problem isn't that the app doesn't have timeout code.  The problem is that it appears to get locked up in a system call because there's an SPD for encapsulating the packet, no matching SA is found (i.e. the tunnel isn't up), and nobody (kernel, racoon, whatever) rejects or times out that transmission request.  Thus, the program is hung without hope of recovery.  The only solution is to bring the remote box up and let the VPN come up.  At that moment everything is honkey dorey again.  This is with statically-declared SPD's, btw, and is the main symptom.

Maybe when the SA is not there, you use default route for the packets
that would normally be encapsulated; and your default router sends
back ICMP errors? Maybe you should try with no-SPD, but explicit firewall
rule to DROP packets, or blackhole route them. If that works, then it
sounds like a kernel bug.

- Timo
Just to clarify, this is the "algorithm" I'm trying to implement:  Boot up without any SPD's or SA's in place - this means that everything starts up working and "unbroken". Then, we bring up racoon, and tell it to bring up the VPN's (using vpn-connect or establish-sa as appropriate). When phase 1 comes up for VPN X, add the SPD's using the "phase1_up" script.  IF phase 1 goes down, take them away using the same script (phase1_down).  This eliminates the problem with bind, but has the problem that it only works intermittently.

Strangely enough, I have other VPN's defined to other sites not controlled by me that do work as expected 100% of the time.


Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: diego.rivera@rbxglobal.com | www.rbxglobal.com

-----Inline Attachment Follows-----

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

-----Inline Attachment Follows-----

Ipsec-tools-devel mailing list

Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8.