[vpn-help] Connection failure with client. Debug information doesn't seem helpful.

[Kevin VPN]

On 07/01/2011 12:32 AM, Eric B. wrote:
> On 07/01/2011 12:15 AM, Eric B. wrote:
>> Hi,
>>
>> I am looking to configured my FC14 box as an IPSEC client to connect to
>> my office VPN. I do not know what server the office VPN is using. All
>> I know are the specs that they have given me. This is my first attempt
>> in getting the IPSEC tunnel to work from Linux. I don't know if anyone
>> else has managed successfully. I do know that Mac users have gotten it
>> working with ipsecuritas.
>
> A quick followup. I double checked my /etc/ike/iked.conf file and it was
> misconfigured. With proper debug level enabled, I now get the following
> trace (I still can't understand it however):
> /var/log/ike/iked.log:
...
> 11/07/01 00:27:32 <- : recv IKE packet xx.xx.160.179:500 ->
> 192.168.2.114:500 ( 228 bytes )
> 11/07/01 00:27:32 DB : phase1 found
> 11/07/01 00:27:32 ww : initiator port values should only float once per
> session
> 11/07/01 00:27:32 ii : processing phase1 packet ( 228 bytes )
> 11/07/01 00:27:32 =< : cookies fc65ce98e1ea6e4e:1c3396377d7b7fab
> 11/07/01 00:27:32 =< : message 00000000
> 11/07/01 00:27:32 << : ignoring duplicate key excahnge payload
> 11/07/01 00:27:32 !! : unprocessed payload data
> 11/07/01 00:27:32 << : ignoring duplicate nonce payload
> 11/07/01 00:27:32 !! : unprocessed payload data
> 11/07/01 00:27:32 !! : unhandled phase1 payload 'unknown' ( 42 )
> 11/07/01 00:27:32 !! : unprocessed payload data
> 11/07/01 00:27:32 ii : sending peer DELETE message
> 11/07/01 00:27:32 ii : - 192.168.2.114:4500 -> xx.xx.160.179:4500
> 11/07/01 00:27:32 ii : - isakmp spi = fc65ce98e1ea6e4e:1c3396377d7b7fab
> 11/07/01 00:27:32 ii : - data size 0
> 11/07/01 00:27:32 >> : hash payload
> 11/07/01 00:27:32 >> : delete payload
> 11/07/01 00:27:32 == : new informational hash ( 20 bytes )
> 11/07/01 00:27:32 == : new informational iv ( 16 bytes )
> 11/07/01 00:27:32 >= : cookies fc65ce98e1ea6e4e:1c3396377d7b7fab
> 11/07/01 00:27:32 >= : message f0ebee95
> 11/07/01 00:27:32 >= : encrypt iv ( 16 bytes )
> 11/07/01 00:27:32 == : encrypt packet ( 80 bytes )
> 11/07/01 00:27:32 == : stored iv ( 16 bytes )
> 11/07/01 00:27:32 -> : send NAT-T:IKE packet 192.168.2.114:4500 ->
> xx.xx.160.179:4500 ( 124 bytes )
> 11/07/01 00:27:32 ii : phase1 removal before expire time
> 11/07/01 00:27:32 DB : phase1 deleted ( obj count = 0 )

Hi Eric,

I've never worked with certificates, but it looks to me that the Shrew 
client receives a message from the gateway and immediately stops 
negotiations and tears down the connection.

That suggests to me that perhaps you still have not got some setting 
configured the way the gateway wants it.  The "ignoring duplicate key 
excahnge payload" message may suggest that Phase 1 negotiation is not 
completing properly.

I notice a difference in Phase 1 lifetimes.  In your first message, you 
mention the Phase 1 settings as:

Phase 1:
    - Lifetime 1800
    - DH Group: 1024(2)
    - Encryption: AES 128
    - Authen: SHA-1
    - Exchange: Main

However, in the trace you sent, your client is echoing the following:

11/07/01 00:27:22 ii : matched isakmp proposal #1 transform #1
11/07/01 00:27:22 ii : - transform    = ike
11/07/01 00:27:22 ii : - cipher type  = aes
11/07/01 00:27:22 ii : - key length   = 128 bits
11/07/01 00:27:22 ii : - hash type    = sha1
11/07/01 00:27:22 ii : - dh group     = modp-1024
11/07/01 00:27:22 ii : - auth type    = sig-rsa
11/07/01 00:27:22 ii : - life seconds = 86400
11/07/01 00:27:22 ii : - life kbytes  = 0

You may want to double-check those settings.