[Vpn-help] trouble compiling beta3 on ubunutu 6.0.6 lts

Mon Sep 17 16:01:49 CDT 2007

On Mon, 17 Sep 2007 13:14:21 -0700, "Harondel J. Sibble" <help at pdscc.com>
wrote:
> Matthew
> 
> Here's where I am at, I am seeing lots of DPD traffic happening, but it
> doesn't look like it's getting to Phase2. Here's what I am seeing on the
> router side, I've obscured any possibly sensitive info.
> 

It doesn't proceed to phase2 as we are getting stalled during the mode
config exchange.

> At the vpn client end, I have the laptop running Ubuntu 6.0.6 LTS and the
> beta 3 of the Shrew client going through a Fortigate 50 router connecting
> to
> a Fortgate Wifi60a gateway.
> 
> 

Please upgrade to beta 4 ( or rc1 which should be released tonight ). A
locking issue was present in beta 3 that caused iked to hang in some cases
which was particularly troublesome on Linux.

>  comes www.xxx.yyy.zzz:51859->aaa.bbb.ccc.ddd:500,ifindex=4....
> 0: Exchange=4 I_COOKIE=xxxxxxxxxxxxxxxxxxxxx
R_COOKIE=xxxxxxxxxxxxxxxxxxxx
> len=410
> The peer id is staff.member1
> 0:P1_Reco_ipsec_vpn: new connection.
> 0:P1_Reco_ipsec_vpn:0: received payloads SA KE NONCE ID VID VID VID VID
> 0:P1_Reco_ipsec_vpn:347: responder: aggressive mode get 1st message...
> 0:P1_Reco_ipsec_vpn:347: parse all vendor ids...
> 0:P1_Reco_ipsec_vpn:347: found NAT-T v2
> 0:P1_Reco_ipsec_vpn:347 found FortiClient v3
> 0:P1_Reco_ipsec_vpn:347: found DPD v2
> 0:P1_Reco_ipsec_vpn:347: found Cisco Unity client
> 0:P1_Reco_ipsec_vpn:347: negotiation result
> 0:P1_Reco_ipsec_vpn:347: proposal id = 1:
> 0:P1_Reco_ipsec_vpn:347:   protocol id = ISAKMP:
> 0:P1_Reco_ipsec_vpn:347:      trans_id = KEY_IKE.
> 0:P1_Reco_ipsec_vpn:347:      encapsulation = IKE/none
> 0:P1_Reco_ipsec_vpn:347:         type=OAKLEY_ENCRYPT_ALG, val=AES_CBC.
> 0:P1_Reco_ipsec_vpn:347:         type=OAKLEY_HASH_ALG, val=SHA.
> 0:P1_Reco_ipsec_vpn:347:         type=AUTH_METHOD, val=PRESHARED_KEY.
> 0:P1_Reco_ipsec_vpn:347:         type=OAKLEY_GROUP, val=1536.
> 0:P1_Reco_ipsec_vpn:347:         type=KEY_LENGTH, val=256.
> 0:P1_Reco_ipsec_vpn:347: phase1 lifetimes=28800
> 0:P1_Reco_ipsec_vpn:347: sending DPD VID payloads....
> 0:P1_Reco_ipsec_vpn:347: sending FGT DPD VID payloads....
> 0:P1_Reco_ipsec_vpn:347: Sending VID payload....
> P1_Reco_ipsec_vpn: Responder: sent www.xxx.yyy.zzz aggressive mode
message
> #1
> (OK)
> 0:P1_Reco_ipsec_vpn:347: send IKE
> Packet(STF_REPLY):aaa.bbb.ccc.ddd:500(if4) -> www.xxx.yyy.zzz:51859,
> len=420
> 0:P1_Reco_ipsec_vpn:347: retransmit timeout=6.
> 
> 
> 0: comes www.xxx.yyy.zzz:51859->aaa.bbb.ccc.ddd:500,ifindex=4....
> 0: Exchange=4 I_COOKIE=xxxxxxxxxxxxxxxxxxx R_COOKIE=xxxxxxxxxxxxxxxxx
> len=60
> 0: checking P1_Reco_ipsec_vpn aaa.bbb.ccc.ddd 4 -> www.xxx.yyy.zzz:51859
> 0:P1_Reco_ipsec_vpn: phase1 found
> 0:P1_Reco_ipsec_vpn:347: received payloads HASH
> 0:P1_Reco_ipsec_vpn:347: responder: aggressive mode get 2nd response...
> 0:P1_Reco_ipsec_vpn:347: set phase1 state timeout=28800
> P1_Reco_ipsec_vpn: Responder: parsed www.xxx.yyy.zzz aggressive mode
> message
> #2 (DONE)
> 0:P1_Reco_ipsec_vpn: adding new dialup tunnel for www.xxx.yyy.zzz:51859
> 0:P1_Reco_ipsec_vpn_0: added new dialup tunnel for www.xxx.yyy.zzz:51859
> 
> 
> 0: comes www.xxx.yyy.zzz:51859->aaa.bbb.ccc.ddd:500,ifindex=4....
> 0: Exchange=5 Message=0x1ACE4F83 len=92
> 0: checking P1_Reco_ipsec_vpn_0 aaa.bbb.ccc.ddd 4 ->
www.xxx.yyy.zzz:51859
> 0:P1_Reco_ipsec_vpn_0: phase1 found
> 0:P1_Reco_ipsec_vpn_0:347: received payloads HASH Notif
> 0:P1_Reco_ipsec_vpn_0:347: received protected info
> 0:P1_Reco_ipsec_vpn_0:347:   protocol_id=1, notify_msg=24578 (24578??),
> ispi_size=16
> 0:P1_Reco_ipsec_vpn_0:347:   spi=yyyyyyyyyyyyyyyyyyyyyyyy
> 0:P1_Reco_ipsec_vpn_0:347:   Msg=ô¿@3
> 0:P1_Reco_ipsec_vpn_0:347: processing INITIAL-CONTACT
> 0:P1_Reco_ipsec_vpn_0: flushing
> 0:P1_Reco_ipsec_vpn_0: flushed
> 0:P1_Reco_ipsec_vpn_0:347: processed INITIAL-CONTACT
> 
> 
> 0:P1_Reco_ipsec_vpn_0: no ISAKMP SA available to send DPD, so delete
> dynamic
> connection
> 
> 
> 0: comes www.xxx.yyy.zzz:51859->aaa.bbb.ccc.ddd:500,ifindex=4....
> 0: Exchange=5 Message=0x7DB5C7A7 len=92
> 0: checking P1_Reco_ipsec_vpn_0 aaa.bbb.ccc.ddd 4 ->
www.xxx.yyy.zzz:51859
> 0:P1_Reco_ipsec_vpn_0: phase1 found
> 0:P1_Reco_ipsec_vpn_0:347: received payloads HASH Notif
> 0:P1_Reco_ipsec_vpn_0:347: received protected info
> 0:P1_Reco_ipsec_vpn_0:347: send IKE Packet(DPD
> response):aaa.bbb.ccc.ddd:500(if4) -> www.xxx.yyy.zzz:51859, len=92
> 
> 
> 0: comes www.xxx.yyy.zzz:51859->aaa.bbb.ccc.ddd:500,ifindex=4....
> 0: Exchange=5 Message=0x96FC1503 len=92
> 0: checking P1_Reco_ipsec_vpn_0 aaa.bbb.ccc.ddd 4 ->
www.xxx.yyy.zzz:51859
> 0:P1_Reco_ipsec_vpn_0: phase1 found
> 0:P1_Reco_ipsec_vpn_0:347: received payloads HASH Notif
> 0:P1_Reco_ipsec_vpn_0:347: received protected info
> 0:P1_Reco_ipsec_vpn_0:347: send IKE Packet(DPD
> response):aaa.bbb.ccc.ddd:500(if4) -> www.xxx.yyy.zzz:51859, len=92
> 
> 
> On the Shrew side I see the following. P.S. is there are way to have
> date/time stamp on the logs, that'd be really hand to have.
> 

Right. This is a bit embarrassing and should have been fixed by now. I will
get this fixed in the next release.

> I'm seeing similar results with Nat Traversal enabled or disabled on the
> client side. What is difference between the push and pull configuration
> method on the general tab?
> 

The configuration mode exchange draft defines two methods for peer
configuration, push and pull. Cisco and IPsec Tools both support the pull
configuration method which is the client default. Both methods are
supported by the Shrew Soft IKE daemon when acting as a gateway or a
client. The push method is used by other vendors ( although I can't
remember which ones at the moment ). Here is a basic description ( from
memory ) on how they work ...

Pull Mode : After phase1/Xauth, the client sends a list of configuration
attributes using either NULL or suggested values. This constitutes the pull
request. The gateway then responds with a list of configuration attributes
for the client to use ( address, netmask, DNS, etc ... ). The client then
acknowledges the response with a list of configuration attributes it has
accepted.

Push Mode : After phase1/Xauth, the client waits for the gateway to send a
list of configuration attributes for the client to use ( address, netmask,
DNS, etc ... ). The client then acknowledges the response with a list of
configuration attributes it has accepted.

> Where do I get sysv startup script I see mentioned in a few posts, that
> doesn't seem to be around after my compile.
> 

I will forward this to the list again when I get back to my pc.

> Lastly, running iked manually, I noticed it stops running on it's own
> about
> half the time and has to be restarted manually.
> 

Hmmm ... that doesn't sound good. Hopefully this was the problem that was
corrected in beta 4. Do you have an example of the log output when this
occurs?

> 
> ## : IKE Daemon, ver 2.0.0
> ## : Copyright 2007 Shrew Soft Inc.
> ## : This product linked OpenSSL 0.9.8a 11 Oct 2005
> ii : opened /var/log/iked.log'
> ii : opened /var/log/ike.pcap'
> ii : opened /var/log/pub.pcap'
> ii : network process thread begin ...
> ii : pfkey process thread begin ...
> K! : recv X_SPDDUMP message failure ( errno = 2 )
> ii : admin process thread begin ...
> <A : peer config add message
> <A : proposal config message
> <A : proposal config message
> <A : client config message
> <A : local id 'staff.member1' message
> <A : preshared key message
> <A : remote resource message
> <A : peer tunnel enable message
> ii : opened tap device tap0
> ii : matched isakmp proposal #1 transform #1
> ii : - transform    = ike
> ii : - cipher type  = aes
> ii : - key length   = 256 bits
> ii : - hash type    = sha1
> ii : - dh group     = modp-1536
> ii : - auth type    = psk
> ii : - life seconds = 28800
> ii : - life kbytes  = 0
> ii : phase1 id match ( natt prevents ip match )
> ii : phase1 id match ( ipv4-host aaa.bbb.ccc.ddd )
> ii : peer supports DPDv1
> ii : phase1 sa established
> ii : aaa.bbb.ccc.ddd:500 <-> fff.ggg.eee.hhh:500
> ii : (the spi has been obscured)
> ii : sending peer INITIAL-CONTACT notification
> ii : - fff.ggg.eee.hhh:500 -> aaa.bbb.ccc.ddd:500
> ii : - isakmp spi = (the spi has been obscured)
> ii : - data size 0
> ii : xauth is not required

Alright, so I see that phase1 is established here but I don't see it moving
to the configuration phase. Is the client set to use the push method? I
probably need to add a log output line that shows this so this will be more
transparent in the future. The ike daemon may simply be waiting for the
gateway to offer the configuration attribute list. If this is the case,
perhaps you need to use the pull configuration method. The Fortgate doesn't
seem to be sending a push configuration in its log output so I think this
is likely the problem. Do you have any sample log output using the pull
method?

Thanks,

-Matthew