Re: [Ipsec-tools-devel] Intermittent VPN behavior

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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 <die...@rb...> wrote:

From: Diego Rivera <die...@rb...>
Subject: Re: [Ipsec-tools-devel] Intermittent VPN behavior
To: "Timo Teräs" <tim...@ik...>
Cc: ips...@li..., tim...@gm...
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.

Thanks.

-- 

#yiv16518093 p {margin:0;}

 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: die...@rb...
| 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
Ips...@li...
https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel

      Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8. http://downloads.yahoo.com/in/internetexplorer/