[Openswan Users] Connection to Netscreen 500, PHASE 2 fails

Thu Dec 6 16:29:50 EST 2007

Off hand I don't see the problem in your conf or logs here.

Put this in your ipsec.conf setup section.
	plutodebug=none
	klipsdebug=none
Setting them to anything else just fills you logs with junk and makes hard to read.
Restart openswan, try to connect again, then send the new readable logs from the restart to the end.

This will not be the cause of your problem but may help later, also set these in your conn to match remote end...
	ikelifetime=28800 # also, 8.0h, defaults to 1.0h
	keylife=3600 # also 1.0h, defaults to 8.0h

Peter McGill

> -----Original Message-----
> From: users-bounces at openswan.org 
> [mailto:users-bounces at openswan.org] On Behalf Of Michael Lavallee
> Sent: December 6, 2007 3:49 PM
> To: users at openswan.org
> Subject: [Openswan Users] Connection to Netscreen 500, PHASE 2 fails
> 
> Hello everyone,
> 
> I've been lurking on this list for a while now while I've 
> read through 
> the Packt Publishing Openswan book and countless Google 
> articles.  :-)  
> I've learned a lot about VPN's the past while, but not nearly 
> enough, it 
> seems!
> 
> I'm trying to setup our Linux server to connect to one of my business 
> partner's Netscreen 500 boxes.  They've got other clients using VPN's 
> with it.  This is going to be a host-to-host VPN, not a network (or 
> subnet it's also called?) VPN.  I'm running openswan 2.4.5.
> 
> We are passing PHASE 1 without any problems that I can see, 
> but things 
> hang up on entering PHASE 2 and I can not tell from the log 
> files what 
> exactly is going on.
> 
> I guess to start off with I should tell you the parameters I 
> was given 
> by them.
> 
> PHASE1: AES 256, PSK, SHA-1, GROUP2, Lifetime 28 800 seconds.
> PHASE2: AES 256, SHA-1, GROUP2, Lifetime 3600 seconds, PFS YES.
> 
> My configuration, from /etc/ipsec.d/partner.conf
>   auto=add
>   authby=secret
>   compress=no
>   ike=aes256-sha1-modp1024
>   esp=aes256-sha1
>   pfs=yes
>   left=xxx.xxx.205.212   #My box, Internet IP.
>   right=xxx.xxx.94.73     #Their box, Interne IP.
> 
> This is what they said they configured their NetScreen as for our 
> specific VPN:
>   set ike p1-proposal "mlavalle" preshare group2 esp aes256 
> sha-1 second 
> 28800
>   set ike p2-proposal "mlavalle" group2 esp aes256 sha-1 second 3600
>   set ike gateway "mlavalle" address xxx.xxx.205.212 Main 
> outgoing-interface "ethernet3/1:1" preshare "--snip--" 
> proposal "mlavalle"
>   set vpn "mlavalle" gateway "mlavalle" no-replay tunnel idletime 0 
> proposal "mlavalle"
> 
> My box has a direct connection to the Internet, and acts as a gateway 
> for the other workstations here, so I don't think NAT is an issue in 
> this circumstance.  I also have a static Internet IP, as does the 
> NetScreen I am trying to connect to.
> 
> # ipsec auto --up partner
> 104 "partner" #8: STATE_MAIN_I1: initiate
> 003 "partner" #8: ignoring unknown Vendor ID payload 
> [2c78d2631621ef645b510ec9202f31024d1560e50000000200000514]
> 003 "partner" #8: ignoring Vendor ID payload [HeartBeat 
> Notify 386b0100]
> 106 "partner" #8: STATE_MAIN_I2: sent MI2, expecting MR2
> 108 "partner" #8: STATE_MAIN_I3: sent MI3, expecting MR3
> 004 "partner" #8: STATE_MAIN_I4: ISAKMP SA established 
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha 
> group=modp1024}
> 117 "partner" #9: STATE_QUICK_I1: initiate
> 010 "partner" #9: STATE_QUICK_I1: retransmission; will wait 
> 20s for response
> 010 "partner" #9: STATE_QUICK_I1: retransmission; will wait 
> 40s for response
> 031 "partner" #9: max number of retransmissions (2) reached 
> STATE_QUICK_I1.  No acceptable response to our first Quick 
> Mode message: 
> perhaps peer likes no proposal
> 000 "partner" #9: starting keying attempt 2 of an unlimited 
> number, but 
> releasing whack
> 
> There is a lot of information in my /var/log/secure, I'm not 
> sure if I 
> should post it all - don't know what the accepted message 
> limit is here 
> yet!  But, I will try and post starting from a logical place 
> to shorten 
> it down.
> 
> 13:19:54 server pluto[19629]: "partner" #8: STATE_MAIN_I4: ISAKMP SA 
> established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha 
> group=modp1024}
> 13:19:54 server pluto[19629]: | modecfg pull: noquirk 
> policy:push not-client
> 13:19:54 server pluto[19629]: | phase 1 is done, looking for 
> phase 1 to 
> unpend
> 13:19:54 server pluto[19629]: | unqueuing pending Quick Mode with 
> xxx.xxx.94.73 "partner"
> 13:19:54 server pluto[19629]: | duplicating state object #8
> 13:19:54 server pluto[19629]: | creating state object #9 at 
> 0x5555558232d0
> 13:19:54 server pluto[19629]: | processing connection client
> 13:19:54 server pluto[19629]: | ICOOKIE:  28 b5 cd 0c  0b 5b 7d fe
> 13:19:54 server pluto[19629]: | RCOOKIE:  7c 86 c1 9f  43 64 4e 3a
> 13:19:54 server pluto[19629]: | peer:  c0 7f 5e 49
> 13:19:54 server pluto[19629]: | state hash entry 0
> 13:19:54 server pluto[19629]: | inserting event EVENT_SO_DISCARD, 
> timeout in 0 seconds for #9
> 13:19:54 server pluto[19629]: "partner" #9: initiating Quick Mode 
> PSK+EpartnerYPT+TUNNEL+PFS+UP {using isakmp#8}
> 13:19:54 server pluto[19629]: | 0: w->pcw_dead: 0 
> w->pcw_work: 0 cnt: 1
> 13:19:54 server pluto[19629]: | asking helper 0 to do 
> build_kenonce op 
> on seq: 9
> 13:19:54 server pluto[19629]: | inserting event EVENT_CRYPTO_FAILED, 
> timeout in 300 seconds for #9
> 13:19:54 server pluto[19633]: ! helper -1 doing build_kenonce op id: 9
> 13:19:54 server pluto[19629]: | next event 
> EVENT_PENDING_PHASE2 in 4 seconds
> 13:19:54 server pluto[19629]: | processing connection partner
> 13:19:54 server pluto[19629]: | kernel_alg_db_new() will return 
> p_new->protoid=3, p_new->trans_cnt=1
> 13:19:54 server pluto[19629]: | kernel_alg_db_new()     trans[0]: 
> transid=12, attr_cnt=2, attrs[0].type=5, attrs[0].val=2
> 13:19:54 server pluto[19629]: | returning new proposal from esp_info
> 13:19:54 server pluto[19629]: | sending 268 bytes for quick_outI1 
> through eth2:500 to 192.127.94.73:500:
> 13:19:54 server pluto[19629]: | inserting event EVENT_RETRANSMIT, 
> timeout in 10 seconds for #9
> 13:19:54 server pluto[19629]: | next event 
> EVENT_PENDING_PHASE2 in 4 seconds
> 13:19:58 server pluto[19629]: |
> 13:19:58 server pluto[19629]: | *time to handle event
> 13:19:58 server pluto[19629]: | handling event EVENT_PENDING_PHASE2
> 13:19:58 server pluto[19629]: | event after this is 
> EVENT_RETRANSMIT in 
> 6 seconds
> 13:19:58 server pluto[19629]: | inserting event EVENT_PENDING_PHASE2, 
> timeout in 120 seconds
> 13:19:58 server pluto[19629]: | pending review: connection 
> "partner" checked
> 13:19:58 server pluto[19629]: | next event EVENT_RETRANSMIT 
> in 6 seconds 
> for #9
> 13:20:04 server pluto[19629]: |
> 13:20:04 server pluto[19629]: | *time to handle event
> 13:20:04 server pluto[19629]: | handling event EVENT_RETRANSMIT
> 13:20:04 server pluto[19629]: | event after this is 
> EVENT_PENDING_PHASE2 
> in 114 seconds
> 13:20:04 server pluto[19629]: | processing connection partner
> 13:20:04 server pluto[19629]: | handling event EVENT_RETRANSMIT for 
> xxx.xxx.94.73 "partner" #9
> 13:20:04 server pluto[19629]: | sending 268 bytes for 
> EVENT_RETRANSMIT 
> through eth2:500 to xxx.xxx.xx.73:500:
> 13:20:04 server pluto[19629]: | inserting event EVENT_RETRANSMIT, 
> timeout in 20 seconds for #9
> 13:20:04 server pluto[19629]: | next event EVENT_RETRANSMIT in 20 
> seconds for #9
> 13:20:24 server pluto[19629]: |
> 13:20:24 server pluto[19629]: | *received kernel message
> 13:20:24 server pluto[19629]: | next event EVENT_RETRANSMIT 
> in 0 seconds 
> for #9
> 13:20:24 server pluto[19629]: |
> 13:20:24 server pluto[19629]: | *time to handle event
> 13:20:24 server pluto[19629]: | handling event EVENT_RETRANSMIT
> 13:20:24 server pluto[19629]: | event after this is 
> EVENT_PENDING_PHASE2 
> in 94 seconds
> 13:20:24 server pluto[19629]: | processing connection partner
> 13:20:24 server pluto[19629]: | handling event EVENT_RETRANSMIT for 
> xxx.xxx.94.73 "partner" #9
> 13:20:24 server pluto[19629]: | sending 268 bytes for 
> EVENT_RETRANSMIT 
> through eth2:500 to xxx.xxx.xx.73:500:
> 13:20:24 server pluto[19629]: | inserting event EVENT_RETRANSMIT, 
> timeout in 40 seconds for #9
> 13:20:24 server pluto[19629]: | next event EVENT_RETRANSMIT in 40 
> seconds for #9
> 13:21:04 server pluto[19629]: |
> 13:21:04 server pluto[19629]: | *time to handle event
> 13:21:04 server pluto[19629]: | handling event EVENT_RETRANSMIT
> 13:21:04 server pluto[19629]: | event after this is 
> EVENT_PENDING_PHASE2 
> in 54 seconds
> 13:21:04 server pluto[19629]: | processing connection partner
> 13:21:04 server pluto[19629]: | handling event EVENT_RETRANSMIT for 
> xxx.xxx.94.73 "partner" #9
> 13:21:04 server pluto[19629]: "partner" #9: max number of 
> retransmissions (2) reached STATE_QUICK_I1.  No acceptable 
> response to 
> our first Quick Mode message: perhaps peer likes no proposal
> 
>  From there it just seems to be the same 'ol thing.  If I've made a 
> mistake and grabbed the wrong section, please let me know and I will 
> repost or maybe link to the full log or something.
> 
> Reading that log, I'm not entirely sure where I've failed in my 
> configuration.  There was one message that stood out, an 
> "EVENT_CRYPTO_FAILED", but I'm not sure how / if that plays 
> into things 
> as I thought the pre-shared key stuff was done in STAGE 1.
> 
> Any help or direction is greatly appreciated!
> 
> Thanks,
> 
> Michael.
> 
> 
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan: 
> http://www.amazon.com/gp/product/1904811256/104-3099591-294632
> 7?n=283155